ALT Linux Community general discussions
 help / color / mirror / Atom feed
From: "Денис Смирнов" <mithraen@freesource.info>
To: Alexey Morsov <samurai@ricom.ru>
Cc: community@altlinux.ru
Subject: [Comm] Re: Атаки типа buffer overflow
Date: Mon, 16 Aug 2004 13:41:22 +0400
Message-ID: <20040816094122.GA8755@dhcppc2> (raw)
In-Reply-To: <412074CB.9090801@ricom.ru>

On Mon, Aug 16, 2004 at 12:48:11PM +0400, Alexey Morsov wrote:

 AM> Т.е. ваше мнение что на Си нужно (и достаточно безопасно) писать 
 AM> только системное ПО (модули, ядра, драйвера)? А приложения (и уж 
 AM> тем более взаимодействующие с интернет) на чем-то ином?

Именно так.
 
 AM> А на чем тогда 

Хоть на Visual Basic. Я абсолютно серьёзно.

Если совсем серьёзно, то при программировании по Windows лучше всего
использовать любой .NET язык, а при портабельном программировании либо
Java (из распространённых), либо, что гораздо лучше, Tcl.

 AM> (вроде тотже апач, mysql, squid на Си и писаны)?

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

Кстати апач, mysql и squid не совсем прикладные программы всё-таки, и при
их написании вставки кода на си отнюдь не помешают (особенно это касается
апача и сквида).

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

Всё это прекрасно оптимизируется. Я не удивлюсь если движок типа SQLite,
написаный на OCaml, окажется:
а) быстрее;
б) надёжнее;
в) менее требовательным к памяти;
г) легче расширяемым;

Но это всё _сейчас_ имеет смысл только в mission critical приложениях.
Просто потому, что хороших программистов на языках отличных от C++ и жабы
за разумные деньги найти сложно, и они _потребуют_ великолепной зарплаты,
соц программ, хорошего менеджмента. Далеко не всегда руководство просто
достаточно квалифицировано, чтобы создать такие тепличные условия (дело не
в деньгах даже, программисты за 2-3k$ реально дешевле программистов за
500-1000$).

Поэтому:

1. делается декомпозиция программы на _модули_ (ООП в жопу)
2. для каждого модуля продумывается на каком языке его стоит писать
3. каждый модуль либо пишется своими силами, либо заказывается у кого-то
сильно более крутого (если модуль критичен по производительности)

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

логика -- зависит от её объёмов, в порядке убывания: OCaml, Tcl, Java, C++

вещи, требующие максимальной производительности -- OCaml, C++, Java

Ну и далее смотреть и смотреть по ситуации.

Главный принцип программиста -- лень.
Второй главный принцип -- "разделяй и властвуй"

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

В случае свободных программ не зазорно использовать в качестве
_расширений_ проприетарные библиотеки (IMHO). Например написать патч к
mplayer, который бы использовал Intel'овские примитивы для DSP _если они
есть у пользователя_ было бы полезно (это как пример).

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

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

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

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

Если же вопрос в плане "чему учиться?" то я рекомендую:

1. Tcl (обязательно)
2. OCaml (мозги несколько сдвигает, всё не могу найти время чтобы
полностью с ним разобраться, но уже даже теоретическое знание изменило
стиль написания кода на других языках)
3. Java (придётся)
4. Perl (знать надо, но лучше стараться на нём не писать, изучать лучше
после вышеперечисленность, мозги портит почти как бейсик, по себе сужу)

Стоит обратить внимание на Lisp -- так говорят умные люди, которым я
доверяю. Времени пока не нахожу.

-- 
С уважением, Денис

http://freesource.info



  reply	other threads:[~2004-08-16  9:41 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-12 12:47 [COMM] " Alexey Morsov
2004-08-15 16:39 ` [Comm] " Денис Смирнов
2004-08-16  8:48   ` Alexey Morsov
2004-08-16  9:41     ` Денис Смирнов [this message]
2004-08-16 10:12       ` Aleksey Novodvorsky
2004-08-16 10:25         ` Maxim Tyurin
2004-08-16 10:37           ` Aleksey Novodvorsky

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=20040816094122.GA8755@dhcppc2 \
    --to=mithraen@freesource.info \
    --cc=community@altlinux.ru \
    --cc=samurai@ricom.ru \
    /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 Community general discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://lore.altlinux.org/community/0 community/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 community community/ http://lore.altlinux.org/community \
		mandrake-russian@linuxteam.iplabs.ru community@lists.altlinux.org community@lists.altlinux.ru community@lists.altlinux.com
	public-inbox-index community

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


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