DNF будет переписан на языке C

debdelta
diff and patch utilities which work with Debian packages

Так что оно как бы есть, только никому не упёрлось.

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

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

- Ой, что деется! Вчерась траншею рыли, Так откопали две коньячные струи. - Говорят, шпионы воду отравили. Самогоном. Ну, а хлеб, теперь из рыбьей чешуи.

Брысь отседова. RedHat пока что в патентовых преследованиях не замарался, да и не с руки ему гадить в свой же водоём - они с опенсорса неплохой профит получают, а репутация в этом деле - далеко не последняя штука.

Поддержка упрощается, вход для новичков снижается.

И вот тут начинается Адъ. Другое дело когда перепишут на С, что вызовет самоликвидацию школоты и повышение качества архитектуры, ну и производительность слегка увеличится.

Другое дело когда перепишут на С, что вызовет самоликвидацию школоты и повышение качества архитектуры

Тогда надо сразу на Haskell или Agda переписывать.

Что вот прям есть такая проблема? Что лезут школьники и всё портят? Есть примеры из реального мира, что вот был проект, написан на условном Python/C#/Basic/Java, и из-за низкого порога входа в него пришли школьники и всё испортили? Как-бы принятие патчей в апстрим должно контролироваться мейнтейнерами, а не уровнем входа языка. Язык С, кстати, тоже не такой уж сложный. Написать на нём хорошо - сложно, но школьники что так, что так не напишут хорошо.

К чему эти полумеры? Писать сразу на коболе или на PL/I. Отсутствие школоты гарантировано.

Слишком низкоуровневый для написания прикладного софта.

Кто сказал git?

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

Кто сказал git?

Добровольно пишут на Си те, кто не освоил более подходящих языков.

Кто сказал git?
На Си пишут те, кто не освоил более подходящих языков.

А какой язык более подходящий для этой задачи?

Любой, кроме ассемблера. Monotone был на Си++, DARCS на Haskell, Mercurial и Bazaar-NG - на Python; Arch вообще был на shell %)

Monotone был на Си++

Ненужно :-)

DARCS на Haskell

Ненужно :-)

Mercurial и Bazaar-NG - на Python

Ненужно :-)

Arch вообще был на shell

Ненужно :-)

Победил Git, который на C, ау, проснись :-)

Monotone был на Си++

Ненужно :-)

фейспалм. Блин, ну как можно быть таким малограмотным.

Победил Git

Победа git имеет очень мало отношения к техническим характеристикам - это результат пиара

который на C, ау, проснись :-)

OpenCM был на Си и зафейлился; TLA был в основном на Си - то же самое.

DARCS тормозит как сучка и не умеет локальных репозиториев. И код там не то чтобы прямо замечательный.

фейспалм. Блин, ну как можно быть таким малограмотным.

github знаю :-) gitlab знаю :-) monotonehub не знаю, знать не хочу :-) Фейспалмся на здоровье, грамотей :-)

Победа git имеет очень мало отношения к техническим характеристикам - это результат пиара

Нет, в случае git - это результат технических характеристик, как раз :-) Поди заставь перейти всех с CVS или SVN на Git, если бы Git не имел бы таких характеристик :-) Поди теперь заставь кого-нибудь променять Git на SVN, CVS, Monotone, Mercurial и т.д. :-) Давай, вперёд :-) Фейспалм :-)

OpenCM был на Си и зафейлился; TLA был в основном на Си - то же самое.

Ну вот, характеристиками не вышел же :-) Сам себе и спротиворечил :-)

Эээ... Вообще tailgunner прав. Mercurial так же неплохо бы подошел на роль DVCS. А Subversion и CVS вообще VCS (не путать с DVCS) и до сих пор активно используются там, где это банально удобнее.

ошибки делать? однозначно

Mercurial так же неплохо бы подошел на роль DVCS.

Если бы он имел выдающиеся характеристики лучше чем у Git, то ты бы сейчас скачивал большинство исходников с mercurialhub, а не c github :-) Но он плохо подошёл на роль DVCS по сравнению с Git :-) Так что fail :-)

А Subversion и CVS вообще VCS (не путать с DVCS) и до сих пор активно используются там, где это банально удобнее.

Скорее всего банально лень напрячь свой мозг и перейти на Git :-) Но это их не красит и новых разработчиков не привлекает :-) Поэтому эти товарищи обречены на узкий круг сотоварищей, а «молодой крови» им не видать как своих ушей :-)

apt-get ужасен.

aptitude есть, он не идеален, но лучше, чем большинство других бинарных пм

нет, лучше копипастить, провоцируя сотни ошибок на каждый чих

// плюсохейтер, если что

нет, лучше копипастить, провоцируя сотни ошибок на каждый чих

Нет, лучше решать конкретную задачу здесь и сейчас :-) За каким мне хреном нужна суперуниверсальность тех же строк цепепе, если мне всего лишь надо сконкатенировать 2 массива? :-) Это ради этого я должен цепепе использовать, чтобы не «велосипедить»? :-) Так мне это не надо, я к каждой задаче подхожу отдельно, поэтому у меня нет такого занятия как «велосипедить», у меня есть занятие «решать задачу» :-)

яростная атака высоколобых снобов, вещающих про неосиляторов, меня не впечатляет

как меня не впечатляют стоны в духе «я ниасилил С и щетаю, что на нём писать апасна и ваще низззя».
пока что из основных плюсов у С есть два: нативная поддержка на абсолютном большинстве платформ и архитектур и скорость работы приложений. минусов я не вижу, ибо не отношусь к классу нытиков-неосиляторов.

Забавно... Вместе с emacs он ставит ещё emacs24 emacs24-bin-common emacs24-common libm17n-0 libotf0 m17n-db. При этом, удаление самого emasc не приводит к удалению остальных пакетов, а удаление emacs24 приводит только удалению libm17n-0 libotf0 m17n-db, но не emacs24-bin-common emacs24-common. Однако, Столман как бы говорит тебе, «этот емакс не хочешь удалять ты».

Написано же «for fun, not prod» так что сравнивать нельзя.

Про пакетные менеджеры и скорость работы мы говорили выше. На какой платформе и архитектуре у вас не работал dnf или portage?

Вы кроме си и крестов знаете ещё какие языки программирования? Писали на них большие проекты? Вы писали прикладной софт? Я не утверждаю, что ответ нет на вопросы выше нивелируют важность вашего мнения, мне просто интересно, почему вы так яростно защищаете си

минусов я не вижу, ибо не отношусь к классу нытиков-неосиляторов.

Отсутствие вменяемой системы типов тебя не беспокоит?

Если бы он имел выдающиеся характеристики лучше чем у Git

Какие, например?

Отсутствие вменяемой системы типов тебя не беспокоит?

Это последнее, что может беспокоить в С.

Это последнее, что может беспокоить в С.

Да нет, отсюда растут ноги у void * на каждый чих, NULL pointer dereference и прочих багов.

За каким мне хреном нужна суперуниверсальность тех же строк цепепе, если мне всего лишь надо сконкатенировать 2 массива?

Эдик, ты штоле?

Какие, например?

Это у тебя надо спросить :-) Ты же пытаешься противопоставить Mercurial и Git, намекая, что успех Git связал лишь с пиаром :-) А тебе говорят, что если бы Mercurial обладал лучшими характеристиками, по сравнению с Git, то он был бы стандартным VCS де-факто, коим сейчас является не Mercurial, а именно Git, написанный на C :-) Остальные потерпели фиаско по сути и мало кому нужны :-)

github знаю :-) gitlab знаю :-) monotonehub не знаю, знать не хочу :-)

Какая неожиданность - аноним с нарисованной улыбкой не знает историю своего ремесла.

Я тебе говорю, что у них в целом паритет по возможностями. Ты мне говоришь про превосходство Git. Ну так в чем оно заключается-то?

DARCS тормозит как сучка

Наверное. И что? Ты знаешь, что первые год-два своей жизни Git тормозил настолько, что люди переходили на Mercurial только потому, что он не тормозил? При том, что Git на якобы быстром Си, а имя Линуса привлекло десятки добровольцев. DARCS просто не довели - не хватило людей.

и не умеет локальных репозиториев.

Это для меня новость.

Да нет, отсюда растут ноги у void * на каждый чих, NULL pointer dereference и прочих багов.

Аппарат типов не особо то и выручает в плане багов :-) А иначе бы весь тот софт, который, к сожалению, пишется на цепепе, был бы безглючным :-) Ты точно также можешь разыменовать нулевой смарт-поинтер в цепепе и вывалиться по SIGSEGV :-) Ты даже можешь напороться на трудноуловимую ошибку, просто не учтя очередность определения 2-х членов класса, первый из которых будет хранить указатель на какую-нибудь вариацию по dynamic_cast второго члена, например :-) Что произойдёт в этом случае додумай сам :-) А ты говоришь, типы, void *... :-) Лол :-)

Как пользователь Ubuntu полностью поддерживаю это начинание!

Какая неожиданность

Детская? :-) Лол :-)

Наверное. И что? Ты знаешь, что первые год-два своей жизни Git тормозил настолько, что люди переходили на Mercurial только из-за тормозов? При том, что Git на якобы быстром Си, а имя Линуса привлекло десятки добровольцев. DARCS просто не довели - не хватило людей.

Знаю. C тут слегка не причем - тормоза в софте обычно не из-за языка возникают.

Это для меня новость.

Криво выразился. Я вот об этом: http://bugs.darcs.net/issue555

Какая неожиданность - аноним с нарисованной улыбкой не знает историю своего ремесла.

Детская? :-)

Именно.

на коболе или на PL/I. Отсутствие школоты гарантировано.

Уверен? Я как раз в школе на них немножко писал...

Если брать классику, то лучше APL или SNOBOL.

Эдик, ты штоле?

Не знаю о ком ты, но так считает не только некий Эдик :-)

А иначе бы весь тот софт, который, к сожалению, пишется на цепепе, был бы безглючным

Цепепе очень низкоуровневый язык, с чуть более строгой системой типов. Сравни с тем же OCaml.

нет. меня не беспокоит. по-моему, там с типами всё нормально. чего конкретно не хватает-то?

Я вот об этом: http://bugs.darcs.net/issue555

Судя по wish, это что-то не фундаментальное (я удивлен, что DARCS до сих пор жив).

Аппарат типов не особо то и выручает в плане багов

Существуют исследования, доказывающие обратное.

Цепепе очень низкоуровневый язык, с чуть более строгой системой типов.

Гораздо более строгой. И на порядок более выразительной.

Существуют исследования

Британские ученые доказали (с)

Цепепе очень низкоуровневый язык, с чуть более строгой системой типов.

Да, но есть много удивительных экземпляров, который искренне верят, что цепепе - язык высокоуровневый :-)

Сравни с тем же OCaml.

А чего там сравнивать? :-) OCaml - элегантный, интересный язык, с более здравой системой типов, не то, что бредовый цепепе :-)

Британские ученые доказали (с)

Да нет, просто собрали статистику по времени разработки и количеству багов.