The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..., opennews (??), 10-Янв-20, (0) [смотреть все] +1

Сообщения [Сортировка по времени | RSS]


41. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +/
Сообщение от Аноним (-), 10-Янв-20, 11:00 
btrfs device add наш путь... :)
Ответить | Правка | Наверх | Cообщить модератору

85. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +11 +/
Сообщение от Annoynymous (ok), 10-Янв-20, 12:27 
Тернист ваш путь!
Ответить | Правка | Наверх | Cообщить модератору

216. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  –2 +/
Сообщение от Аноним (-), 11-Янв-20, 07:40 
> Тернист ваш путь!

Неа, уже нормально его протоптали. Хотя конечно если у вас там RHEL 6 с чуть ли не 2.6.чтототам - вы там держитесь, конечно...

Ответить | Правка | Наверх | Cообщить модератору

125. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  –1 +/
Сообщение от Аноним (125), 10-Янв-20, 15:17 
btrfs это путь в /dev/null
сравнивать её с zfs это все-равно что сравнивать Photoshop и Gimp, вроде оба графические редакторы, но почему-то у первого интерфейс и фичи намного более продуманные чем у второго.
Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

158. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +7 +/
Сообщение от 6 (?), 10-Янв-20, 18:19 
срвнивать Photoshop и Gimp с btrfs и zfs, это как сравнивать 3 и 5 с 8 и 12, вроде бы все числа, но у вторых больше разница, а в вашем случае у первых больше значимость, мне и гимпа за глаза хватает, а многим пэйнта, а большенство вообще не пользуется, а фс пользуют все.

... и оракл тоже путь вникуда, сколько они сказок про яву пели..

Ответить | Правка | Наверх | Cообщить модератору

173. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +1 +/
Сообщение от Аноним (173), 10-Янв-20, 21:00 
я и не имел ввиду что zfs нужен всем (так же как Photoshop и/или Gimp).
мой пост нес смысловую нагрузку в том, что btrfs ни разу не заменитель zfs в linux, как по стабильности так и по фичам.
Ответить | Правка | Наверх | Cообщить модератору

175. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +3 +/
Сообщение от Аноним (175), 10-Янв-20, 21:27 
Не знаю кому, но я в восторге от того, что btrfs позволяет буквально одной командой откатить все изменения в системе - мгновенно.
Ответить | Правка | Наверх | Cообщить модератору

178. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +1 +/
Сообщение от puertto (?), 10-Янв-20, 21:37 
внезапно в zfs это появилось еще до того как было придумано в батырфс
Ответить | Правка | Наверх | Cообщить модератору

185. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +1 +/
Сообщение от Gannetemail (ok), 10-Янв-20, 22:05 
И что, от этого она лучше?
Ответить | Правка | Наверх | Cообщить модератору

195. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +/
Сообщение от Аноним (173), 11-Янв-20, 00:13 
именно из-за этого нет, но у zfs есть фичи, которых либо нет в btrfs, либо они в последней криво реализованы. вот из-за этого btrfs это не есть аналог zfs, это попытка быть им, но не удачная.
Ответить | Правка | Наверх | Cообщить модератору

205. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +/
Сообщение от Gannetemail (ok), 11-Янв-20, 04:46 
Списочек в студию.
Ответить | Правка | Наверх | Cообщить модератору

219. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +1 +/
Сообщение от Аноним (219), 11-Янв-20, 07:53 
> Списочек в студию.

Я могу наоборот. Btrfs умеет в reflinks. Это ... ну примерно как линки, только на блочном уровне. Так что копия файла изначально ссылается на те же блоки что и оригинал. Занимая место 1 раз. А по мере того как они расходятся в эволюции, разные блоки по мере надобности копируются.

В результате скопировать вон ту виртуалку из шаблона, с 20 гигз диском? Фигня вопрос, пара секунд. А если она от шаблона и прочих виртуалок мало отличается, это еще и места займет только на отличия - т.е. почти нифига. Такой себе overcommit на диске, позволяющий запустить толпу виртуалок в момент и даже их суммарная емкость "дисков" может быть заметно больше свободного места. Несомненно, нюансы будут, но где так еще можно то? Аж в целом XFS? Так у него ненппряжного управления девайсами и рестрайпа на ходу нет.

Ответить | Правка | Наверх | Cообщить модератору

257. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +/
Сообщение от Kroz (ok), 11-Янв-20, 12:38 
> Я могу наоборот. Btrfs умеет в reflinks. Это ... ну примерно как линки, только на блочном уровне. Так что копия файла изначально ссылается на те же блоки что и оригинал. Занимая место 1 раз.

Это есть практически в любой Линуксовй ФС: ext2/3/4, reiserfs, xfs,...
Но...

> А по мере того как они расходятся в эволюции, разные блоки по мере надобности копируются.

Это называется Copy-on-write (CoW). Это, да, умеют не многие.

Ответить | Правка | Наверх | Cообщить модератору

298. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +/
Сообщение от Аноним (-), 12-Янв-20, 06:26 
> Это есть практически в любой Линуксовй ФС: ext2/3/4, reiserfs, xfs,...

Вы, похоже, не шарите. Или перепутали с другими *links. Которые оперируют не блоками а файлами целиком, что как бы большая разница. Симлинками и хардлинками нельзя сослаться на середину вон того файла. Reflinks работает на блочном уровне - там так можно.

Эта фича есть в всего 2 ФС. Изначально ее сделали btrfs а потом в шапке кой-как прикрутили к XFS. А на самом деле очень крутая фича для работы с VM и образами дисков.

> Это называется Copy-on-write (CoW). Это, да, умеют не многие.

Reflinks более или менее завязан на семантику CoW. Суть в том что изначально при cp --reflink все блоки нового файла ссылаются на блоки старого. Поэтому хотя это формально иной файл, копия почти не занимает места. Однако когда копия (или оригинал) меняются, измененные блоки уже фактически копируются, описание файла апдейтится ФС чтобы отсылать уже туда. Так строится новый вид файла. И программы видят два вполне независимых файла которые можно независимо менять.

Для программ это два совершенно независимых файла, с которыми можно работать как с 2 разными файлами. Они будут хранить разные данные, если это надо (разные блоки будут "unshared").

В чем пойнт? Можно например за несколько секунд поднять 10 одинаковых VM с 20-гиговым диском из шаблона. У каждой будет свой диск, никак не завязаный на соседей или шаблон. Изначально оно почти не займет дополнительного места, а дальше по мере работы VM - смотря насколько их диски разойдутся в состояниях. В хучшем случае постепенно может стать 10 файлов где не шарится ни 1 блок - и тогда это займет 200 гигз. Но во первых наихучший случай почти никогда не наступает, а во вторых - есть разница: случился ли это плавно, при работе VM, или же вы будете ждать копиривания 200 гигз при подъеме виртуалок в самом начале.

Ответить | Правка | К родителю #257 | Наверх | Cообщить модератору

316. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +/
Сообщение от Аноним (173), 12-Янв-20, 10:31 
zfs: snapshot+clone ?
и будет у вас 10 ВМ, которые будут занимать как один больщой + 10 diff'ов.
или aufs - тогда вообще без разницы на какой fs находится каталог.

и да, фича reflink как таковая есть не у многих, но может быть потому что она мало кому нужна? - при желании можно найти способы как добиться того же иными механизмами (см. выше).

Ответить | Правка | К родителю #298 | Наверх | Cообщить модератору

319. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +/
Сообщение от пох. (?), 12-Янв-20, 14:46 
> и да, фича reflink как таковая есть не у многих, но может

для начала она совершенно бесполезна на не-cow-fs, поэтому многих тут и не предвиделось.

> быть потому что она мало кому нужна? - при желании можно

собственно, ее года два назад уже пытались втащить в zfs - застряли на вершине posix layer. То есть технически ничего не мешает, поленились протащить механизм через подсистему уже непосредственно способную взаимодействовать с юзерскими тулзами. И так и бросили - по всей очевидности, не нашлось того единственного человека, которому эта фича на самом деле была бы нужна не чисто теоретически.

Ну правильно, докеровцы подавали на банкр...продавались пока берут, а кроме них никому оно особо и не было нужно.

Ответить | Правка | К родителю #316 | Наверх | Cообщить модератору

335. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +/
Сообщение от Аноним (-), 13-Янв-20, 07:38 
> для начала она совершенно бесполезна на не-cow-fs,

Когда нельзя, но очень хочется... шапка все же смогла сову на глобус^W xfs :). Оно вроде экспериментальное, но все-же.

> собственно, ее года два назад уже пытались втащить в zfs - застряли на вершине posix layer.

И забили болт? FAIL, учитывая что шляпа смогла аж в xfs втащить.

> То есть технически ничего не мешает, поленились протащить механизм через подсистему
> уже непосредственно способную взаимодействовать с юзерскими тулзами. И так и бросили
> - по всей очевидности, не нашлось того единственного человека, которому эта фича на
> самом деле была бы нужна не чисто теоретически.

Ну, блин, на линухе это уже и так в 2 файлухах есть. Логично что ленятся.

> Ну правильно, докеровцы подавали на банкр...продавались пока берут, а кроме них никому
> оно особо и не было нужно.

Я не докеровец, к такой фиче отношусь положительно, но отлично понимаю что кому оно надо - скорее btrfs или xfs поюзают в результате. Последнее особенно угарно, т.к. изначально он даже и не cow был.

Ответить | Правка | К родителю #319 | Наверх | Cообщить модератору

347. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +/
Сообщение от пох. (?), 13-Янв-20, 10:11 
> Когда нельзя, но очень хочется... шапка все же смогла сову на глобус^W xfs :)

ну вам и флаг в руки, разбираться, как это работает и зачем нам ненужно. Я, пожалуй, пару лет подожду.

> И забили болт?

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

> Ну, блин, на линухе это уже и так в 2 файлухах есть. Логично что ленятся.

я полагаю, желающих поменять fs под работающей системой ради этой фичи найдется примерно ноль.

> Я не докеровец, к такой фиче отношусь положительно

да смысл? Вот с учетом предыдущей фигни - не кому-то там абстрактному, а лично тебе месяц свободного времени не видать, чтобы ее дописать и оттестировать? Полагаю - "ну нафиг!" Тем более что там есть вещи поважнее, на которые время потратить стоит.

Вот докеру оно было бы очень кстати, в виду его особенностей громождения уровней поверх уровней.  Но его разработчикам как раз в тот момент стало резко не до этого - они побежали срочно обновлять профили на линкедине.

Ответить | Правка | К родителю #335 | Наверх | Cообщить модератору

353. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +/
Сообщение от Аноним (-), 13-Янв-20, 14:25 
> ну вам и флаг в руки, разбираться, как это работает и зачем нам ненужно.

Я не фанат шапки, да и xfs мне как-то средне, пусть его какие-нить юзеры федоры тестят, если они понимают пойнт такого сочетания. Это так, возражение насчет единственной. Я думаю что постепенно это станет неким околостандартным апи. Было бы хорошо если бы офлайн дедупы могли работать на разных ФС, а в идеале и ОС используя один и тот же код...

> Я, пожалуй, пару лет подожду.

Да хоть пятьдесят, мне не жалко :). Даже имеет некий пойнт. Как говорится, бесплатный сыр достается только второй мышке. Главное в этой истории не обнаружить что сыр протух.

> Даже если это достаточно тривиальное улучшение. Пообсуждали и разошлись.

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

> я полагаю, желающих поменять fs под работающей системой ради этой фичи найдется примерно ноль.

Кто ж ФС под работающей ОС то меняет? Судя по гитлогу в btrfs основные крушильные эксперименты на qemu крутятся. К тому же там жесткие факапы ядра удобнее отлаживать.

> а лично тебе месяц свободного времени не видать, чтобы ее дописать
> и оттестировать? Полагаю - "ну нафиг!" Тем более что там есть
> вещи поважнее, на которые время потратить стоит.

Вот тут ты прав. Тем более что мой интерес к внеядерным модулям ядра по дефолту равен нулю. Есть пара штук с которыми я развлекаюсь но это мелкие штуки которые при желании можно хоть с нуля переписать.

> Вот докеру оно было бы очень кстати, в виду его особенностей громождения
> уровней поверх уровней.  Но его разработчикам как раз в тот
> момент стало резко не до этого - они побежали срочно обновлять профили на линкедине.

А что, в докере вообще были кодеры такого плана? Я думал там только вебмакаки с go?

Ответить | Правка | К родителю #347 | Наверх | Cообщить модератору

371. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +/
Сообщение от пох. (?), 15-Янв-20, 16:03 
>> Даже если это достаточно тривиальное улучшение. Пообсуждали и разошлись.
> Я как-то набредал на разработчика zfs, он утверждал что так вышло что
> фича плохо маппится на устройство файлухи и нифига оно там не
> тривиально.

ну видимо у них там всьо нетривиально, кроме вредных экспериментов, которые, похоже, как раз тривиальны.
А менеджера с кнутом, увы, не осталось.

>> я полагаю, желающих поменять fs под работающей системой ради этой фичи найдется примерно ноль.
> Кто ж ФС под работающей ОС то меняет? Судя по гитлогу в

имелось в виду - от появления в очередном редхаторелизе xfs данной фичи - никто не бросится ей заменять установленную и работающую zfs с воплем "два года жжждал!" И даже ext4 не бросится.

> А что, в докере вообще были кодеры такого плана? Я думал там

аж две unionfs произвели на свет!
Несовместимые и с одним и тем же названием - как у них принято.

Ответить | Правка | К родителю #353 | Наверх | Cообщить модератору

331. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +/
Сообщение от Аноним (-), 13-Янв-20, 05:52 
> zfs: snapshot+clone ?
> и будет у вас 10 ВМ, которые будут занимать как один больщой + 10 diff'ов.

Лепить по снапшоту на каждый инстанс виртуалки? А я не устану эту плеяду снапшотов менеджить? Особенно если захочу еще и какие-то состояния VM заснпшотить? Reflinks вообще никакого менеджмента не требует. Это такой убер-дедуп, когда мы явно просим ФС сделать "изначально полностью дедупнутую копию файла". Просится 1 раз за жизнь виртуалки, дальше это обычный файл и никакого внимания не требует. Поработали, когда разнадобился - стерли. Блоки файла которые никто не использует файлуха сама уберет. Знаете, я так то GC называю "неизбежное зло". А чтоб самому в его роли пахать? Хм!

Кстати если мы об этом, в btrfs таки сделали удаление subvolumes как обычных дир. Поскольку снапшоты тоже subvolumes, теперь можно снапшоты выпиливать прямо по F8 в миднайте (или кто там что лю). А в zfs так можно?

В общем если мы об удобном менеджменте - btrfs умеет в это. И довольно хорошо.

> или aufs - тогда вообще без разницы на какой fs находится каталог.

И как в этом случае выглядит эквивалент reflink? Ну и следующий логичный вопрос - а мануально дедупнуть файл X относительно Y на этом можно будет? Ну вон какой-нибудь jdupes в офлайне btrfs'а довольно лихо дедупает. Наверное и xfs'а уже так может. А aufs вывешивает программный интерфейс, понимаемый софтом? Вручную закатывать солнца вместо операционки я не хочу. Нет, так то я могу и хексэдитором байты разложить как надо, но предпочитаю юзать этот скилл редко и по делу.

> и да, фича reflink как таковая есть не у многих, но может
> быть потому что она мало кому нужна?

Тот факт что шапка подорвалась такое кодить аж в xfs и ряд системных тулсов это заимплементили как-то не подтверждает эту идею.

> - при желании можно найти способы как добиться того же иными механизмами (см. выше).

...но это не будет оформлено программным интерфейсом, который понимают например вон те проги дедубликаторов, etc...

Ответить | Правка | К родителю #316 | Наверх | Cообщить модератору

372. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +/
Сообщение от пох. (?), 15-Янв-20, 16:17 
>> zfs: snapshot+clone ?
>> и будет у вас 10 ВМ, которые будут занимать как один больщой + 10 diff'ов.
> Лепить по снапшоту на каждый инстанс виртуалки? А я не устану эту

а что мешает? Если мы уж так хотим сэкономить место. Напоминаю, что "инстанс виртуалки" у нас, вообще-то - volume, а не файл на диске, к радости васяна с миднайтом.

> плеяду снапшотов менеджить? Особенно если захочу еще и какие-то состояния VM

вы же не устали менеджить ручное создание рефлинков? Вряд ли ваш миднайт снабжен особо продвинутой кнопкой f5.

> мы явно просим ФС сделать "изначально полностью дедупнутую копию файла". Просится

в zfs есть clone - "полная копия fs/тома". Вполне хватит и виртуалкам.

> Кстати если мы об этом, в btrfs таки сделали удаление subvolumes как
> обычных дир. Поскольку снапшоты тоже subvolumes, теперь можно снапшоты выпиливать прямо
> по F8 в миднайте (или кто там что лю). А в zfs так можно?

к счастью, нет, макака с миднайтом даже если сумеет забраться в скрытую от посторонних глаз .zfs/snapshots, ничего там не сможет удалить. Поскольку неактивный снапшот - аналог readonly subvol, и удаляется не по одному файлику, а только и исключительно целиком.

> В общем если мы об удобном менеджменте - btrfs умеет в это.

я бы не назвал пофайликовое удаление миднайт кошмандером и невозможность отличить без микроскопа сабвольюм от каталога - удобным менеджментом.
Если мне чего и не хватает в zfs destroy - так это аналога ключа -r в snap.

> Тот факт что шапка подорвалась такое кодить аж в xfs и ряд

они туда старательно переписывают все фичи zfs/btrfs, но, к сожалению, реализованные через ^опу, автогеном.

Ответить | Правка | К родителю #331 | Наверх | Cообщить модератору

320. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +1 +/
Сообщение от пох. (?), 12-Янв-20, 14:55 
> В результате скопировать вон ту виртуалку из шаблона, с 20 гигз диском?
> Фигня вопрос, пара секунд. А если она от шаблона и прочих

стесняюсь спросить - это у вас kvm настолько бестолково спроектирована, что без уберфичи на уровне fs не жизнеспособна, или у вас все так?

Любые известные мне системы управления виртуализацией способны на такой подвиг собственными силами, без необходимости задействовать единственноверную файловую систему с мегафичей. Кстати, отдельный вопрос - какова потом плата за вермишель мапингов "здесь блок от старого файла, тут от нового, тут от еще более нового" и протаскивания ее через четыре context-switch вместо линейного чтения. А то что-то я ретроград, предпочитаю использовать zfs volumes вместо файлов, чтобы хотя бы в этом месте не плодить ненужных накладных расходов.

Вот докеру оно было, да, архиактуально - ну так что вы хотите от хипстоподелки. Но докер мертв, а rh нонеча почему-то тоже рекомендует использовать для своих ociшных аналогов raw volumes, правда, почему-то, на lvm.

Ответить | Правка | Наверх | Cообщить модератору

332. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +/
Сообщение от Аноним (-), 13-Янв-20, 06:07 
> стесняюсь спросить - это у вас kvm настолько бестолково спроектирована, что без
> уберфичи на уровне fs не жизнеспособна, или у вас все так?

Я со своей стороны считаю что на уровне ФС эта уберфича логичнее. Потому что кроме kvm я могу так и с иными файлами развлекаться.

Ну вот например, доставал я знакомым данные с полутрупного винча. Образ вычитал, пора fsck напускать. Без железной уверенности что он сделает лучше чем было - случаи разные бывают. Делаем cp --reflink, пускаем уже на _копии_. Смотрим как нам результат. Если не нравится - ну, стираем образ да пробуем еще раз, по другому. Устаканиваемся на наилучшем достигнутом. И все это занимает маргинальный объем времени. Особенно если сравнить с честным копированием образа на терабайт.

К тому же, на винче в 2 тб спокойно лежат _три_ образа по якобы терабайту. Реально они занимают чуть более терабайта. Потому что "core set" + небольшая дельта которую fsck и т.п. нагенерили. В результате я могу быстро и безопасно экспериментировать над образами, не боясь ушатать оригинал и у меня всегда есть откат. Стер неудачный эксперимент да попробовал еще раз.

Вопрос: а как мне в этом приключении вообще поможет kvm? И почему именно он :)

> Любые известные мне системы управления виртуализацией

Кто сказал что я хочу это видеть только для виртуализации? Cp --reflink образа терабайтника еще эпичнее чем 20-гигового диска vm.

> без необходимости задействовать единственноверную файловую систему с мегафичей.

Ну, вообще-то, уже не единственную. Шапка подрасперлась и вот конкретно это к xfs все же прикрутила на проволоку и скотч, кастомеры избалованные btrfs'ом видать очень просили.

> Кстати, отдельный вопрос - какова потом плата за вермишель мапингов

Некоторая, разумеется, есть. Поэтому очень сильно референсить блоки не следует. Но для десятка виртуалок номер вполне катит.

> то что-то я ретроград, предпочитаю использовать zfs volumes вместо файлов, чтобы
> хотя бы в этом месте не плодить ненужных накладных расходов.

Я скажу так: в конечном итоге я не хочу подрабатывать Garbage Collector'ом и прочим менеджментом при мегафайлухе. В идеале я не пересекаюсь с этим вообще. Реально это неизбежное зло и чем меньше этих тантрумов - тем лучше.

> Вот докеру оно было, да, архиактуально - ну так что вы хотите от хипстоподелки.

Даже если докер сам так не умеет, можно ему вручную подкостылить или накрайняк потом офлайн дедуп пульнуть. Впрочем, мне пофиг, я докером не пользуюсь.

Ответить | Правка | К родителю #320 | Наверх | Cообщить модератору

218. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  –1 +/
Сообщение от Аноним (-), 11-Янв-20, 07:46 
> btrfs это путь в /dev/null

Я бы сказал ровно наоборот - даже на паре совсем стремных компов с сыпучим диском получилось радикально повысить надежность системы, сугубо теорвером: сделал им схему DUP на данные + метаданные, и так даже сыпучий хард тех чуваков в домике в деревне теперь ни по чем. А блин где я им другой хард возьму если там до ближайшего ларька с хардами километров 200 и про запас я с собой харды в рюкзаке не таскаю? Они тяжелые, заразы.

> сравнивать её с zfs это все-равно что сравнивать Photoshop и Gimp, вроде
> оба графические редакторы, но почему-то у первого интерфейс и фичи намного
> более продуманные чем у второго.

Я юзал и фотошоп и гимп. И без проблем перешел на гимп после фотошопа. Интерфейс что у одного, что у другого требует привыкания и разучивания. И после этого - я этот интерфейс вообще не вижу, делая 95% операций тупо шорткатами. Что быстрее чем мышкой возякать в хоть каком там интерфейсе.

Ответить | Правка | К родителю #125 | Наверх | Cообщить модератору

326. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +/
Сообщение от Аноним (326), 12-Янв-20, 21:56 
окей. как долго вы юзали Photoshop, а затем перешли на Gimp? сколько теоретической базы у вас есть по Photoshop? я однажды попытался пройти курсы по фотографии, и придя домой попробовал все навыки в Gimp после первого же урока. впечатления были странные, вроде слои есть, а толком их использовать нельзя. что-то там еще было, что в Photoshop можно сделать легко и быстро, а в Gimp руками надо и долго.
и я под интерфейсом не подразумеваю только графический интерфейс, а весь интерфейс программы - графический+доступные команды с клавиатуры. откуда у вы взяли что я только мышкой работаю?
Ответить | Правка | Наверх | Cообщить модератору

333. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  –1 +/
Сообщение от Аноним (-), 13-Янв-20, 06:31 
> окей. как долго вы юзали Photoshop, а затем перешли на Gimp? сколько
> теоретической базы у вас есть по Photoshop?

Зачем мне теоретическая база _по фотошопу_? Я читал теоретическую базу _по фотографии_ начиная с бумажных книжек для пленки и заканчивая форматами файлов, принципами работы матриц, алгоритмами и всем таким. По поводу чего у меня есть сносное понимание процесса, dos и donts и всего такого. Но это для себя, чтобы фоткать получше чем рядовые хомяки, выставляющие объектив в солнце.

А применительно к _программе_ мне как-то практические скиллы использования программы оказались важнее всего. Ну хотя-бы потому что без них на элементарные операции можно убить полдня с поганым результатом. Что в фотошопе, что в гимпе. Без типовых хоткеев - неэффективно, а без ощущения тулсов и понимания как они работают приходится постоянно undo фигачить.

> толком их использовать нельзя. что-то там еще было, что в Photoshop
> можно сделать легко и быстро, а в Gimp руками надо и долго.

Не знаю, я на себе этого не ощутил. По первости любая сложная прога требует привыкания. А потом можно ей гвоздить как из пушки. В том числе и гимпом. Впрочем для именно фот мне понравилось darktable'ом ворочать - он вообще не редактор.

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

Ну вот я в гимпе кроме всякой ретуши фотографий еще и пару кастомных гуев например нарисовал, для чего мне потребовалось подразогнать эффективность, иначе это заняло бы уйму времени. В фотошопе я кстати за такое по состоянию на сейчас вообще не взялся бы.

Вообще я немного скептичен насчет курсов. Это для ленивых, кто хочет чтобы его научили быть крутым. А на самом деле чтобы подтянуть в чем-то свой скилл надо этого просто захотеть. Остальное в этом на самом деле вторично и если это и правда цель, можно найти сотни вариантов.

Ответить | Правка | Наверх | Cообщить модератору

373. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +/
Сообщение от пох. (?), 15-Янв-20, 16:37 
>> окей. как долго вы юзали Photoshop, а затем перешли на Gimp? сколько
>> теоретической базы у вас есть по Photoshop?
> Зачем мне теоретическая база _по фотошопу_? Я читал теоретическую базу _по фотографии_

затем, что очень легко рассуждать, как просто с фотошопа перейти на гимп, если ни тем, ни другим на самом деле пользоваться толком не умел. На что ваш оппонент прозрачненько и намекнул.

> начиная с бумажных книжек для пленки и заканчивая форматами файлов, принципами

здорово, что тут как раз пропущено все, о чем, собственно - фотошоп. Слово я  не назову, понимающий да угадает. А вы - пропустили теоретическую базу, угу.

> работы матриц, алгоритмами и всем таким. По поводу чего у меня
> есть сносное понимание процесса, dos и donts и всего такого. Но

ок, опишите своими словами сущность процесса unsharp mask (надеюсь, он уже есть в gimp?). Я достал пивас и сникерс, и удобно уселся в кресле.

> это для себя, чтобы фоткать получше чем рядовые хомяки, выставляющие объектив
> в солнце.

это не означает что вы умеете пользоваться фотошопом, или хотя бы понимаете его назначение.

> А применительно к _программе_ мне как-то практические скиллы использования программы оказались
> важнее всего. Ну хотя-бы потому что без них на элементарные операции
> можно убить полдня с поганым результатом. Что в фотошопе, что в

нет, обычно "пол-дня с поганым результатом" убивают те, кто не понимают, что и как нужно делать. Без понимания - результат будет поганым. Или приемлемым - случайно. С пониманием - возможно медленным, но целенаправленным.

> гимпе. Без типовых хоткеев - неэффективно, а без ощущения тулсов и

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

> Вообще я немного скептичен насчет курсов. Это для ленивых, кто хочет чтобы
> его научили быть крутым. А на самом деле чтобы подтянуть в

нет. Это для тех кто понимает, что помимо "кастомных интерфейсов" есть еще другое ремесло. И обучаться ему методом тыка - бесполезно. Примерно как дикарю пытаться угнать автомобиль. Сколько ни кричит "нно!", сколько кнутом его не лупит - не едет, гад.
Хотя в принципе научить-то его - недолго.
Но если единственного водителя на острове съели - то шансов что научатся самостоятельно - ровно ноль.

Ну разьве что на модной тесле случайно сумеют активировать автопилот. Сумевшего - назначат жрецом - "у него есть ощущение!"

А перекрасить его - кисточкой и валиком - да, может и дикарь.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру