LINUX.ORG.RU

Баш, питон... А исполняемые C++ сорцы с шебангом видали? :)

 ,


2

8
$ cat ~/bin/hello.cpp 
#!/usr/local/bin/build-n-run
#include <stdio.h>
int main() {
    puts("Hello world!");
}

$ hello.cpp 
Recompiling...
Hello world!

$ hello.cpp 
Hello world!

Этот самый /usr/local/bin/build-n-run тоже написан на C++ с использованием std::experimental::filesystem, и он не сильно длиннее эквивалентного баш-скрипта. Собственно работа с путями даже короче. Кому сорц? :)

Отныне в гробу я видал этот ваш баш.

UPD: Сорцы: https://github.com/dimgel/cpp-linux-scripts

★★★★★

Последнее исправление: dimgel (всего исправлений: 1)
Ответ на: комментарий от vertexua

Так как если нету необходимости использовать Rust/Go, то равносильно нет необходимости использовать С

Rustм не нужен, а Linux на С пишут и в нём есть необходимость.

anonymous
()
Ответ на: комментарий от dimgel

Я как гентушник больше думал про source-based, чтобы в манифесте лежало что-то на тему configure-опций: если задашь --with-mysql, то требуется mysql версий таких-то.

Так configure и так умеет проверять версии зависимостей при необходимости.

aureliano15 ★★
()
Ответ на: комментарий от aureliano15

Хм. Подозреваю, там всё не настолько хорошо, чтобы дистрописатели могли всю необходимую инфу для управления зависимостями оттуда тянуть. Иначе ebuild-ы были б не нужны.

dimgel ★★★★★
() автор топика

баш нужен для «простой» работы с переменными окружения

удачи из Си получать и работать с параметрами окружения

anonymous
()
Ответ на: комментарий от yoghurt

header-only враппер для простой работы с переменными окружения, особенно на плюсах, пишется за раз

вот его и написали еще в 80-х, и назвали Баш

чем будет отличаться твой баш от баша существующего-да ничем

anonymous
()
Ответ на: комментарий от anonymous

Это к ТСу вопрос, тут за 4 страницы-то наверное уже обсудили

yoghurt ★★★★★
()
Ответ на: комментарий от anonymous

вот его и написали еще в 80-х, и назвали Баш

В твоих влажных фантазиях.

чем будет отличаться твой баш от баша существующего-да ничем

Всем, не? Баш - убогое дерьмо, не?

Я даже тебе поясню, хотя сложно домохозяйке объяснить разницу между языком и не языком, но всё же. Да что там далеко ходить - 99% домохозяек не отличают баш от coreutils. Вот я тебя и попрошу решить задачу выше без coreutils, а именно - получить имя файла из пути.

А потом ты мне обойдёшь рекурсивной фс и выполнишь какую-то логику над файлами. На баше, естественно.

anonymous
()
Ответ на: комментарий от anonymous

А эти потуги, просто идиотия. «переменные окружения» в привычном тебе виде - это просто башевское дерьмо. Насколько упоротым надо быть, чтобы башевское дерьмо требовать от чего-то ещё?

Является ли башевское дерьмо удобным? Нет. Это полный и тотальный мусор, как и самое это убогое дерьмо в виде баша. На этом дерьме даже не тормозящий комплишн запилить не смогли.

Оно полностью бесполезно. Это не язык - хоть что-то вменяемое на нём не напишешь. А если напишешь - это будет такое дерьмо нерабочее.

В основном колхозники путают банальный cli и coreultils с башем, но на то они и колхозники.

Хочешь хоть какую-то пародию на язык - тебе дали awk, но это такое же дерьмо. Мне даже лень это разъяснять.

А уж если мы за говорим про синтаксис этой параши, то это просто убожество. Доллары, семантика на пробелах, построчная логика. Да даже банальный дерьмоцикл со счётчиком хрен нормально напишешь.

anonymous
()
Ответ на: комментарий от dimgel

Подозреваю, там всё не настолько хорошо, чтобы дистрописатели могли всю необходимую инфу для управления зависимостями оттуда тянуть. Иначе ebuild-ы были б не нужны.

Я гентой не пользуюсь, но подозреваю, что у ebuild'ов могут быть несколько иные задачи, чем у скриптов autoconf. Autoconf предназначен для определения зависимостей, причём достаточно гибко (их можно определять по названию зависимости, её версии, а также по наличию/отсутствию отдельных файлов и идентификаторов), причём определяются как сборочные, так и run-time зависимости. Затем идёт собственно процесс сборки с теми или иными опциями и инсталляция.

Пакеты же (и, полагаю, отчасти ebuild'ы) должны не просто определять, удовлетворены ли зависимости или нет, но и разрешать их, для чего необходимо указывать, откуда эти зависимости можно скачать. С другой стороны, уже не предполагается, что зависимость установлена (а если нет, то сначала установите руками, а потом снова запускайте configure), а предполагается лишь, что она либо установлена, либо может быть автоматически установлена, и этого достаточно. Соответственно, метод проверки на основе существования какого-то идентификатора, как в случае с automake, уже не подходит (хотя этот метод более гибкий). Т. е. если меня, как разработчика, интересует наличие какой-то функции, то я могу проверить это с помощью autoconf, не завязываясь на версии библиотек, а проверяя именно наличие функции. Этот метод в общем случае гибче (мне не надо думать, в какой версии впервые появилась эта функция, и выбросят ли её в будущих версиях, я просто проверяю, есть она или нет). Но майнтейнер, имея дело с ещё не установленной зависимостью, не может на это полагаться. Он должен сначала её установить, но до этого выяснить, подходит ли данная версия. Соответственно, ориентироваться он может только на номера версий.

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

aureliano15 ★★
()
Последнее исправление: aureliano15 (всего исправлений: 1)
Ответ на: комментарий от aureliano15

Autoconf предназначен для определения зависимостей, причём достаточно гибко

В параллельной вселенной. Неужели pkg?

по наличию/отсутствию отдельных файлов и идентификаторов

Очень полезно. Компилятор итак знает - есть файлы, либо нет.

причём определяются как сборочные, так и run-time зависимости.

Это неважно - всё это является твоим колхозом, причём колхозом явно на pkg, который никакого отношения а автоконфу не имеет.

Т. е. если меня, как разработчика, интересует наличие какой-то функции, то я могу проверить это с помощью autoconf, не завязываясь на версии библиотек, а проверяя именно наличие функции.

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

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

Этот метод в общем случае гибче (мне не надо думать, в какой версии впервые появилась эта функция, и выбросят ли её в будущих версиях, я просто проверяю, есть она или нет).

Опять ты пытаешься выдать единственное, что у тебя есть - за «гибче».

Тебе надо думать - работает ли эта функция так, как она работает и не поменялась ли у неё сигнатура. Да и удачи найти что-то в крестах. К тому же - ты будешь перечислять все функции? Удачи.

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

Если в рамках портежа существует установка, то она отслеживает все установленные файлы. Это даёт возможность нормально обновляться - не оставляя лишних файлов. Точно так же - оно показывает конфликты между файлами, а в твоём убожестве оно просто перезапишет чужие.

anonymous
()
Ответ на: комментарий от Iron_Bug

хипстерское программирование без зависимостей.

либы «зависимостей» стали писать нормальные программисты «целиком в *.h файлах» без необходимости компиляции «левой либы» и ее инклюдинга

consists only of header files, hence there is nothing to compile

before you can use it. Moreover, these header files do not depend on your platform, they are the same for everybody.

но он скорее всего про «гигабайтные рантаймы» (ждем встроенного вебсервера в std:: )

anonymous
()

Могу посоветовать только почитать «Искусство программирования для UNIX», «Программное окружение UNIX». Ну и перестать забивать гвозди микроскопом и резать ткани бензопилой «Дружба» модификации народов Африки.

anonymous
()
Ответ на: комментарий от anonymous

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

Так и я говорил о том же самом. Что автоконф и пакеты/порты предназначены для немного разных задач. Автоконф больше для программиста, а пакеты — для конечного пользователя, хотя за неимением оных можно пользоваться и автоконфом.

Если в рамках портежа существует установка, то она отслеживает все установленные файлы. Это даёт возможность нормально обновляться - не оставляя лишних файлов. Точно так же - оно показывает конфликты между файлами, а в твоём убожестве оно просто перезапишет чужие.

Безусловно.

aureliano15 ★★
()
Ответ на: комментарий от aureliano15

Так и я говорил о том же самом.

Нет. Ты говорил о другом. Мало того, чтобы проигнорировал историю и pkg, которая показывают всю мусорность автоконфа, но это ладно.

Ты говорил о том, что они разные - нет, не разные. Ты говорил о том, что автоконф мощнее - нет, не мощнее.

Что автоконф и пакеты/порты предназначены для немного разных задач.

Для идентичных. Пример pkg я тебе уже привёл, ведь это по сути и есть метаинфа от системы пакетов. Она намного мощнее этого убожества.

Есть некоторые нюансы, допустим, портежем обладает малым функционалом, и ты об этом говорил, т.е. он менее мощный(на самом деле нет, но всё же. Ведь мир не заканчивает на автоконфе), но.

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

Но, именно такой штукой и является тот же pkg-config. Он уже давно показал своё превосходство над этим мусором. Но он построен на базе именно пакетного менеджера и в этом его сила, и в этом его смысл.

А представь, что у тебя будет не просто pkg-config, а нормальная система, который поднимет тебе нужное окружение? Везде. Она не будет слабее автоконфа - он просто будет убожество на фоне неё. И в этом смысл.

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

anonymous
()
Ответ на: комментарий от anonymous

история с зависимостями - убогий мусор, который нужно выпилить

И с ними плохо, и без них. С ними проблемы. А без них придётся таскать с собой все возможные версии либ, и каждый пакет будет весить десятки метров. Даже на винде есть зависимости, хотя там с этим проще. Но проще в основном за счёт отсутствия выбора, что на мой взгляд преимуществом не является.

aureliano15 ★★
()
Ответ на: комментарий от anonymous

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от anonymous

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

в софте много сложных библиотек, которые являются базовыми. [skip] простейшие программки на коленке можно ваять и без них

К сожалению, в gcc даже hello_world сваять со статической линковкой слишком накладно:

$ gcc -o hello_world -g0 -O3 -static hello_world.c
$ strip hello_world
$ ls -l hello_world*
652064 мар 22 01:28 hello_world
    76 мар 22 01:27 hello_world.c
aureliano15 ★★
()
Ответ на: комментарий от aureliano15

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

Да. И тут мне вспоминается maven.org (и централизованные репы других языков), куда разрабы сами деплоят свои либы. Будь такое для сей, вопрос «откуда скачать» не стоял бы: настроил глобальный набор реп где искать - и всё.

Это однако потребовало бы так же устранения бардака в именах, например использования общепринятого reverse domain naming, по которому либа просто и однозначно идентифицировалась бы. Может быть с внедрением C++ modules (молюсь чтобы хотя бы в C++20, раз уж в C++17 зарубили) поползут потихоньку в эту сторону. Сейчас же, глядя на содержимое /lib и /usr/lib, я вообще не понимаю, как вся эта ватага непонятных сокращений ухитряется жить без коллизий.

Пытаюсь в качестве вывода сообразить, что бы в таком случае осталось от ебилдов (хоть какая-то генту-специфичная инфа должна ж остаться), но однако в случае жавы кроме pom.xml, скачиваемых из maven-реп, ничего локально заводить не надо. Вообще, мэйвенская магия не перестаёт меня завораживать: каждый раз как на новой системе / под новым юзером начинаю что-нить собирать, при первой сборке он автоматом дикие объёмы скачивает в локальную репу - свои собственные плагины с зависимостями (которые тут же и запускает), либы/фреймворки с зависимостями - и всё ж сука работает! А на сях/юнисях... :( В общем, аноним прав.

dimgel ★★★★★
() автор топика
Ответ на: комментарий от dimgel

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

Патчи бы остались, во. :) Там где они нужны. Т.е. дистро-специфическое portage tree скукожилось бы на пару-тройку порядков.

dimgel ★★★★★
() автор топика
Ответ на: комментарий от dimgel

И тут мне вспоминается maven.org (и централизованные репы других языков), куда разрабы сами деплоят свои либы. Будь такое для сей

А под чьим управлением? Апача? А если другие захотят создать свои репы? И мы получим 100500 реп. Очень удобно. :-)

А кроме того, репы, ориентированные на разные языки, на мой взгляд крайне неудобны. Вот сейчас ты в генте работаешь с ихними портами. Изучил один раз и работаешь. А если бы вместо гентушных портов были бы репы для каждого инструмента: для си — свои, для си++ — свои, для java — свои, для bash-скриптов — свои, для питона — свои, — они и так есть, и т. д. Причём у каждого репозитория своя структура и своя система команд. А тебе, как пользователю, всё это надо запоминать. Но это ещё пол беды. Многие крупные пректы используют разные языки для разных частей. Одна часть может быть написана на си или си++, а другая на том же питоне (какие-нибудь настроечные скрипты, например). И как в такой системе ты их будешь ставить? Сишную часть — отдельно, а питоновскую — отдельно? А потом как-то компоновать всё это руками? И удалять так же придётся: сначала сишную часть, потом питоновскую, потом про какой-нибудь баш-скрипт не забыть. И что останется от твоей системы пакетирования и контроля? — Колхоз, как любит говорить царь. Ещё хуже, чем ручная компиляция и установка. Нет уж. Имхо, лучше пусть в каждой системе будут свои централизованные репы для всех пакетов, независимо от того, на чём те или иные программы написаны.

aureliano15 ★★
()
Ответ на: комментарий от aureliano15

А под чьим управлением? Апача?

ХЗ. Кто-нибудь да найдётся, нашлись же для мавена.

А если другие захотят создать свои репы? И мы получим 100500 реп. Очень удобно. :-)

На жаве не получили. Если не считать локальных да внутрикорпоративных, редко когда приходится больше 1-2-3 общедостуных реп цеплять (одна maven.org, другая скажем для скалы, третья - не припомню).

А кроме того, репы, ориентированные на разные языки, на мой взгляд крайне неудобны.

Об этом я не подумал. Здраво. Но, после того как подумал:

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

2. Не знаю как в генте делают ебилды для жавовских либ - [полу]автоматом или вручную, но наличие заточенного под автоматическую обработку источника позволяет в значительной степени процесс генерации ебилдов автоматизировать.

3. Про колхоз. А почему, собственно? Допустим, если дистр знает, что для установки жава-пакета надо вызвать maven, для питон-пакета - pip, и т.п., то вся проблема сводится к наличию/отсутствию в метаданных пакетов возможности задавать ссылки на пакеты из других языков. Т.е., к примеру, если в pom.xml добавить что-нить такое:

<foreign-dependencies>
    <foreign-dependency>
        <url>python:org.example.packagename</url>
        <version>[1.0,)</version>
    <foreign-dependency>
</foreign-dependencies>

и аналогично в pip-пакеты, и гипотетические c++ пакеты, то дистру опять же достаточно понимать эти метаданные. Т.е., повторюсь, дистру достаточно понимать формат описателей пакетов на разных языках, причём соответствующие либы могут состряпать и авторы языков - если договорятся об одинаковом API =). И не будет никакого кохоза.

dimgel ★★★★★
() автор топика
Ответ на: комментарий от dimgel

Собственно, колхозом является как раз нынешняя ситуация, когда дистры дублируют работу пакетных менеджеров языков, причём ещё и в раскоряку: гента, к примеру, раскладывает жавовские пакеты, именуемые через reverse domain name, в свою двухуровневую структуру категория/пакет, причём категория всегда равна dev-java, а имя пакета я хз как они сочиняют.

dimgel ★★★★★
() автор топика
Ответ на: комментарий от aureliano15

И с ними плохо, и без них.

Не плохо.

А без них придётся таскать с собой все возможные версии либ

Ахинея убогая.

и каждый пакет будет весить десятки метров.

Ахинея убогая.

Ну что вы все такие глупые. Во-первых, из того, что пакет будет весить «десятки метров» - из этого ничего не следует. Будет - дальше что?

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

Никакая мусорная линковка не нужна. Никаких 10метров нет и не будет. Никакие библиотеки таскать не нужно. Не существует такого понятия как «библиотека» в нормальном мире. Существует набор функционала, необходимая часть которого интегрируется в программу.

anonymous
()
Ответ на: комментарий от Iron_Bug

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

Сколько ты там служишь хозяину, нонейм убогий, меня мало волнует. Ты в дерьме - это основное твоё свойство. Осознай сей просто момент и иди дальше повторяй соседям по парте свои 2-3 рандомные фразы.

Животное нихрена в этом мире не видело, животное мыло полы рядом с данным ею хозяином стеком, животное не может отвечать за свой трёп, но оно профессионал. Лизания жоп и мытья полов.

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

anonymous
()
Ответ на: комментарий от aureliano15

К сожалению ты нихрена не понял, и продолжаешь нести ахинею. Свой статической линковкой ты можешь только подтереться. Зачем вы меня доводите своей тупость непроходимой?

Мне тебе посчитать кол-во кода, который инклюдится в хелворд на бусте, а далее показать бинарник?

Как же меня одалевает эта убогая клоунада.

anonymous
()
Ответ на: комментарий от aureliano15

И? Ты не можешь использовать базовые средства дистрибутива для управления зависимостями. Поэтому они должны у тебя быть.

Это какой-то колхоз убогий в виде автоконфа или подобного мусора. Ну не нашел ты нужных либ - дальше что? Как их пользователь поставит? Астралом? Дыра номер один.

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

И всё это кастылится через пистонячье дерьмо - их пакетный менеджер. Никаким образом не проверяется и нихрена вообще ни в какие твое автоконфы не интегрировано. Опять же - как юзеру поставить твои пистонячье дерьмо убогое? А никак. Через астрал.

В конечном итоге из всех этих потуг ничего не следует, кроме того, что полная ахинея.

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

А он может просто уметь в одну систему, которая собирает всё сама. Он выступает в роли враппера. И это в 10раз проще - реализовать одну, нежели 100 разных систем сборки.

anonymous
()
Ответ на: комментарий от anonymous

эк тя расколбасило. но сути это не меняет. программирование на плюсах остаётся сложной задачей, а не игрушкой для нубов вроде тебя.

очевидно, что ты неудачник с пропитым мозгом и никчёмными нервами. из тебя лезет понос, когда тебе говорят очевидные вещи. оставайся в своей незамутнённой неграмотности и дальше. мне наплевать.

Iron_Bug ★★★★★
()
Ответ на: комментарий от dimgel

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

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

в генте, очевидно, пытаются упорядочить тот бардак в системе, который порождает жаба и прочие интерпретаторы. хотя вообще-то это должны делать разработчики этих интерпретаторов. чтобы соответствовать стандарту, а не создавать в ФС нигде не документированную развесистую клюкву. по идее, всё это барахло должно лежать в /usr/share. ибо оно не бинарник и не библиотека, а некий ресурс для какого-то приложения.

Iron_Bug ★★★★★
()

tcc -run коль полон мир открытий чудных ))

Deleted
()

Тебя на реддите говном накормили так ты сюда пришел?

anonymous
()
Ответ на: комментарий от Iron_Bug

Невменяшка, ты мне расскажи о том, почему ты такое никчёмное? Почему я тебя макал в дерьмо в каждом треде, в который ты влезало? Почему любой нонейм тутошний тебя в дерьмо макал? Ты мне это объяснишь?

Далее, ты немного перепутало - кукарекать на меня своей одной извилиной. У меня всё записано. Ты, трепло убогое, выше кукарекало о том, что «я ничего не знаю про кресты» и «я пишу на си», дак вот, невмеяншка, ты уж определись в своих убогих потугах - что ты там делало. Но я тебе заранее скажу - мыло полы.

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

Особенно смешно об обгадившегося нонейма с помойки слушать про «удачников». Убожество, ты вылези из помойки, а не пытайся впарить свою убогую жопу клянча у хозяина «я не уйду в дикрет». Убожество, фу.

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

Что же ещё оно может мне вкукарекнуть? «идиот», «нубы», «памперсы»?

Кстати, куда памперсы пропали? Я изобличил твою убогую рожу? Осознай своё место, поломойка, и не появляйся в подобных тредах.

anonymous
()
Ответ на: комментарий от Iron_Bug

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

Строго говоря, мы несколько о разном.

Во-первых, гентушные коцанные имена java-пакетов (посрав нению с исходными RDN) никакого отношения к FHS не имеют, это вопрос организации гентушного дерева портежей.

Во-вторых, не станешь же ты пулять в общую кучу /lib и /usr/lib и .so, и .jar, и что там у питона и прочих? Бардак случится. Как раз имеет смысл каждому уникальному формату «бинарников» свою помоечку: т.е. если D линкуется с C, нехай ложится в сишный FHS, а вот jar с C не линкуется - нехай у него своя помойка (и свои языко-специфичные пути поиска либ в этой помойке, в случае жавы и прорвы других языков работающих над JVM - classpath).

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

Собственно, я говорил о том, что этот который выше по иерархии мог бы осмысленней взаимодействовать с пакетными менеджерами разных языков, а не пытаться вогнать всё многообразие языков и идеологий в прокрустово ложе сишной FHS.

dimgel ★★★★★
() автор топика
Ответ на: комментарий от dimgel

не станешь же ты пулять в общую кучу /lib и /usr/lib и .so, и .jar, и что там у питона и прочих?

конечно нет. это всё должно валяться в /usr/share/[пистон|жаба|всё прочее]. и чтобы они сами туда лезли, а не требовали каких-то магических настроек от системы и эзотерических знаний от админа. почему сишечка не требует от админа знать ничего, а жаба требует, чтобы админ по уши влезал в клоаку ейных пидсрачников GCов и прочие дебри? это в корне неверно. разработчики должны сделать свою систему совместимой со здравым смыслом и нуждами юзера.

этот который выше по иерархии мог бы осмысленней взаимодействовать с пакетными менеджерами разных языков, а не пытаться вогнать всё многообразие языков и идеологий в прокрустово ложе сишной FHS

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

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 3)
Ответ на: комментарий от dimgel

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

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 3)
Ответ на: комментарий от Iron_Bug

конечно нет. это всё должно валяться в /usr/share/[пистон|жаба|всё прочее]. и чтобы они сами туда лезли

Дошло. Про «чтобы сами лезли» +1.

в этом и есть суть построения системы, а не бардака на винте.

И это дошло.

Глянул как гента раскладывает жава-пакеты - таки в /usr/share. =) Вот только не в /usr/share/java, к сожалению. Т.е. у них сквозной реестр имён по всем языкам, а с юниксовой традицией всё сокращать до нескольких нечитабельных букв, по-прежнему нифига непонятно как они без коллизий живут.

dimgel ★★★★★
() автор топика
Ответ на: комментарий от Iron_Bug

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

А вот именно всякие го и прочее - никакую систему не засирают и живут в одном каталоге со своими путями и всё сами ищут. Вот незадача - оказывается всё как раз наоборот. Как оправдываться?

anonymous
()
Ответ на: комментарий от anonymous

детка, это ты ничего не знаешь о сишном софте. но это твои проблемы, а не проблемы опенсорца. и вообще разговор был не об этом. но ты просто не догнал.

Iron_Bug ★★★★★
()
Ответ на: комментарий от dimgel

непонятно как они без коллизий живут.

Но как-то живут, что, в свою очередь, доказывает, что в мире opensource не всё так плохо. :-)

aureliano15 ★★
()
Ответ на: комментарий от aureliano15

(даёшь пятую страницу!)

что, в свою очередь, доказывает, что в мире opensource не всё так плохо. :-)

Хочешь сказать, ещё не успели наговнокодить до коллизий? Чё-т не верится. Это мейнтейнеры воду мутят.

dimgel ★★★★★
() автор топика
Ответ на: комментарий от aureliano15

Собственно, отдельная помойка /usr/src/java могла бы быть удобной и с точки зрения компактности classpath. Сейчас он дикий, каждую зависимость явно перечисляет: /usr/share/ant:/usr/share/commons-io:/usr/share/и_т.д. С другой стороны, если все jar-ы в одной куче, сканировать их в поисках нужного класса запаришься - это не сишные либы, которым в одной куче хорошо, тут по-другому делается. С третьей стороны, система могла бы это кешировать; или можно внутри /usr/share/java подкатегории забабахать (но не такие как щас - по одному пакету на каталог).

dimgel ★★★★★
() автор топика
Ответ на: комментарий от dimgel

(даёшь пятую страницу!)

У кого как. У меня лично всё ещё первая. Это задаётся в настройках («Число комментариев на странице»).

Собственно, отдельная помойка /usr/src/java могла бы быть удобной и с точки зрения компактности classpath. Сейчас он дикий, каждую зависимость явно перечисляет: /usr/share/ant:/usr/share/commons-io:/usr/share/и_т.д. С другой стороны, если все jar-ы в одной куче, сканировать их в поисках нужного класса запаришься - это не сишные либы, которым в одной куче хорошо, тут по-другому делается.

Возможно. Везде есть свои недоработки. Но, думаю, конкретно эта недоработка связана с тем, что майнтейнеры и те, кто определяет структуру каталогов, просто не запариваются с разными инструментами, как там принято. Ведь разберись они с явой, тут же аналогичные претензии возникнут со стороны питонистов. А потом со стороны лисперов. А потом со стороны не знаю кого ещё. Конечно, лучше бы, чтоб эти проблемы решали. Но ещё лучше, имхо, если бы разработчики разных инструментов понимали, что оси бывают разными, и с самого начала затачивали свои инструменты для использования в разных осях, которые и должны следить за порядком у себя. А не рассчитывали бы, что их инструмент — это центр it мира, и все оси будут подстраивать свои fhs под их инструмент, который сегодня есть, а завтра — нет.

aureliano15 ★★
()
Ответ на: комментарий от dimgel

И тут мне вспоминается maven.org (и централизованные репы других языков), куда разрабы сами деплоят свои либы. Будь такое для сей, вопрос «откуда скачать» не стоял бы

Кстати, заказывали — получите. И гентушники туда тоже понабежали (в обсуждение, я имею в виду). :-)

aureliano15 ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.