Иной взгляд на UNIX.
Обратите внимание, что единственное спасение для UNIX заключено вОбратите внимание, не "для UNIX", а только для тех, кому вдруг оказался нужен EDT.
Emacs, тоже, кстати, уходящем корнями в недра DEC, или в Emacs-
подобном JED.
Revision control, как правильно замечено, необходимо делать или средствами
файловой системы, если она позволяет, или внешним программным обеспечением,
специально для этого предназначенным.
Revision control, привязанный к конкретному текстовому редактору
не является здравой идеей.
> Обратите внимание, не "для UNIX", а только для тех,
> кому вдруг оказался нужен EDT.
Ты читать не умеешь?
>> 10.2. Numbered Backups Under Linux
>> Linux doesn't still support file version numbers
А vi --- удел ярых UNIX-поклонников, которые ничего другого, кроме ed и cat,
не видели.
Кстати о редакторах.
Возьми исходники TECO и сравни TECO с ed.
Узнай, откуда ноги растут.
А насчёт "привязки к редактору" почитай про Symbolics.
После всего этого, ещё думать над словами Пайка.
---
"...Видный ретроград-новатор."
> кому вдруг оказался нужен EDT.
Ты читать не умеешь?
>> 10.2. Numbered Backups Under Linux
>> Linux doesn't still support file version numbers
А vi --- удел ярых UNIX-поклонников, которые ничего другого, кроме ed и cat,
не видели.
Кстати о редакторах.
Возьми исходники TECO и сравни TECO с ed.
Узнай, откуда ноги растут.
А насчёт "привязки к редактору" почитай про Symbolics.
После всего этого, ещё думать над словами Пайка.
---
"...Видный ретроград-новатор."
> vi --- удел ярых UNIX-поклонников, которые ничего другого, кроме ed и cat
категорически не согласен. я считаю этот редактор очень удобным.
категорически не согласен. я считаю этот редактор очень удобным.
CVS?
Открой для себя vim 
CVS это не то. Чтобы понять, о чем плачет надо хотя бы чуть-чуть поработать на VMS.
ключевые отличия?
А много тут таких людей? Кого волнуют его проблемы?
Это не его проблемы. Версионная файловая система - это действительно очень удобно и полезно. Я не слышал о ее реализациях в системах новее, чем VMS. Поэтому я и написал, что для того, чтобы понять что же это такое суперудобное - лучше хотя бы чуть-чуть поработать под VMS. Поверь, Глеб, даже тебе понравилась бы эта концепция, если бы ты попробовал.
сытый голодного не разумеет... инета нет хронически.
даже тебелол.
Я посмотрю, что это за штука такая.
Хотя очень боюсь, конечно. Вдруг придётся перейти на emacs потом.
Зря ты так. Версионная файловая система - это просто клевая концепция, с emacs никак не связана. Да и сам я больше люблю vim, хотя версионная файловая система мне нравится.
А с какими ещё редакторами ты работал?
---
"Narrowness of experience leads to narrowness of imagination."
Rob Pike
---
"Narrowness of experience leads to narrowness of imagination."
Rob Pike
Кстати, кто бы что ни говорил - но самый удобный редактор для программиста, из всего чем доводилось пользоваться был MultiEdit 4.0... Жаль только, что старичек умер вместе с MS-DOS.
Есть такой на компе
ee
ed - только параллельно с мануалом
emacs не оценивал, ибо vi мне по глаза и за глаза хватает
ed - только параллельно с мануалом
emacs не оценивал, ибо vi мне по глаза и за глаза хватает
Создание нового файла.
RCS:
(сохранение)
ci имя
Emacs:
C-x C-s C-x v i
VMS, Emacs/VMS:
(сохранение)
Затраты на создание новой версии.
RCS:
(сохранение)
ci -чего-то-там-чтоб-не-стёр имя
(загрузка)
Emacs:
C-x C-q C-c C-c C-x C-q
VMS:
(сохранение)
Emacs/VMS: C-x C-s
Считаем нажатия на клавиши.
---
"Narrowness of experience leads to narrowness of imagination."
Rob Pike
RCS:
(сохранение)
ci имя
Emacs:
C-x C-s C-x v i
VMS, Emacs/VMS:
(сохранение)
Затраты на создание новой версии.
RCS:
(сохранение)
ci -чего-то-там-чтоб-не-стёр имя
(загрузка)
Emacs:
C-x C-q C-c C-c C-x C-q
VMS:
(сохранение)
Emacs/VMS: C-x C-s
Считаем нажатия на клавиши.
---
"Narrowness of experience leads to narrowness of imagination."
Rob Pike
Это который наподобие сильно урезанного "WordStar"?
Ср. jstar из поставки joe.
---
"Narrowness of experience leads to narrowness of imagination."
Rob Pike
Ср. jstar из поставки joe.
---
"Narrowness of experience leads to narrowness of imagination."
Rob Pike
хз, я такого не видел
CVS заслуживает отдельного разговора.
Такой отстой тоже ещё поискать.
---
"Narrowness of experience leads to narrowness of imagination."
Rob Pike
Такой отстой тоже ещё поискать.
---
"Narrowness of experience leads to narrowness of imagination."
Rob Pike
"DOS lives!"
Мне "MultiEdit" не понравился.
Я его очень плохо помню, поэтому не буду обосновывать, ладно?
Возможно, что он был другого выпуска, не 4.0.
---
"...Плывёт по волнам,
По волнам моей памяти,
Исчезая в этих волнах..."
Мне "MultiEdit" не понравился.
Я его очень плохо помню, поэтому не буду обосновывать, ладно?
Возможно, что он был другого выпуска, не 4.0.
---
"...Плывёт по волнам,
По волнам моей памяти,
Исчезая в этих волнах..."
Ты точно не линуксовод.
Даже если бы я и не знал, что ты демонопоклонник,
твоё "не видел" даёт все основания утверждать
об отсутствии знакомства с наиболее распространёнными линуксами.
---
"Narrowness of experience leads to narrowness of imagination."
Rob Pike
Даже если бы я и не знал, что ты демонопоклонник,
твоё "не видел" даёт все основания утверждать
об отсутствии знакомства с наиболее распространёнными линуксами.
---
"Narrowness of experience leads to narrowness of imagination."
Rob Pike
А вот именно тут ты прав 
Нафиг мне линукс, если меня БСД всем устраивает?
Нафиг мне линукс, если меня БСД всем устраивает?
Не только я прав, но прав ещё и тот самый Роб Пайк.
Человек, стоявший когда-то у истоков UNIX и сказавший:
"Not only is UNIX dead, it's starting to smell really bad."
---
"Narrowness of experience leads to narrowness of imagination."
Rob Pike
Человек, стоявший когда-то у истоков UNIX и сказавший:
"Not only is UNIX dead, it's starting to smell really bad."
---
"Narrowness of experience leads to narrowness of imagination."
Rob Pike
>UNIX dead
то-то большинство современных осей называют себя *NIX-подобными
Повторение мать заикания.
то-то большинство современных осей называют себя *NIX-подобными
Повторение мать заикания.
www.cs.bell-labs.com/who/rob/utah2000.pdf
www.cs.bell-labs.com/who/rob/utah2000.ps
---
...Я работаю антинаучным аферистом...
www.cs.bell-labs.com/who/rob/utah2000.ps
---
...Я работаю антинаучным аферистом...
а что там?
Несколько важных тезисов:
Today’s graduating PhDs use Unix, X, Emacs, and Tex.
That’s their world. It’s often the only computing world
they’ve ever used for technical work.
Twenty years ago, a student would have been exposed to a
wide variety of operating systems, all with good and bad
points.
New employees in our lab now bring their world with them, or
expect it to be there when they arrive. That’s reasonable, but
there was a time when joining a new lab was a chance to
explore new ways of working.
Narrowness of experience leads to narrowness of imagination.
...
New operating systems today tend to be just ways of
reimplementing Unix. If they have a novel architecture and
some do the first thing to build is the Unix emulation layer.
How can operating systems research be relevant when the
resulting operating systems are all indistinguishable?
...
There has been much talk about component architectures but
only one true success: Unix pipes. It should be possible to
build interactive and distributed applications from piece parts.
The future is distributed computation, but the language
community has done very little to address that possibility.
The Web has dominated how systems present and use
information: the model is forced interaction; the user must go
get it. Let’s go back to having the data come to the user
instead.
...
Conclusions
The world has decided how it wants computers to be. The
systems software research community influenced that decision
somewhat, but very little, and now it is shut out of the
discussion.
It has reached the point where I doubt that a brilliant systems
project would even be funded, and if funded, wouldn’t find the
bodies to do the work. The odds of success were always low;
now they’re essentially zero.
The community - universities, students, industry, funding
bodies - must change its priorities.
The community must accept and explore unorthodox ideas.
The community must separate research from market
capitalization.
А, так он поборник чистой науки?
Кто?
Пайк?
Он, между прочим, успел существенно поучавствовать в создании твоей любимой *NIX.
Так что там с "numbered backups" в БСД?
А можно там по примеру Пайка делать так:
% ls /ftp/ftp.uu.net/pub/
?
---
"Narrowness of experience leads to narrowness of imagination."
Rob Pike
Пайк?
Он, между прочим, успел существенно поучавствовать в создании твоей любимой *NIX.
Так что там с "numbered backups" в БСД?
А можно там по примеру Пайка делать так:
% ls /ftp/ftp.uu.net/pub/
?
---
"Narrowness of experience leads to narrowness of imagination."
Rob Pike
для меня критерий качества ОС - "работает - не работает"
винда - не работает, ибо вирусов дохрена и тормозит неоправданно. но она неизбежна
БСД - работает с точностью до отдельных девайсов
linux - должен работать, куда ж он денется.
про numbered backups в первый раз слышу
ls /ftp/ftp.uu.net/pub/ - попробую на досуге. не должно работать, да?
винда - не работает, ибо вирусов дохрена и тормозит неоправданно. но она неизбежна
БСД - работает с точностью до отдельных девайсов
linux - должен работать, куда ж он денется.
про numbered backups в первый раз слышу
ls /ftp/ftp.uu.net/pub/ - попробую на досуге. не должно работать, да?
% ls /ftp/ftp.uu.net/pub/Думаю, что можно, если это вдруг станет необходимо.
Почему ты работаешь в vi, а не в ed?
Почту ты тоже наверняка отправляешь не посредством sendmail,
хотя это можно делать:
sendmail -чего-то-там такому-то@там-то <file-name
А под виндой ты тоже работаешь?
Почту как отправляешь?
"telnet smtp.host 25" ?
"nc smtp.host 25 <filename.ext" ?
У тебя не самый лучший критерий качества.
Можешь подумать над этим.
---
...Я работаю антинаучным аферистом...
Почту ты тоже наверняка отправляешь не посредством sendmail,
хотя это можно делать:
sendmail -чего-то-там такому-то@там-то <file-name
А под виндой ты тоже работаешь?
Почту как отправляешь?
"telnet smtp.host 25" ?
"nc smtp.host 25 <filename.ext" ?
У тебя не самый лучший критерий качества.
Можешь подумать над этим.
---
...Я работаю антинаучным аферистом...
Можно сначала вопрос? Тебе это и правда интересно?
ed не юзаю, ибо сначала привык к ее, а потом к vi, при этом в принципе не зная о существовании ed
почту отправляю посредством html-интерфейса mail.ru Но недавно мне показали sylpheed!
В БСД есть большинство нужных мне приложений, это я и называю "работает" (в совокупности с безглючностью самой ОС).
ed не юзаю, ибо сначала привык к ее, а потом к vi, при этом в принципе не зная о существовании ed
почту отправляю посредством html-интерфейса mail.ru Но недавно мне показали sylpheed!
В БСД есть большинство нужных мне приложений, это я и называю "работает" (в совокупности с безглючностью самой ОС).
У тебя весьма странный для технического человека показатель качества.
Я понимаю, что "в БСД есть."
Например, я одно время отправлял почту исключительно путём
"netcat smtp.host.net 25 <filename.ext",
поскольку это было простейшее доступное за короткое время решение.
Однако писать письмо, заполняя уже вставленные заголовки,
и отправлять за два нажатия клавиш мне кажется более разумным.
---
"Narrowness of experience leads to narrowness of imagination."
Rob Pike
Я понимаю, что "в БСД есть."
Например, я одно время отправлял почту исключительно путём
"netcat smtp.host.net 25 <filename.ext",
поскольку это было простейшее доступное за короткое время решение.
Однако писать письмо, заполняя уже вставленные заголовки,
и отправлять за два нажатия клавиш мне кажется более разумным.
---
"Narrowness of experience leads to narrowness of imagination."
Rob Pike
Например, я одно время отправлял почту исключительно путём
"netcat smtp.host.net 25 <filename.ext"
Slackware - такая штука. Понимаю.
А мне нравится Это он для тебя странный
Это он для тебя странный В отличие от тебя я общаюсь не только с линуксом и форточками.
---
"Для того, чтобы не пройти мимо цели, иногда необходимо пойти ко дну."
Феликс Кривин, "Аксиомы"
---
"Для того, чтобы не пройти мимо цели, иногда необходимо пойти ко дну."
Феликс Кривин, "Аксиомы"
Ну-ну.
Продолжай набивать "co file-name" и "ci file-name" руками.
Пускай и с использованием дополнения и сохранения предыдущих команд.
Когда устанешь, подумай о "numbered backups" и vc-mode.
---
"Narrowness of experience leads to narrowness of imagination."
Rob Pike
Продолжай набивать "co file-name" и "ci file-name" руками.
Пускай и с использованием дополнения и сохранения предыдущих команд.
Когда устанешь, подумай о "numbered backups" и vc-mode.
---
"Narrowness of experience leads to narrowness of imagination."
Rob Pike
Странно. Никогда такого не набивал. Почему бы это?
наверное, профиль не тот
наверное, профиль не тот
Мне один администратор линуксов как-то пожаловался,
что в конторе начальство требует закомментаривать старые настройки,
писать новые и примечания к ним: кто, когда и зачем.
Меня удивляет то, что они не смогли додуматься использовать для этого
такую совершенно необычную для нашего времени вещь, как RCS.
---
"Narrowness of experience leads to narrowness of imagination."
Rob Pike
что в конторе начальство требует закомментаривать старые настройки,
писать новые и примечания к ним: кто, когда и зачем.
Меня удивляет то, что они не смогли додуматься использовать для этого
такую совершенно необычную для нашего времени вещь, как RCS.
---
"Narrowness of experience leads to narrowness of imagination."
Rob Pike
А можно там по примеру Пайка делать так:
% ls /ftp/ftp.uu.net/pub/
CODA + несложный плагин - и можно.
Это не его проблемы. Версионная файловая система - это действительно очень удобно и полезно. Я не слышал о ее реализациях в системах новее, чем VMS. Поэтому я и написал, что для того, чтобы понять что же это такое суперудобное - лучше хотя бы чуть-чуть поработать под VMS. Поверь, Глеб, даже тебе понравилась бы эта концепция, если бы ты попробовал.Снапшоты в современных файловых системах конечно не реализуют этой фичи полностью, но реализуют частично и также дают много других ценных вещей.
Ты точно не линуксовод.Он счастливый человек.
Даже если бы я и не знал, что ты демонопоклонник,
твоё "не видел" даёт все основания утверждать
об отсутствии знакомства с наиболее распространёнными линуксами.
Так что там с "numbered backups" в БСД?Есть incremental dumps и snapshots.
% ls /ftp/ftp.uu.net/pub/OS тут не причем. Это фича шелла. Всякие монстры типа zsh это умеют.
P.S. КОНТРА, что ты пытаешься в этом треде доказать? Что VMS лучше чем БСД?
Снапшоты в современных файловых системах конечно не реализуют этой фичи полностью, но реализуют частично
К сожалению, я бы такую реализацию даже частичной побоялся назвать. Слижком уж убого получается... А точнее, совсем не то
КОНТРА, что ты пытаешься в этом треде доказать? Что VMS лучше чем БСД?Скорее он пытается доказать вот это, и я с ним полностью согласен:
Today’s graduating PhDs use Unix, X, Emacs, and Tex. That’s their world. It’s often the only computing world they’ve ever used for technical work.
Twenty years ago, a student would have been exposed to a wide variety of operating systems, all with good and bad points.
New employees in our lab now bring their world with them, or expect it to be there when they arrive. That’s reasonable, but there was a time when joining a new lab was a chance to explore new ways of working.
Narrowness of experience leads to narrowness of imagination.
> Narrowness of experience leads to narrowness of imagination.
И правильно, чтоб не воображали чего ни попадя
И правильно, чтоб не воображали чего ни попадя
20 лет назад ИТ-индустрия была не так развита.
Ничего удивительного, что перестали попадаться универсалы, которые разбираются ВО ВСЕХ системах.
Сейчас просто произошло "разделение труда". А оно в свое время в промышленности произвело бум. Появились специалисты - каждый в своей области. Спец идет туда, где разбирается в системе. Вот и в ИТ-индустрии бум. Если будешь воспитывать "компьютерщиков", кторые ВСЕ ЗНАЮТ, ничего не выйдет... Слишком большая производная объема необходимых знаний...
Ничего удивительного, что перестали попадаться универсалы, которые разбираются ВО ВСЕХ системах.
Сейчас просто произошло "разделение труда". А оно в свое время в промышленности произвело бум. Появились специалисты - каждый в своей области. Спец идет туда, где разбирается в системе. Вот и в ИТ-индустрии бум. Если будешь воспитывать "компьютерщиков", кторые ВСЕ ЗНАЮТ, ничего не выйдет... Слишком большая производная объема необходимых знаний...
Ты чуть-чуть не понял.
Дело совсем не в том, что нет специалистов, которые разбираются во всех системах. И не в том, что надо воспитывать компьютерщиков, которые все знают. И не было никогда тех, кто хорошо знал все. И раньше тоже были узкие специалисты. Нет, речь совсем не о том.
Речь о том, что сейчас при воспитывании не показывают ничего кроме POSIX/C (сюда же вписывай все *nix, Windows *, DOS, C++, Java, C#, и кучу другой ерунды). Никто даже не подозревает, что бывает подругому. А те, кто не знает, что бывает подругому - им сложнее придумывать действительно новые и оригинальные концепции. Вот в чем проблема.
Дело совсем не в том, что нет специалистов, которые разбираются во всех системах. И не в том, что надо воспитывать компьютерщиков, которые все знают. И не было никогда тех, кто хорошо знал все. И раньше тоже были узкие специалисты. Нет, речь совсем не о том.
Речь о том, что сейчас при воспитывании не показывают ничего кроме POSIX/C (сюда же вписывай все *nix, Windows *, DOS, C++, Java, C#, и кучу другой ерунды). Никто даже не подозревает, что бывает подругому. А те, кто не знает, что бывает подругому - им сложнее придумывать действительно новые и оригинальные концепции. Вот в чем проблема.
> сейчас при воспитывании не показывают ничего кроме POSIX/C (сюда же вписывай все *nix, Windows *, DOS,
> C++, Java, C#, и кучу другой ерунды).
А почему, например, Microsoft не сохранило непохожесть своих систем?
Изначально там ведь и позиксом не пахло, и были слухи, что не на С писалось...
И что делать предлагается? Силой навязывать кому-то квадратные колёса вместо круглых?
(Почему кстати весь наземный транспорт - колёсный, разве это не затрудняет придумывание новых концепций?)
> C++, Java, C#, и кучу другой ерунды).
А почему, например, Microsoft не сохранило непохожесть своих систем?
Изначально там ведь и позиксом не пахло, и были слухи, что не на С писалось...
И что делать предлагается? Силой навязывать кому-то квадратные колёса вместо круглых?
(Почему кстати весь наземный транспорт - колёсный, разве это не затрудняет придумывание новых концепций?)
Речь о том, что сейчас при воспитывании не показывают ничего кроме POSIX/C (сюда же вписывай все *nix, Windows *, DOS, C++, Java, C#, и кучу другой ерунды). Никто даже не подозревает, что бывает подругому. А те, кто не знает, что бывает подругому - им сложнее придумывать действительно новые и оригинальные концепции. Вот в чем проблема.По-моему все эту пустой треп. Кому не нравится - есть куча других языков и платформ. Программируйте на них сколько угодно, только не жалуйтесь, у вас что-то идет не так, как у всех.
(Почему кстати весь наземный транспорт - колёсный, разве это не затрудняет придумывание новых концепций?)Обожаю автомобильные аналогии в IT флеймах. Да, Лео, почему все ездят на машинах и только очень редкие индивидуумы могут позволить себе использовать в качестве средства передвижения личный самолет или колхозный трактор?
Да, Лео, почему все ездят на машинах и только очень редкие индивидуумы могут позволить себе использовать в качестве средства передвижения личный самолет или колхозный трактор?
Хотите аналогий? Хорошо, вперед.
Трактор, машина, тележка - это все одно и то же. Ездить на чем-либо отличном от машины сейчас, когда она обладает наилучшем соотношением цена/качество никто не заставляет, и не говорит, что это хорошо. Но вот только все знают, что кроме машин еще бывают лошади, самолеты, корабли. А вот в компьютерном мире ситуация стала складываться таким образом, что новые специалисты уже не знают, что бывают самолеты, лошади и корабли. Они знают, что бывают машины, с разными объемами двигателей, и разными моделями колес (типа "трактор" или "телега"). И если такому специалисту дать время, деньги и полет фантазии, то он, конечно, придумает еще одну машину. Или даже две. Но пока он придумает что-то концептуально новое, например тот же самолет, уйдет много времени. Гораздо больше времени, чем если бы он знал, что бывает что-то кроме машин.
А вот почему в сфере ОС все остальные варианты отмирают?
В любом случае, если специалисту не рассказывают, что бывают/были и другие системы, значит плохо готовят.
В любом случае, если специалисту не рассказывают, что бывают/были и другие системы, значит плохо готовят.
А вот почему в сфере ОС все остальные варианты отмирают?
Так считают те, кто о них мало слышал. Они не отмирают совсем, они занимают свою нишу, и продолжают работать. Как очень стабильно работающие решения, которые были сделаны давно, и которые не хочется менять. Я не говорю, что сейчас следует делать так же, как тогда, когда создавались эти решения. Но рассказывать о том, что так бывает надо обязательно. А вот этого, как раз, практически не делают... Очень зря.
> Они не отмирают совсем, они занимают свою нишу, и продолжают работать. Как очень стабильно работающие решения,
> которые были сделаны давно, и которые не хочется менять.
Это же legacy.
Но где тут развитие?
Продолжают работать - это не то же самое, что продолжают жить.
А вот для новых применений всё больше юникс- и виндовс-подобные системы используются.
Наверное, это связано с распространением открытых стандартов и открытых протоколов.
Например, если у тебя нет файловой системе типа как в юниксе - уже ftp и http не очень-то поиспользуешь.
> которые были сделаны давно, и которые не хочется менять.
Это же legacy.
Но где тут развитие?
Продолжают работать - это не то же самое, что продолжают жить.
А вот для новых применений всё больше юникс- и виндовс-подобные системы используются.
Наверное, это связано с распространением открытых стандартов и открытых протоколов.
Например, если у тебя нет файловой системе типа как в юниксе - уже ftp и http не очень-то поиспользуешь.
Это же legacy.
Но где тут развитие?
Продолжают работать - это не то же самое, что продолжают жить.
А вот для новых применений всё больше юникс- и виндовс-подобные системы используются.
Опять. Я не пытаюсь говорить о том, что нужно использовать. Никто не говорит, что ездить на телеге правильно, потому, что это надежно. И распространенность машин, хотя и привела к тому, что падают и ломаются они чаще телег, не является злом. Но нужно хотя бы рассказывать, что бывают телеги, бывают параходы, и бывают самолеты...
Мне один администратор линуксов как-то пожаловался,
что в конторе начальство требует закомментаривать старые настройки,
писать новые и примечания к ним: кто, когда и зачем.
Недавно в ньюсах эта тема проскакивала: разграничение обязанностей между админами, сосуществование, версии и прочее. Кажется, это было в fido7.ru.unix. Как я понял, даже решения были предложены. Был и скриптик на перле, который отслеживал какие файлы и кем были изменены, бэкапил это дело и отсылал всем админам репорты.
Меня удивляет то, что они не смогли додуматься использовать для этого
такую совершенно необычную для нашего времени вещь, как RCS.
Кажется, упомянутое мной решение использовало cvs.
Хм, а разве об этом не рассказывают на том же ВМК? Помнится, на первом курсе (мех-мат) мы работали на vax. Признаюсь, ничего я оттуда не вынес кроме головной боли от ужасных "зеленых" экранов. Я тогда думал только о том, чтобы поскорее прак сдать и послать все это на... Разумеется, были люди, которые в них копались, даже системным программированием кто-то из моих сокурсников занимался, и эти последние вполне лестно и даже с восторгом отзывались о своих "игрушках".
Мне недавно довелось поработать на IBM OS-400: DSP-файлы, RPG, позиционное программирование и пр. - то еще счастье! Но, да, эти машины хорошо работают и для базы данных "Альфа-банка" пока трудно найти достойную замену. Но, черт возьми, какой же титанический труд был вложен в эту систему! Предусмотреть все, что захочет сделать пользователь и под все написать интерфейс. Вот тогда-то я и понял, почему Брукс с таким вдохновением описывает необходимость тотального документирования проекта ... несколько метров (в толщину) мануала для Голубого Гиганта, конечно, не предел. Кстати, именно в этой ветке появилось понятие (и было успешно реализовано) байткода - предтеча идеологии Java.
Мне недавно довелось поработать на IBM OS-400: DSP-файлы, RPG, позиционное программирование и пр. - то еще счастье! Но, да, эти машины хорошо работают и для базы данных "Альфа-банка" пока трудно найти достойную замену. Но, черт возьми, какой же титанический труд был вложен в эту систему! Предусмотреть все, что захочет сделать пользователь и под все написать интерфейс. Вот тогда-то я и понял, почему Брукс с таким вдохновением описывает необходимость тотального документирования проекта ... несколько метров (в толщину) мануала для Голубого Гиганта, конечно, не предел. Кстати, именно в этой ветке появилось понятие (и было успешно реализовано) байткода - предтеча идеологии Java.
> Версионная файловая система - это действительно очень удобно и полезно.
> Я не слышал о ее реализациях в системах новее, чем VMS. Поэтому я и написал,
> что для того, чтобы понять что же это такое суперудобное - лучше хотя бы чуть-чуть поработать под VMS.
Сам не работал, но знаю, что не все жертвы так тепло отзываются об этом.
Действительно, несколько проблем можно сходу указать.
* Копии файлов быстро съедают дисковое пространство, значит надо их чистить, а это уже труднее автоматизировать.
* Если тупо перенести это в современные системы, где файлы плоские, работать будет очень плохо. Прикинь, любая модификация
какого-либо бинарного файла (например, чего-то вроде berkley db приводила бы к созданию копии, это совершенно недопустимо.
Значит, приложение должно иметь возможность указать, что вот эта конкретная модификация не должна приводить к созданию
новой версии. То есть, имеем уже два способа работы с файлами. Теперь, более сложный механизм управления версиями
(хотя бы типа cvs) всё равно будет нужен, так как возможностей автоматически-создаваемых-на-каждый-чих
линейно-упорядоченных нумерованных версий хватает лишь для очень ограниченного круга задач (кроме текстовых файлов,
редактируемых человеком по отдельности, ничего даже в голову не приходит).
Получаем:
1. в ОС есть способ доступа к файлам без поддержки версий, и он нужен
2. есть системы управления версиями, и они не лишние
3. есть задачи, для которых нужен какая-то автоматическая и примитивная поддержка версий
4. как мы договорились, задачи из п.3 будут использовать другой вид доступа к файлам, чем упомянутый в п.1
5. решение: пусть задачи из п.3 работают с помощью систем из п.2, ура!
То есть, нужно научить текстовый редактор вызывать rcs при сохранении файла, и проблемы больше нет.
> Я не слышал о ее реализациях в системах новее, чем VMS. Поэтому я и написал,
> что для того, чтобы понять что же это такое суперудобное - лучше хотя бы чуть-чуть поработать под VMS.
Сам не работал, но знаю, что не все жертвы так тепло отзываются об этом.
Действительно, несколько проблем можно сходу указать.
* Копии файлов быстро съедают дисковое пространство, значит надо их чистить, а это уже труднее автоматизировать.
* Если тупо перенести это в современные системы, где файлы плоские, работать будет очень плохо. Прикинь, любая модификация
какого-либо бинарного файла (например, чего-то вроде berkley db приводила бы к созданию копии, это совершенно недопустимо.
Значит, приложение должно иметь возможность указать, что вот эта конкретная модификация не должна приводить к созданию
новой версии. То есть, имеем уже два способа работы с файлами. Теперь, более сложный механизм управления версиями
(хотя бы типа cvs) всё равно будет нужен, так как возможностей автоматически-создаваемых-на-каждый-чих
линейно-упорядоченных нумерованных версий хватает лишь для очень ограниченного круга задач (кроме текстовых файлов,
редактируемых человеком по отдельности, ничего даже в голову не приходит).
Получаем:
1. в ОС есть способ доступа к файлам без поддержки версий, и он нужен
2. есть системы управления версиями, и они не лишние
3. есть задачи, для которых нужен какая-то автоматическая и примитивная поддержка версий
4. как мы договорились, задачи из п.3 будут использовать другой вид доступа к файлам, чем упомянутый в п.1
5. решение: пусть задачи из п.3 работают с помощью систем из п.2, ура!
То есть, нужно научить текстовый редактор вызывать rcs при сохранении файла, и проблемы больше нет.
Да, я уже забиндил запись и 'cvs ci -m "" %' на функциональную кнопень в vim'е.
PS: А контра пусть и дальше считает число нажатий в емаксе.
Narrowness of experience leads to narrowness of imagination. ГыГыГы.
PS: А контра пусть и дальше считает число нажатий в емаксе.
Narrowness of experience leads to narrowness of imagination. ГыГыГы.
Согласен. Для файлов есть RCS. А снапшоты пусть будут на уровне раздела, а не файла.
Народ, гдя я это подслушал?
"Unix - это интерфейс командной строки, развитый до совершенства".
Такая мысль сегодня посетила...
"Unix - это интерфейс командной строки, развитый до совершенства".
Такая мысль сегодня посетила...
Это скорее про MUD. Там целый мир тебе доступен через командную строку
"...Ибо не ведают..."
---
...Я работаю антинаучным аферистом...
---
...Я работаю антинаучным аферистом...
Твои "incremental dumps" каким образом вызываются?
А "snapshots" как делаются?
---
...Я работаю антинаучным аферистом...
А "snapshots" как делаются?
---
...Я работаю антинаучным аферистом...
> А вот почему в сфере ОС все остальные варианты отмирают?
Ты точно статью прочёл?
---
"...Надо учиться --- не напрягаясь!.." Акад. А. А. Бучаченко.
Ты точно статью прочёл?
---
"...Надо учиться --- не напрягаясь!.." Акад. А. А. Бучаченко.
Про СРВ слышал?
Ничего, что в самых ответственных случаях до сих пор используют согласующую многозадачность?
Даже на заказ пишут.
---
...Я работаю антинаучным аферистом...
Ничего, что в самых ответственных случаях до сих пор используют согласующую многозадачность?
Даже на заказ пишут.
---
...Я работаю антинаучным аферистом...
> Про СРВ слышал?
Это нишевые задачи.
И то стараются юникс-подобно всё делать вроде бы.
Смотрим:
VxWorks: http://www.windriver.com/products/device_technologies/os/vxworks5/
# Full ANSI C compliance and enhanced C++ features for exception handling and template support
# Extensive POSIX 1003.1, .1b, .1c compatibility (including pThreads)
QNX: http://www.qnx.com/products/rtos/
maximize application portability with extensive support for the POSIX standard, which lets you quickly migrate Linux, Unix, and other open source programs
Это ведь самые популярные ОСРВ, так?
> Ничего, что в самых ответственных случаях до сих пор используют согласующую многозадачность?
Ничего, одобряю
В юникс-подобных ОС внутри ядра как правило так и есть.
Статью не читал, ломает
Это нишевые задачи.
И то стараются юникс-подобно всё делать вроде бы.
Смотрим:
VxWorks: http://www.windriver.com/products/device_technologies/os/vxworks5/
# Full ANSI C compliance and enhanced C++ features for exception handling and template support
# Extensive POSIX 1003.1, .1b, .1c compatibility (including pThreads)
QNX: http://www.qnx.com/products/rtos/
maximize application portability with extensive support for the POSIX standard, which lets you quickly migrate Linux, Unix, and other open source programs
Это ведь самые популярные ОСРВ, так?
> Ничего, что в самых ответственных случаях до сих пор используют согласующую многозадачность?
Ничего, одобряю
В юникс-подобных ОС внутри ядра как правило так и есть.
Статью не читал, ломает
> * Копии файлов быстро съедают дисковое пространство,
> значит надо их чистить, а это уже труднее автоматизировать.
Хранится сколько-то последних версий.
> * Если тупо перенести это в современные системы, где файлы плоские,
Не использовать плоские файлы.
> Значит, приложение должно иметь возможность указать,
> что вот эта конкретная модификация не должна приводить к созданию
> новой версии.
Это уже было.
> То есть, имеем уже два способа работы с файлами.
Сколько дополнительных битов принимает open в твоём UNIX?
> То есть, нужно научить текстовый редактор вызывать rcs
> при сохранении файла, и проблемы больше нет.
Изобрёл vc-mode.
Молодец.
Что будет, если я сделаю так:
prog-name вход | awk 'чего-то-там' > выход ?
Всё время набивать ci/co?
---
"Narrowness of experience leads to narrowness of imagination."
Rob Pike
> значит надо их чистить, а это уже труднее автоматизировать.
Хранится сколько-то последних версий.
> * Если тупо перенести это в современные системы, где файлы плоские,
Не использовать плоские файлы.
> Значит, приложение должно иметь возможность указать,
> что вот эта конкретная модификация не должна приводить к созданию
> новой версии.
Это уже было.
> То есть, имеем уже два способа работы с файлами.
Сколько дополнительных битов принимает open в твоём UNIX?
> То есть, нужно научить текстовый редактор вызывать rcs
> при сохранении файла, и проблемы больше нет.
Изобрёл vc-mode.
Молодец.
Что будет, если я сделаю так:
prog-name вход | awk 'чего-то-там' > выход ?
Всё время набивать ci/co?
---
"Narrowness of experience leads to narrowness of imagination."
Rob Pike
Молодец.
Изобретай vc-mode дальше.
---
"Narrowness of experience leads to narrowness of imagination."
Rob Pike
Изобретай vc-mode дальше.
---
"Narrowness of experience leads to narrowness of imagination."
Rob Pike
Униксоиды --- да.
Стараются.
Инженеры ругаются на них по-чёрному.
Большой перерасход ресурсов.
Про VxWorks сразу не скажу, а QnX не самая лучшая ОС РВ.
Она "self-hosted," что серьёзно, очень сильно повышает требования к ресурсам.
А статью почитай.
Может, что-то новое вынесешь.
---
"Narrowness of experience leads to narrowness of imagination."
Rob Pike
Стараются.
Инженеры ругаются на них по-чёрному.
Большой перерасход ресурсов.
Про VxWorks сразу не скажу, а QnX не самая лучшая ОС РВ.
Она "self-hosted," что серьёзно, очень сильно повышает требования к ресурсам.
А статью почитай.
Может, что-то новое вынесешь.
---
"Narrowness of experience leads to narrowness of imagination."
Rob Pike
> Хранится сколько-то последних версий.
Х№йня выходит.
Допустим, я в редакторе сделал 15 мелких правок, и каждый раз сохранял файл.
Вышло 15 версий.
А потом захотел откатиться к состоянию на вчера, а поздно, так как система настроена на хранение 10 последних версий.
> Не использовать плоские файлы.
А другие через сеть не передашь, такие протоколы, придуманные юниксоидами.
С файлами сложной структуры можно работать, используя соответствующие библиотеки,
в которые запросто можно встроить поддержку версионности, если нужно.
> Сколько дополнительных битов принимает open в твоём UNIX?
А нафиг модифицировать open когда в юзер-спейсе можно всё сделать?
> Изобрёл vc-mode.
> Молодец.
Как бы не я, а другие грамотные люди, раньше
> Что будет, если я сделаю так:
> prog-name вход | awk 'чего-то-там' > выход ?
В духе твоего совета выше: не делай так
> Всё время набивать ci/co?
Если файлы редактируются руками, то запускай awk из емакса с vc-mode.
Если файлы генерируются автоматически, то версии им не нужны, так как уже есть у исходников.
> Инженеры ругаются на них по-чёрному.
> Большой перерасход ресурсов.
Чьих ресурсов? Компьютера? Так он же железный.
Человеческие ресурсы более ценны, их и экономят.
> А статью почитай.
сцылка?
Х№йня выходит.
Допустим, я в редакторе сделал 15 мелких правок, и каждый раз сохранял файл.
Вышло 15 версий.
А потом захотел откатиться к состоянию на вчера, а поздно, так как система настроена на хранение 10 последних версий.
> Не использовать плоские файлы.
А другие через сеть не передашь, такие протоколы, придуманные юниксоидами.
С файлами сложной структуры можно работать, используя соответствующие библиотеки,
в которые запросто можно встроить поддержку версионности, если нужно.
> Сколько дополнительных битов принимает open в твоём UNIX?
А нафиг модифицировать open когда в юзер-спейсе можно всё сделать?
> Изобрёл vc-mode.
> Молодец.
Как бы не я, а другие грамотные люди, раньше
> Что будет, если я сделаю так:
> prog-name вход | awk 'чего-то-там' > выход ?
В духе твоего совета выше: не делай так
> Всё время набивать ci/co?
Если файлы редактируются руками, то запускай awk из емакса с vc-mode.
Если файлы генерируются автоматически, то версии им не нужны, так как уже есть у исходников.
> Инженеры ругаются на них по-чёрному.
> Большой перерасход ресурсов.
Чьих ресурсов? Компьютера? Так он же железный.
Человеческие ресурсы более ценны, их и экономят.
> А статью почитай.
сцылка?
>> Хранится сколько-то последних версий.
> Допустим,
Либо настраивается, чтобы побольше, либо удаляются промежуточные.
Медленный способ --- хранить разности.
То есть "RCS inside."
>> Не использовать плоские файлы.
> А другие через сеть не передашь,
> такие протоколы, придуманные юниксоидами.
Промежуточный вид можно изобрести любой.
Кроме того, я что-то не помню, чтобы EtherNet был придуман униксоидами или чтобы он был потоковым.
> С файлами сложной структуры можно работать,
> используя соответствующие библиотеки,
> в которые запросто можно встроить поддержку версионности, если нужно.
Хорошо.
Вот и встройте эти библиотеки в ядро.
>> Сколько дополнительных битов принимает open в твоём UNIX?
> А нафиг модифицировать open когда в юзер-спейсе можно всё сделать?
Я пока не понял, как это выглядит "в юзер-спейсе."
Ты пытаешься сделать что-то вроде микроядра?
>> Что будет, если я сделаю так:
>> prog-name вход | awk 'чего-то-там' > выход ?
> В духе твоего совета выше: не делай так
Есть разница между низкоуровневым и высокоуровневым.
Ты же не отправляешь эфирные кадры вручную?
Почему-то через HTTP-TCP-IP?
>> Всё время набивать ci/co?
> Если файлы редактируются руками, то запускай awk из емакса с vc-mode.
Ознакомься с тем, как работает vc-mode.
Тогда и поймёшь, почему версионность должна поддерживаться ОС,
а не оболочками, средами или текстовыми редакторами.
> Если файлы генерируются автоматически, то версии им не нужны,
> так как уже есть у исходников.
Программа для awk в примере может меняться пользователем.
Так что выходной файл создаётся при непосредственном участии человека,
хотя и опосредованно.
>> Инженеры ругаются на них по-чёрному.
>> Большой перерасход ресурсов.
> Чьих ресурсов? Компьютера?
Микропроцессора и вообще всей обвязки.
Они хотя и кремниевые, но не самые дешёвые.
Либо выходят за рамки ограничений.
>> А статью почитай.
> сцылка?
Уже приведена выше.
Даже две.
---
...Я работаю антинаучным аферистом...
> Допустим,
Либо настраивается, чтобы побольше, либо удаляются промежуточные.
Медленный способ --- хранить разности.
То есть "RCS inside."
>> Не использовать плоские файлы.
> А другие через сеть не передашь,
> такие протоколы, придуманные юниксоидами.
Промежуточный вид можно изобрести любой.
Кроме того, я что-то не помню, чтобы EtherNet был придуман униксоидами или чтобы он был потоковым.
> С файлами сложной структуры можно работать,
> используя соответствующие библиотеки,
> в которые запросто можно встроить поддержку версионности, если нужно.
Хорошо.
Вот и встройте эти библиотеки в ядро.
>> Сколько дополнительных битов принимает open в твоём UNIX?
> А нафиг модифицировать open когда в юзер-спейсе можно всё сделать?
Я пока не понял, как это выглядит "в юзер-спейсе."
Ты пытаешься сделать что-то вроде микроядра?
>> Что будет, если я сделаю так:
>> prog-name вход | awk 'чего-то-там' > выход ?
> В духе твоего совета выше: не делай так
Есть разница между низкоуровневым и высокоуровневым.
Ты же не отправляешь эфирные кадры вручную?
Почему-то через HTTP-TCP-IP?
>> Всё время набивать ci/co?
> Если файлы редактируются руками, то запускай awk из емакса с vc-mode.
Ознакомься с тем, как работает vc-mode.
Тогда и поймёшь, почему версионность должна поддерживаться ОС,
а не оболочками, средами или текстовыми редакторами.
> Если файлы генерируются автоматически, то версии им не нужны,
> так как уже есть у исходников.
Программа для awk в примере может меняться пользователем.
Так что выходной файл создаётся при непосредственном участии человека,
хотя и опосредованно.
>> Инженеры ругаются на них по-чёрному.
>> Большой перерасход ресурсов.
> Чьих ресурсов? Компьютера?
Микропроцессора и вообще всей обвязки.
Они хотя и кремниевые, но не самые дешёвые.
Либо выходят за рамки ограничений.
>> А статью почитай.
> сцылка?
Уже приведена выше.
Даже две.
---
...Я работаю антинаучным аферистом...
> То есть "RCS inside."
Зачем делать inside, когда уже есть один outside?
> Промежуточный вид можно изобрести любой.
И для каждого формата писать свои конвертеры?
> Кроме того, я что-то не помню, чтобы EtherNet был придуман униксоидами или чтобы он был потоковым.
Всякие там FTP и HTTP, которые используются для передачи файлов.
> Вот и встройте эти библиотеки в ядро.
Им там не место, так как они отлично себя могут чувствовать в юзер-спейсе.
> Ознакомься с тем, как работает vc-mode.
На что конкретно смотреть?
> Тогда и поймёшь, почему версионность должна поддерживаться ОС,
> а не оболочками, средами или текстовыми редакторами.
"Оболочки и среды" - это часть ОС. Даже afaik в вашей VMS
> Я пока не понял, как это выглядит "в юзер-спейсе."
Хотя бы libvc.so
Не говоря уж о вызовах /usr/bin/c{i,o}
> Программа для awk в примере может меняться пользователем.
Вот у этой программы и будут версии.
Как и у других исходников.
Так мы подошли к другому требованию - версии для проекта целиком,
а не для каждого файла в отдельности.
Что в VMS для этого?
> Микропроцессора и вообще всей обвязки.
> Они хотя и кремниевые, но не самые дешёвые.
> Либо выходят за рамки ограничений.
Как только появляются достаточно производительные процессоры,
чтобы пускать там unix-like, сразу они начинают теснить всё остальное.
Ну сейчас ещё WinCE или что там ещё есть.
Зачем делать inside, когда уже есть один outside?
> Промежуточный вид можно изобрести любой.
И для каждого формата писать свои конвертеры?
> Кроме того, я что-то не помню, чтобы EtherNet был придуман униксоидами или чтобы он был потоковым.
Всякие там FTP и HTTP, которые используются для передачи файлов.
> Вот и встройте эти библиотеки в ядро.
Им там не место, так как они отлично себя могут чувствовать в юзер-спейсе.
> Ознакомься с тем, как работает vc-mode.
На что конкретно смотреть?
> Тогда и поймёшь, почему версионность должна поддерживаться ОС,
> а не оболочками, средами или текстовыми редакторами.
"Оболочки и среды" - это часть ОС. Даже afaik в вашей VMS
> Я пока не понял, как это выглядит "в юзер-спейсе."
Хотя бы libvc.so
Не говоря уж о вызовах /usr/bin/c{i,o}
> Программа для awk в примере может меняться пользователем.
Вот у этой программы и будут версии.
Как и у других исходников.
Так мы подошли к другому требованию - версии для проекта целиком,
а не для каждого файла в отдельности.
Что в VMS для этого?
> Микропроцессора и вообще всей обвязки.
> Они хотя и кремниевые, но не самые дешёвые.
> Либо выходят за рамки ограничений.
Как только появляются достаточно производительные процессоры,
чтобы пускать там unix-like, сразу они начинают теснить всё остальное.
Ну сейчас ещё WinCE или что там ещё есть.
статью (если так можно назвать powerpoint-style презентацию) заботал
она состоит из двух частей:
1. что происходит
2. что делать
(1) - тривиальные наблюдения, очевидные выводы
(2) - бессмысленно, так как не сказано, зачем это нужно
она состоит из двух частей:
1. что происходит
2. что делать
(1) - тривиальные наблюдения, очевидные выводы
(2) - бессмысленно, так как не сказано, зачем это нужно
>> То есть "RCS inside."
> Зачем делать inside, когда уже есть один outside?
Потому что он никак не спасает.
>> Промежуточный вид можно изобрести любой.
> И для каждого формата писать свои конвертеры?
Только почему-то ``uuencode'' один.
>> Кроме того, я что-то не помню,
>> чтобы EtherNet был придуман униксоидами или чтобы он был потоковым.
> Всякие там FTP и HTTP, которые используются для передачи файлов.
Ты забыл добавить: которые сделаны для того, чтобы передавать через IP или UDP поблочно.
>> Вот и встройте эти библиотеки в ядро.
> Им там не место, так как они отлично себя могут чувствовать в юзер-спейсе.
Так как будет работать внешняя программа?
См. пример с awk.
Я хотел бы управлять сохранением версий на уровне файла.
То есть заявить: "для этого файла хранить столько-то последних версий, изменение по умолчанию создаёт новую."
>> Ознакомься с тем, как работает vc-mode.
> На что конкретно смотреть?
На пример с awk.
>> Тогда и поймёшь, почему версионность должна поддерживаться ОС,
>> а не оболочками, средами или текстовыми редакторами.
> "Оболочки и среды" - это часть ОС. Даже afaik в вашей VMS
Например, Emacs --- это часть ОС?
Если "да," то которой.
>> Я пока не понял, как это выглядит "в юзер-спейсе."
> Хотя бы libvc.so
> Не говоря уж о вызовах /usr/bin/c{i,o}
Хорошо.
Будет ли open("file-name", O_WRITE) создавать новую версию?
То, что в Униксе это не так, не сказать, чтобы было очень неудобно,
но было бы удобнее, если бы это определялось свойствами файла.
>> Программа для awk в примере может меняться пользователем.
> Вот у этой программы и будут версии.
Ты записываешь все свои рабочие команды?
"Это глупость вообще, но мне это знакомая песня."
У меня возникло подозрение, что ты незнаком с awk и с тем,
зачем он по большей части нужен.
> Как и у других исходников.
> Так мы подошли к другому требованию - версии для проекта целиком,
> а не для каждого файла в отдельности.
Про literate programming помнишь?
> Что в VMS для этого?
Напомню, что мы рассматриваем недостатки UNIX, а не VMS.
Там тоже есть своя VCS.
>> Микропроцессора и вообще всей обвязки.
>> Они хотя и кремниевые, но не самые дешёвые.
>> Либо выходят за рамки ограничений.
> Как только появляются достаточно производительные процессоры,
> чтобы пускать там unix-like
Они начинают жрать столько энергии, что их просто нельзя использовать.
---
...Я работаю антинаучным аферистом...
> Зачем делать inside, когда уже есть один outside?
Потому что он никак не спасает.
>> Промежуточный вид можно изобрести любой.
> И для каждого формата писать свои конвертеры?
Только почему-то ``uuencode'' один.
>> Кроме того, я что-то не помню,
>> чтобы EtherNet был придуман униксоидами или чтобы он был потоковым.
> Всякие там FTP и HTTP, которые используются для передачи файлов.
Ты забыл добавить: которые сделаны для того, чтобы передавать через IP или UDP поблочно.
>> Вот и встройте эти библиотеки в ядро.
> Им там не место, так как они отлично себя могут чувствовать в юзер-спейсе.
Так как будет работать внешняя программа?
См. пример с awk.
Я хотел бы управлять сохранением версий на уровне файла.
То есть заявить: "для этого файла хранить столько-то последних версий, изменение по умолчанию создаёт новую."
>> Ознакомься с тем, как работает vc-mode.
> На что конкретно смотреть?
На пример с awk.
>> Тогда и поймёшь, почему версионность должна поддерживаться ОС,
>> а не оболочками, средами или текстовыми редакторами.
> "Оболочки и среды" - это часть ОС. Даже afaik в вашей VMS
Например, Emacs --- это часть ОС?
Если "да," то которой.
>> Я пока не понял, как это выглядит "в юзер-спейсе."
> Хотя бы libvc.so
> Не говоря уж о вызовах /usr/bin/c{i,o}
Хорошо.
Будет ли open("file-name", O_WRITE) создавать новую версию?
То, что в Униксе это не так, не сказать, чтобы было очень неудобно,
но было бы удобнее, если бы это определялось свойствами файла.
>> Программа для awk в примере может меняться пользователем.
> Вот у этой программы и будут версии.
Ты записываешь все свои рабочие команды?
"Это глупость вообще, но мне это знакомая песня."
У меня возникло подозрение, что ты незнаком с awk и с тем,
зачем он по большей части нужен.
> Как и у других исходников.
> Так мы подошли к другому требованию - версии для проекта целиком,
> а не для каждого файла в отдельности.
Про literate programming помнишь?
> Что в VMS для этого?
Напомню, что мы рассматриваем недостатки UNIX, а не VMS.
Там тоже есть своя VCS.
>> Микропроцессора и вообще всей обвязки.
>> Они хотя и кремниевые, но не самые дешёвые.
>> Либо выходят за рамки ограничений.
> Как только появляются достаточно производительные процессоры,
> чтобы пускать там unix-like
Они начинают жрать столько энергии, что их просто нельзя использовать.
---
...Я работаю антинаучным аферистом...
Ты тоже веришь, что UNIX, оно "user friendly?"
Даже если под пользователем понимать умелого пользователя?
---
...Я работаю антинаучным аферистом...
Даже если под пользователем понимать умелого пользователя?
---
...Я работаю антинаучным аферистом...
> Только почему-то ``uuencode'' один.
Тот, uuencode, который я видел, обрабатывает только плоские файлы
(потому что в dos и unix других нет)
Насколько я понимаю, выходной формат у него такой, что для дополнительной структуры места нет.
> > Всякие там FTP и HTTP, которые используются для передачи файлов.
> Ты забыл добавить: которые сделаны для того, чтобы передавать через IP или UDP поблочно.
Садись, двойка.
Если бы ты хоть немного понимал, что говоришь, UDP не приплёл бы сюда.
То, что для передачи по TCP поток разбивается на пакеты не имеет никакого отношения
к структуре передаваемых данных.
Передаётся byte stream.
> Так как будет работать внешняя программа?
> См. пример с awk.
Из emacs запускаешь awk как фильтр, результат сохраняешь.
> Будет ли open("file-name", O_WRITE) создавать новую версию?
> То, что в Униксе это не так, не сказать, чтобы было очень неудобно,
> но было бы удобнее, если бы это определялось свойствами файла.
Для каких-то случаев удобно, а для других нет.
А почему ты хочешь именно open?
В твоём примере с фильтром на awk вообще open может делать именно оболочка
> Ты записываешь все свои рабочие команды?
> "Это глупость вообще, но мне это знакомая песня."
> У меня возникло подозрение, что ты незнаком с awk и с тем,
> зачем он по большей части нужен.
Если тебя не заломало скрипт на несколько строчек руками набрать, то ci тоже как-нибудь наберёшь.
К тому же, как мы договорись, это за тебя емакс сделает.
> Напомню, что мы рассматриваем недостатки UNIX, а не VMS.
Ну а если оказывается, что от "исправления" этих недостатков возникают другие, ещё страшнее?
> Например, Emacs --- это часть ОС?
> Если "да," то которой.
Имхо всех.
> Они начинают жрать столько энергии, что их просто нельзя использовать.
И Java, и WinCE бывают например в сотовых телефонах afaik.
unix-like тоже могли бы быть, если бы были нужны.
Тот, uuencode, который я видел, обрабатывает только плоские файлы
(потому что в dos и unix других нет)
Насколько я понимаю, выходной формат у него такой, что для дополнительной структуры места нет.
> > Всякие там FTP и HTTP, которые используются для передачи файлов.
> Ты забыл добавить: которые сделаны для того, чтобы передавать через IP или UDP поблочно.
Садись, двойка.
Если бы ты хоть немного понимал, что говоришь, UDP не приплёл бы сюда.
То, что для передачи по TCP поток разбивается на пакеты не имеет никакого отношения
к структуре передаваемых данных.
Передаётся byte stream.
> Так как будет работать внешняя программа?
> См. пример с awk.
Из emacs запускаешь awk как фильтр, результат сохраняешь.
> Будет ли open("file-name", O_WRITE) создавать новую версию?
> То, что в Униксе это не так, не сказать, чтобы было очень неудобно,
> но было бы удобнее, если бы это определялось свойствами файла.
Для каких-то случаев удобно, а для других нет.
А почему ты хочешь именно open?
В твоём примере с фильтром на awk вообще open может делать именно оболочка
> Ты записываешь все свои рабочие команды?
> "Это глупость вообще, но мне это знакомая песня."
> У меня возникло подозрение, что ты незнаком с awk и с тем,
> зачем он по большей части нужен.
Если тебя не заломало скрипт на несколько строчек руками набрать, то ci тоже как-нибудь наберёшь.
К тому же, как мы договорись, это за тебя емакс сделает.
> Напомню, что мы рассматриваем недостатки UNIX, а не VMS.
Ну а если оказывается, что от "исправления" этих недостатков возникают другие, ещё страшнее?
> Например, Emacs --- это часть ОС?
> Если "да," то которой.
Имхо всех.
> Они начинают жрать столько энергии, что их просто нельзя использовать.
И Java, и WinCE бывают например в сотовых телефонах afaik.
unix-like тоже могли бы быть, если бы были нужны.
Какое отношение это имеет к "статье"?
Да, в некоторой степени.
Да, в некоторой степени.
> Насколько я понимаю, выходной формат у него такой, что для
> дополнительной структуры места нет.
Придумать единообразное представление особого труда не составляет.
XML тоже ведь придумали.
Ещё и пропихивают так, что только отталкивать успевай.
> То, что для передачи по TCP поток разбивается на пакеты,
> не имеет никакого отношения к структуре передаваемых данных.
> Передаётся byte stream.
Передаётся в конечном счёте не "stream" и не "byte."
> Из emacs запускаешь awk как фильтр, результат сохраняешь.
Тогда уж и от awk можно отказаться.
Писать всё на елиспе.
Это, конечно, хорошо.
Только ты скатился к моему решению --- замена ОС, а не к униксоподобному.
Ты заменяешь "UNIX OS" на "Emacs OS."
Вроде того: "Symbolics forever!"
>> Будет ли open("file-name", O_WRITE) создавать новую версию?
>> То, что в Униксе это не так, не сказать, чтобы было очень неудобно,
>> но было бы удобнее, если бы это определялось свойствами файла.
> Для каких-то случаев удобно, а для других нет.
> А почему ты хочешь именно open?
> В твоём примере с фильтром на awk вообще open
> может делать именно оболочка
Да, это ты предлагаешь заменить ОС полностью.
То есть, все инструменты будут написаны на Лиспе и знать об встроенных возможностях сохранения версий.
А пользоваться средствами Уникса будет возможно, но опасно.
Сродни написанию драйверов с помощью "cat >file-name."
> Если тебя не заломало скрипт на несколько строчек руками набрать,
> то ci тоже как-нибудь наберёшь.
> К тому же, как мы договорись, это за тебя емакс сделает.
Ну, я же не такой извращенец, чтобы скрипт был чёрт знает какой.
Так что он вполне помещается на строке.
Сложность в том, что вызов awk с разной программой имеет смысл необходимости.
Таково решение непосредственной задачи.
А вот общение с RCS --- это совершенно далёкая от основной задача.
И она могла бы решаться ОС, а не пользователем.
>> Напомню, что мы рассматриваем недостатки UNIX, а не VMS.
> Ну а если оказывается, что от "исправления" этих недостатков
> возникают другие, ещё страшнее?
Я пока таких недостатков, за исключением сжирания дискового пространства, не видел.
Но кто из нас говорил, что железо дешевле?
>> Например, Emacs --- это часть ОС?
>> Если "да," то которой.
> Имхо всех.
Я не заметил, чтобы он стоял у всех.
Большинство униксоидов являются фанатичными приверженцами vi.
>> Они начинают жрать столько энергии, что их просто нельзя использовать.
> И Java, и WinCE бывают например в сотовых телефонах afaik.
> unix-like тоже могли бы быть, если бы были нужны.
У меня есть подозрение (плывёт по волнам моей памяти
что на МКС упала именно VxWorks.
Почему --- не помню.
После чего наши её заменили, вроде, каким-то заказным ПО.
Честно говоря, я не общаюсь с мобильными телефонами.
Кстати, у них не такие серьёзные ограничения на время и на питание.
Кому надо, тот будет таскать более тяжёлые аккумуляторы,
но в основном все бегают недалеко от электросети.
---
Всё в наших RU.KAX...
> дополнительной структуры места нет.
Придумать единообразное представление особого труда не составляет.
XML тоже ведь придумали.
Ещё и пропихивают так, что только отталкивать успевай.
> То, что для передачи по TCP поток разбивается на пакеты,
> не имеет никакого отношения к структуре передаваемых данных.
> Передаётся byte stream.
Передаётся в конечном счёте не "stream" и не "byte."
> Из emacs запускаешь awk как фильтр, результат сохраняешь.
Тогда уж и от awk можно отказаться.
Писать всё на елиспе.
Это, конечно, хорошо.
Только ты скатился к моему решению --- замена ОС, а не к униксоподобному.
Ты заменяешь "UNIX OS" на "Emacs OS."
Вроде того: "Symbolics forever!"
>> Будет ли open("file-name", O_WRITE) создавать новую версию?
>> То, что в Униксе это не так, не сказать, чтобы было очень неудобно,
>> но было бы удобнее, если бы это определялось свойствами файла.
> Для каких-то случаев удобно, а для других нет.
> А почему ты хочешь именно open?
> В твоём примере с фильтром на awk вообще open
> может делать именно оболочка
Да, это ты предлагаешь заменить ОС полностью.
То есть, все инструменты будут написаны на Лиспе и знать об встроенных возможностях сохранения версий.
А пользоваться средствами Уникса будет возможно, но опасно.
Сродни написанию драйверов с помощью "cat >file-name."
> Если тебя не заломало скрипт на несколько строчек руками набрать,
> то ci тоже как-нибудь наберёшь.
> К тому же, как мы договорись, это за тебя емакс сделает.
Ну, я же не такой извращенец, чтобы скрипт был чёрт знает какой.
Так что он вполне помещается на строке.
Сложность в том, что вызов awk с разной программой имеет смысл необходимости.
Таково решение непосредственной задачи.
А вот общение с RCS --- это совершенно далёкая от основной задача.
И она могла бы решаться ОС, а не пользователем.
>> Напомню, что мы рассматриваем недостатки UNIX, а не VMS.
> Ну а если оказывается, что от "исправления" этих недостатков
> возникают другие, ещё страшнее?
Я пока таких недостатков, за исключением сжирания дискового пространства, не видел.
Но кто из нас говорил, что железо дешевле?
>> Например, Emacs --- это часть ОС?
>> Если "да," то которой.
> Имхо всех.
Я не заметил, чтобы он стоял у всех.
Большинство униксоидов являются фанатичными приверженцами vi.
>> Они начинают жрать столько энергии, что их просто нельзя использовать.
> И Java, и WinCE бывают например в сотовых телефонах afaik.
> unix-like тоже могли бы быть, если бы были нужны.
У меня есть подозрение (плывёт по волнам моей памяти
что на МКС упала именно VxWorks.
Почему --- не помню.
После чего наши её заменили, вроде, каким-то заказным ПО.
Честно говоря, я не общаюсь с мобильными телефонами.
Кстати, у них не такие серьёзные ограничения на время и на питание.
Кому надо, тот будет таскать более тяжёлые аккумуляторы,
но в основном все бегают недалеко от электросети.
---
Всё в наших RU.KAX...
Прямое.
По-хорошему, униксоиды могли бы улучшить кучу разных вещей.
Но они этого не сделали.
И сомнительно, что сделают, пока их носом не ткнут.
Я, кстати, считаю что Уникс может быть куда более дружественным.
Вот только для этого надо немало переработать.
---
...Я работаю антинаучным аферистом...
По-хорошему, униксоиды могли бы улучшить кучу разных вещей.
Но они этого не сделали.
И сомнительно, что сделают, пока их носом не ткнут.
Я, кстати, считаю что Уникс может быть куда более дружественным.
Вот только для этого надо немало переработать.
---
...Я работаю антинаучным аферистом...
> Версионная файловая система - это
> действительно очень удобно и полезно. Я не
> слышал о ее реализациях в системах новее, чем
> VMS.
открой для себя NTFS
> действительно очень удобно и полезно. Я не
> слышал о ее реализациях в системах новее, чем
> VMS.
открой для себя NTFS
Ну-ка, ну-ка!
После "EDIT file-name" или "EDLIN file-name" получается ещё одна версия?
Какой командой можно сделать откат?
Хочу, например, такое:
copy file-name.ext;num other-name.ext /b
Пройдёт?
---
"Держи, товарищ,
порох сухим!"
После "EDIT file-name" или "EDLIN file-name" получается ещё одна версия?
Какой командой можно сделать откат?
Хочу, например, такое:
copy file-name.ext;num other-name.ext /b
Пройдёт?
---
"Держи, товарищ,
порох сухим!"
Твои "incremental dumps" каким образом вызываются?читайть dump(8) на любом юниксе не старее 10 лет
А "snapshots" как делаются?у меня mksnap_ffs(8 на других ОС по-другому
Хочу, например, такое:А я хочу, чтобы лето не кончалось.
copy file-name.ext;num other-name.ext /b
Пройдёт?
Чтоб оно за мною мчалось.
> Придумать единообразное представление особого труда не составляет.
> XML тоже ведь придумали.
> Ещё и пропихивают так, что только отталкивать успевай.
Предположим, что у нас есть ОС со структурированными файлами, и сериализатор/десериализатор
для предсавления в виде потока байт.
А в другой ОС это представление будет иметь смысл? Похоже, что нет.
> Передаётся в конечном счёте не "stream" и не "byte."
Файловой системы в конечном счёте тоже нет, а есть хитрое намагничивание диска.
> Только ты скатился к моему решению --- замена ОС, а не к униксоподобному.
> Ты заменяешь "UNIX OS" на "Emacs OS."
Как раз нет.
На vim всё тоже самое делается, как уже говорили.
И это компоненты современных юниксов.
По-другому: unix way старается уменьшить разницу между UI и API.
например /usr/bin/c{i,o} - это и то, и другое одновременно.
> Я пока таких недостатков, за исключением сжирания дискового пространства, не видел.
> Но кто из нас говорил, что железо дешевле?
Формулирую основной недостаток - это усложнение, и усложнение не нужное.
Ненужное, так как всё равно понадобятся более мощные VCS, с такими функциями,
как версии для целиком проекта, нелинейное пространство версий (ветки
поддержка распрелённого редактирования.
И такие системы уже есть, и их фунции покрывают все желаемые тобой возможности ФС.
Кроме пожалуй одной - автоматическое создание резервных копий при модификациях файлов.
Эта задача, я думаю, решится, снапшоты, о которых говорил - это шаг к решению.
Причём в духе unix way решить можно красивее, чем ты предлашаешь -
с разделением механизма и политики - копии делает ядро, а версии им навешивает выбранная
тобой VCS, и бекапы складываются на резервный носитель по составленному тобой расписанию.
> XML тоже ведь придумали.
> Ещё и пропихивают так, что только отталкивать успевай.
Предположим, что у нас есть ОС со структурированными файлами, и сериализатор/десериализатор
для предсавления в виде потока байт.
А в другой ОС это представление будет иметь смысл? Похоже, что нет.
> Передаётся в конечном счёте не "stream" и не "byte."
Файловой системы в конечном счёте тоже нет, а есть хитрое намагничивание диска.
> Только ты скатился к моему решению --- замена ОС, а не к униксоподобному.
> Ты заменяешь "UNIX OS" на "Emacs OS."
Как раз нет.
На vim всё тоже самое делается, как уже говорили.
И это компоненты современных юниксов.
По-другому: unix way старается уменьшить разницу между UI и API.
например /usr/bin/c{i,o} - это и то, и другое одновременно.
> Я пока таких недостатков, за исключением сжирания дискового пространства, не видел.
> Но кто из нас говорил, что железо дешевле?
Формулирую основной недостаток - это усложнение, и усложнение не нужное.
Ненужное, так как всё равно понадобятся более мощные VCS, с такими функциями,
как версии для целиком проекта, нелинейное пространство версий (ветки
поддержка распрелённого редактирования.
И такие системы уже есть, и их фунции покрывают все желаемые тобой возможности ФС.
Кроме пожалуй одной - автоматическое создание резервных копий при модификациях файлов.
Эта задача, я думаю, решится, снапшоты, о которых говорил - это шаг к решению.
Причём в духе unix way решить можно красивее, чем ты предлашаешь -
с разделением механизма и политики - копии делает ядро, а версии им навешивает выбранная
тобой VCS, и бекапы складываются на резервный носитель по составленному тобой расписанию.
> Хочу, например, такое:
> copy file-name.ext;num other-name.ext /b
> Пройдёт?
да, только не ;num а :streamname
> copy file-name.ext;num other-name.ext /b
> Пройдёт?
да, только не ;num а :streamname
На файловой системе NTFS каждый файл имеет как минимум один стандартный поток данных, к которому можно обратиться по имени файла. Каждый файл может также иметь дополнительные потоки данных, которые имеют свои персональные имена (filename:streamname).
То есть, всё-таки, вызов руками или по часам?
Это далеко не то, что нужно.
В промежутках между последовательными снимками откат будет невозможен.
---
...Я работаю антинаучным аферистом...
Это далеко не то, что нужно.
В промежутках между последовательными снимками откат будет невозможен.
---
...Я работаю антинаучным аферистом...
>> Придумать единообразное представление особого труда не составляет.
> Предположим, что у нас есть ОС со структурированными файлами,
> и сериализатор/десериализатор для предсавления в виде потока байт.
> А в другой ОС это представление будет иметь смысл? Похоже, что нет.
Есть подозрение, что это и не имеет смысла.
Потому что передавать полный набор версий между различными ОС нафиг не надо.
Ибо передавать имеет смысл только одну версию.
Либо наподобие RCS.
>> Только ты скатился к моему решению --- замена ОС, а не к униксоподобному.
>> Ты заменяешь "UNIX OS" на "Emacs OS."
> Как раз нет.
> На vim всё тоже самое делается, как уже говорили.
> И это компоненты современных юниксов.
> По-другому: unix way старается уменьшить разницу между UI и API.
> например /usr/bin/c{i,o} - это и то, и другое одновременно.
Немного не то.
Смотри.
Если мы живём внутри Емакса, то загнав буфер в vc-mode,
все действия будут согласованы с VCS.
А вот если мы выползем хотя бы в M-x shell,
то можно сделать такое, что побьёт vc-mode.
Подобно исправлению данных на диске с помощью шестнадцатиричного редактора.
Можно побить всё так, что потом и не очухаешься.
Различие состоит в том, что, правя диск, ты знаешь об опасности,
а работая с файлами обычными средствами получаешь рассогласование.
> Ненужное, так как всё равно понадобятся более мощные VCS,
> с такими функциями, как версии для целиком проекта,
> нелинейное пространство версий (ветки
> поддержка распрелённого редактирования.
Можно пример, чтобы более определённо?
Они настолько разные, что никак не устраняют полезности ВФС.
> Кроме пожалуй одной - автоматическое создание резервных копий при модификациях файлов.
> Эта задача, я думаю, решится, снапшоты, о которых говорил - это шаг к решению.
> Причём в духе unix way решить можно красивее, чем ты предлашаешь -
> с разделением механизма и политики - копии делает ядро,
> а версии им навешивает выбранная тобой VCS,
> и бекапы складываются на резервный носитель
> по составленному тобой расписанию.
Предлагается вешать обработчик события "открытие файла?"
Да, так можно.
Только я пока не слышал о таких демонах.
Если есть, скажи --- я посмотрю. А то --- пусть крутится.
Единственное, что непонятно,--- это как, например, будет работать VCS,
сильно отличающаяся от RCS/CVS.
Такая есть, и мне очень даже нравится.
---
...Я работаю антинаучным аферистом...
> Предположим, что у нас есть ОС со структурированными файлами,
> и сериализатор/десериализатор для предсавления в виде потока байт.
> А в другой ОС это представление будет иметь смысл? Похоже, что нет.
Есть подозрение, что это и не имеет смысла.
Потому что передавать полный набор версий между различными ОС нафиг не надо.
Ибо передавать имеет смысл только одну версию.
Либо наподобие RCS.
>> Только ты скатился к моему решению --- замена ОС, а не к униксоподобному.
>> Ты заменяешь "UNIX OS" на "Emacs OS."
> Как раз нет.
> На vim всё тоже самое делается, как уже говорили.
> И это компоненты современных юниксов.
> По-другому: unix way старается уменьшить разницу между UI и API.
> например /usr/bin/c{i,o} - это и то, и другое одновременно.
Немного не то.
Смотри.
Если мы живём внутри Емакса, то загнав буфер в vc-mode,
все действия будут согласованы с VCS.
А вот если мы выползем хотя бы в M-x shell,
то можно сделать такое, что побьёт vc-mode.
Подобно исправлению данных на диске с помощью шестнадцатиричного редактора.
Можно побить всё так, что потом и не очухаешься.
Различие состоит в том, что, правя диск, ты знаешь об опасности,
а работая с файлами обычными средствами получаешь рассогласование.
> Ненужное, так как всё равно понадобятся более мощные VCS,
> с такими функциями, как версии для целиком проекта,
> нелинейное пространство версий (ветки
> поддержка распрелённого редактирования.
Можно пример, чтобы более определённо?
Они настолько разные, что никак не устраняют полезности ВФС.
> Кроме пожалуй одной - автоматическое создание резервных копий при модификациях файлов.
> Эта задача, я думаю, решится, снапшоты, о которых говорил - это шаг к решению.
> Причём в духе unix way решить можно красивее, чем ты предлашаешь -
> с разделением механизма и политики - копии делает ядро,
> а версии им навешивает выбранная тобой VCS,
> и бекапы складываются на резервный носитель
> по составленному тобой расписанию.
Предлагается вешать обработчик события "открытие файла?"
Да, так можно.
Только я пока не слышал о таких демонах.
Если есть, скажи --- я посмотрю. А то --- пусть крутится.
Единственное, что непонятно,--- это как, например, будет работать VCS,
сильно отличающаяся от RCS/CVS.
Такая есть, и мне очень даже нравится.
---
...Я работаю антинаучным аферистом...
И что, "copy file-name.ext other-name.ext" создаёт новую копию?
---
...Я работаю антинаучным аферистом...
---
...Я работаю антинаучным аферистом...
Да, стримы тоже копируются, если other-name.ext также на NTFS-разделе.
Новую копию other-name.ext?
Ни разу не слышал.
У тебя NTFS рядом есть?
Попробуй сделать так:
echo 1 > test
...
eсho 2 > test
Должно получиться две версии: test;1 и test;2
Когда получишь, скажи, что сделал между "эхами."
---
...Я работаю антинаучным аферистом...
Ни разу не слышал.
У тебя NTFS рядом есть?
Попробуй сделать так:
echo 1 > test
...
eсho 2 > test
Должно получиться две версии: test;1 и test;2
Когда получишь, скажи, что сделал между "эхами."
---
...Я работаю антинаучным аферистом...
Не, я имел ввиду, если сделать echo gavnovsyakoe > file.ext:stream1 и copy file.ext other.ext, то more < other.ext:stream1 выведет gavnovsyakoe.
Так это просто.
Потому оно и не имеет отношения к разговору.
А вот если добьёшься правильного итога, тогда обязательно скажи.
Я бы хотел такое видеть.
---
"А я обучался азбуке с вывесок,
листая страницы железа и жести."
Потому оно и не имеет отношения к разговору.
А вот если добьёшься правильного итога, тогда обязательно скажи.
Я бы хотел такое видеть.
---
"А я обучался азбуке с вывесок,
листая страницы железа и жести."
на основе стримов то, если я правильно понял, о чем ты говоришь реализуется тривиально
Вопрос стоит не в том, что возможно.
Вопрос стоит, есть оно или нет.
Если есть, тогда скажи, что нужно вызвать между первой и второй "echo."
Конечно же, с консоли, а то пропадает весь смысл затеи.
---
...Я работаю антинаучным аферистом...
Вопрос стоит, есть оно или нет.
Если есть, тогда скажи, что нужно вызвать между первой и второй "echo."
Конечно же, с консоли, а то пропадает весь смысл затеи.
---
...Я работаю антинаучным аферистом...
на основе стримов то, если я правильно понял, о чем ты говоришь реализуется тривиально
Версии файлов? Нет.
> > Предположим, что у нас есть ОС со структурированными файлами,
> > и сериализатор/десериализатор для предсавления в виде потока байт.
> > А в другой ОС это представление будет иметь смысл? Похоже, что нет.
> Есть подозрение, что это и не имеет смысла.
> Потому что передавать полный набор версий между различными ОС нафиг не надо.
Похоже, ты уже сам забыл, о чём флейм.
Так вот, тут он был о плоских vs. структурированных файлах.
> Подобно исправлению данных на диске с помощью шестнадцатиричного редактора.
> Можно побить всё так, что потом и не очухаешься.
> Различие состоит в том, что, правя диск, ты знаешь об опасности,
> а работая с файлами обычными средствами получаешь рассогласование.
Наветы
Говори за себя.
> Можно пример, чтобы более определённо?
> Они настолько разные, что никак не устраняют полезности ВФС.
Хотя бы cvs, хоть там и плохо с распределённостью.
Скажешь, в рабочем катологе cvs нужны версии средствами ФС? Или в репозитории?
> только я пока не слышал о таких демонах.
Я тоже
> > и сериализатор/десериализатор для предсавления в виде потока байт.
> > А в другой ОС это представление будет иметь смысл? Похоже, что нет.
> Есть подозрение, что это и не имеет смысла.
> Потому что передавать полный набор версий между различными ОС нафиг не надо.
Похоже, ты уже сам забыл, о чём флейм.
Так вот, тут он был о плоских vs. структурированных файлах.
> Подобно исправлению данных на диске с помощью шестнадцатиричного редактора.
> Можно побить всё так, что потом и не очухаешься.
> Различие состоит в том, что, правя диск, ты знаешь об опасности,
> а работая с файлами обычными средствами получаешь рассогласование.
Наветы
Говори за себя.
> Можно пример, чтобы более определённо?
> Они настолько разные, что никак не устраняют полезности ВФС.
Хотя бы cvs, хоть там и плохо с распределённостью.
Скажешь, в рабочем катологе cvs нужны версии средствами ФС? Или в репозитории?
> только я пока не слышал о таких демонах.
Я тоже
>>> Предположим, что у нас есть ОС со структурированными файлами,
>>> и сериализатор/десериализатор для предсавления в виде потока байт.
>>> А в другой ОС это представление будет иметь смысл? Похоже, что нет.
>> Есть подозрение, что это и не имеет смысла.
>> Потому что передавать полный набор версий между различными ОС нафиг не надо.
> Так вот, тут он был о плоских vs. структурированных файлах.
По-моему, он был немного о другом.
В твоём понимании, он уже дошёл до структурированных файлов.
В моём --- ещё застрял на ВФС.
> Говори за себя.
Я выкручивался после падения чего-то такого виндового.
Радости не доставило.
Это если о правке диска.
RCS руками пока не правил, но уже приходилось вмешиваться,
чтобы всё работало как надо.
Отсутствие поддержки версий в общем даёт о себе знать.
Если бы поддерживались, было бы куда проще.
Впечатления остались чуть получше, чем от правок диска.
Это ещё и к вопросу о дружественности.
>> Можно пример, чтобы более определённо?
>> Они настолько разные, что никак не устраняют полезности ВФС.
> Хотя бы cvs, хоть там и плохо с распределённостью.
Брр.
> Скажешь, в рабочем катологе cvs нужны версии средствами ФС?
> Или в репозитории?
В рабочем каталоге --- не помешают.
Видимо ты не понял, что не все файлы создаются текстовым редактором либо автомагически.
---
...Я работаю антинаучным аферистом...
>>> и сериализатор/десериализатор для предсавления в виде потока байт.
>>> А в другой ОС это представление будет иметь смысл? Похоже, что нет.
>> Есть подозрение, что это и не имеет смысла.
>> Потому что передавать полный набор версий между различными ОС нафиг не надо.
> Так вот, тут он был о плоских vs. структурированных файлах.
По-моему, он был немного о другом.
В твоём понимании, он уже дошёл до структурированных файлов.
В моём --- ещё застрял на ВФС.
> Говори за себя.
Я выкручивался после падения чего-то такого виндового.
Радости не доставило.
Это если о правке диска.
RCS руками пока не правил, но уже приходилось вмешиваться,
чтобы всё работало как надо.
Отсутствие поддержки версий в общем даёт о себе знать.
Если бы поддерживались, было бы куда проще.
Впечатления остались чуть получше, чем от правок диска.
Это ещё и к вопросу о дружественности.
>> Можно пример, чтобы более определённо?
>> Они настолько разные, что никак не устраняют полезности ВФС.
> Хотя бы cvs, хоть там и плохо с распределённостью.
Брр.
> Скажешь, в рабочем катологе cvs нужны версии средствами ФС?
> Или в репозитории?
В рабочем каталоге --- не помешают.
Видимо ты не понял, что не все файлы создаются текстовым редактором либо автомагически.
---
...Я работаю антинаучным аферистом...
Оставить комментарий
Ivan8209
Всё! Других способов нет.
Обратите внимание, что единственное спасение для UNIX заключено в
Emacs, тоже, кстати, уходящем корнями в недра DEC, или в Emacs-
подобном JED.
Можете прикинуть, что нужно делать, если пытаться задавать поиск в
предыдущих версиях.
Вы читали отрывки из VMS-to-Linux-HOWTO
---
"...Видный ретроград-новатор."