ALT Linux Team development discussions
 help / color / mirror / Atom feed
From: Michael Shigorin <mike@osdn.org.ua>
To: devel@lists.altlinux.org
Subject: Re: [devel] OCaml packaging
Date: Sat, 23 Dec 2006 12:13:08 +0200
Message-ID: <20061223101308.GU12587@osdn.org.ua> (raw)
In-Reply-To: <20061223121104.5aa2fa0f.bga@altlinux.org>

On Sat, Dec 23, 2006 at 12:11:04PM +0300, Grigory Batalov wrote:
> Остаётся вопрос из "Проблемы 1": как паковать и паковать ли
> исполняемый байт-код? Ну и вообще, что думает сообщество о
> предложенном материале?

Всё-таки ещё раз порекомендую участникам команды, которым
доводится сталкиваться с принятием неоднозначных решений,
почитать про SWOT-анализ[1], простая же штука.  Разве что
для себя порой воспринимаю "SWOT" как "плюс-минус на
сейчас-завтра" вместо рыночных факторов.

В данном разе я бы нарисовал по минимуму так
(не пытаюсь отабличить, бо ещё разъедется):


1. собирать байткод

Strengths
* переносимость между архитектурами

Weaknesses
* меньшая производительность
* необходимость интерпретатора

Opportunities
-

Threats
* возможность съезда бинарной совместимости,
  которой апстрим не озадачивается, и неочевидных
  грабель


2. собирать натив

Strengths
* большая производительность
* большая компактность (?)

Weaknesses
* непереносимость между архитектурами as-is

Opportunities
-

Threats
-


3. собирать байткод с подвесным интерпретатором

Strengths
* отсутствие зависимости от внешнего интерпретатора

Weaknesses
* меньшая производительность байткода плюс добавленный
  объём VM

Opportunities
* возможность запуска при наличии нативного внешнего 
  интерпретатора на ненативной платформе

Threats
* при сборке пакета "мусор" в виде байткода может быть
  стрипнут при зачистке buildroot => неработоспособность


Из всего этого лично мне как дистрибутивное решение однозначно
видится сборка нативного кода, поскольку все возникающие
(описанные) проблемы закрываются rpm и средой сборки.


[1] http://www.iteam.ru/publications/strategy/section_16/article_1185/print/

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/


      reply	other threads:[~2006-12-23 10:13 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-23  9:11 Grigory Batalov
2006-12-23 10:13 ` Michael Shigorin [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20061223101308.GU12587@osdn.org.ua \
    --to=mike@osdn.org.ua \
    --cc=devel@lists.altlinux.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

ALT Linux Team development discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \
		devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru
	public-inbox-index devel

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://lore.altlinux.org/org.altlinux.lists.devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git