Re: Контейнеры и кросс-компиляция
On Thu, Jun 25, 2015 at 01:49:33PM +0300, Andrey Tataranovich wrote: On Thu, 25 Jun 2015 10:23:32 +0300 Vladimir Zhbanov vzhba...@gmail.com wrote: Возникла у меня проблема: обновился до jessy и сломалась MinGW'шная кросс-компиляция одной нужной мне программы. Откатываться обратно на wheezy на рабочей машине не хочу, разобраться с налёту, что чего поломало, не получилось. Вот решил попробовать засунуть wheezy в контейнер и попробовать собирать в нём. Зависеть от внешних хостеров не хотелось бы, обламывали уже в самый неподходящий момент. Отсюда вопрос: подскажите, пожалуйста, что проще всего развернуть без чтения тонны документации? Попробуйте schroot. Прост в настройке и вполне достаточен для отката к wheezy. Собственно вопрос тот же, что и для chroot: а с другим (более старым) ядром там можно работать параллельно с ядром основной системы? Просто у меня на работе всего одна машина, и я на ней ещё и работаю иногда :) -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150625120608.GB8231@localhost.localdomain
Re: Контейнеры и кросс-компиляция
25.06.2015 14:58, Vladimir Zhbanov пишет: On Thu, Jun 25, 2015 at 10:36:04AM +0300, Mikhail A Antonov wrote: 25.06.2015 10:23, Vladimir Zhbanov пишет: Здравствуйте. Возникла у меня проблема: обновился до jessy и сломалась MinGW'шная кросс-компиляция одной нужной мне программы. Откатываться обратно на wheezy на рабочей машине не хочу, разобраться с налёту, что чего поломало, не получилось. Вот решил попробовать засунуть wheezy в контейнер и попробовать собирать в нём. Зависеть от внешних хостеров не хотелось бы, обламывали уже в самый неподходящий момент. Отсюда вопрос: подскажите, пожалуйста, что проще всего развернуть без чтения тонны документации? Зависит от того что делает программа. Может тебе хватит debootstrap и chroot. Программа - geda-gaf, но пока guile, которая туда встраивается. Проблема в том, что guile создаёт объектный код в своём собственном формате, и эти объектные файлы потом используются как есть для кросс-компиляции. Она содержит свой собственный компилятор, который должен выводить одинаковый код и в Linux, и в Windows, и вот эта одинаковость у меня поломалась после обновления. И я пока подозреваю, что проблема в библиотеках mingw, но вполне допускаю, что где-то глубже, может быть даже в ядре, libc, libffi и т. д., так как для кросс-компиляции под Windows guile необходимо сначала скомпилировать с абсолютно той же версией в Linux, чтоб она выдавала правильный объектный код. Вот такая, блин, зависимость. Создавать себе окружение и отлаживать всё это в Windows мне не улыбается. Я от неё устал ещё лет 15 как тому. Я это всё, собственно, к чему: если я правильно ничего не понимаю, chroot использует именно то ядро, которое уже загружено, а мне может понадобиться другое. Тогда удобнее всего будет виртуалбокс с гуём. Можно повозиться с всякими libvirt и их virt-manager, но мне они не понравились. Тебе нужна полноценная виртуальная машина. Всё контейнерное использует одно ядро и на систему и все контейнеры. -- Best regards, Mikhail - WWW: http://www.antmix.ru/ XMPP: ant...@stopicq.ru signature.asc Description: OpenPGP digital signature
Re: Контейнеры и кросс-компиляция
On Thu, 25 Jun 2015 10:23:32 +0300 Vladimir Zhbanov vzhba...@gmail.com wrote: Возникла у меня проблема: обновился до jessy и сломалась MinGW'шная кросс-компиляция одной нужной мне программы. Откатываться обратно на wheezy на рабочей машине не хочу, разобраться с налёту, что чего поломало, не получилось. Вот решил попробовать засунуть wheezy в контейнер и попробовать собирать в нём. Зависеть от внешних хостеров не хотелось бы, обламывали уже в самый неподходящий момент. Отсюда вопрос: подскажите, пожалуйста, что проще всего развернуть без чтения тонны документации? Попробуйте schroot. Прост в настройке и вполне достаточен для отката к wheezy. -- WBR, Andrey Tataranovich -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150625134933.1b11ccac@dragoncore.local
Re: Контейнеры и кросс-компиляция
On Thu, Jun 25, 2015 at 10:36:04AM +0300, Mikhail A Antonov wrote: 25.06.2015 10:23, Vladimir Zhbanov пишет: Здравствуйте. Возникла у меня проблема: обновился до jessy и сломалась MinGW'шная кросс-компиляция одной нужной мне программы. Откатываться обратно на wheezy на рабочей машине не хочу, разобраться с налёту, что чего поломало, не получилось. Вот решил попробовать засунуть wheezy в контейнер и попробовать собирать в нём. Зависеть от внешних хостеров не хотелось бы, обламывали уже в самый неподходящий момент. Отсюда вопрос: подскажите, пожалуйста, что проще всего развернуть без чтения тонны документации? Зависит от того что делает программа. Может тебе хватит debootstrap и chroot. Программа - geda-gaf, но пока guile, которая туда встраивается. Проблема в том, что guile создаёт объектный код в своём собственном формате, и эти объектные файлы потом используются как есть для кросс-компиляции. Она содержит свой собственный компилятор, который должен выводить одинаковый код и в Linux, и в Windows, и вот эта одинаковость у меня поломалась после обновления. И я пока подозреваю, что проблема в библиотеках mingw, но вполне допускаю, что где-то глубже, может быть даже в ядре, libc, libffi и т. д., так как для кросс-компиляции под Windows guile необходимо сначала скомпилировать с абсолютно той же версией в Linux, чтоб она выдавала правильный объектный код. Вот такая, блин, зависимость. Создавать себе окружение и отлаживать всё это в Windows мне не улыбается. Я от неё устал ещё лет 15 как тому. Я это всё, собственно, к чему: если я правильно ничего не понимаю, chroot использует именно то ядро, которое уже загружено, а мне может понадобиться другое. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150625115832.GA8231@localhost.localdomain
Re: Контейнеры и кросс-компиляция
On Thu, Jun 25, 2015 at 03:18:57PM +0300, Eugene Berdnikov wrote: On Thu, Jun 25, 2015 at 02:58:32PM +0300, Vladimir Zhbanov wrote: Программа - geda-gaf, но пока guile, которая туда встраивается. Проблема в том, что guile создаёт объектный код в своём собственном формате, и эти объектные файлы потом используются как есть для кросс-компиляции. Она содержит свой собственный компилятор, который должен выводить одинаковый код и в Linux, и в Windows, и вот эта одинаковость у меня поломалась после обновления. И я пока подозреваю, что проблема в библиотеках mingw, но вполне допускаю, что где-то глубже, может быть даже в ядре, libc, libffi и т. д., так как для кросс-компиляции под В библиотеках -- да, могут быть критичные изменения, а вот вероятность того, что на результат как-то влияет ядро (кроме зависимостей) близка к абсолютному нулю. Так что запуск полноценной ВМ вряд ли оправдан. IMHO, здесь должно хватить простого chroot'а. Вот-вот, их-то, зависимости, я и имел в виду, когда говорил о ядре. Поскольку у меня система почти всегда stable/testing с чуть-чуть или сразу много testing. И я сразу прыгнул с ядра 3.2.x на 4.0.x. Соответственно, думаю, оно что-то могло потянуть за собой. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150625123421.GD8231@localhost.localdomain
Re: Контейнеры и кросс-компиляция
On Thu, 25 Jun 2015 15:06:08 +0300 Vladimir Zhbanov vzhba...@gmail.com wrote: Собственно вопрос тот же, что и для chroot: а с другим (более старым) ядром там можно работать параллельно с ядром основной системы? Просто у меня на работе всего одна машина, и я на ней ещё и работаю иногда :) Вам не нужно старое ядро в chroot. Поднимите в schroot окружение wheezy и оно будет нормально работать с ядром из jessie. У меня как раз так и работало. -- WBR, Andrey Tataranovich -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150625165132.40432871@dragoncore.local
Re: Контейнеры и кросс-компиляция
On Thu, Jun 25, 2015 at 02:58:32PM +0300, Vladimir Zhbanov wrote: Программа - geda-gaf, но пока guile, которая туда встраивается. Проблема в том, что guile создаёт объектный код в своём собственном формате, и эти объектные файлы потом используются как есть для кросс-компиляции. Она содержит свой собственный компилятор, который должен выводить одинаковый код и в Linux, и в Windows, и вот эта одинаковость у меня поломалась после обновления. И я пока подозреваю, что проблема в библиотеках mingw, но вполне допускаю, что где-то глубже, может быть даже в ядре, libc, libffi и т. д., так как для кросс-компиляции под В библиотеках -- да, могут быть критичные изменения, а вот вероятность того, что на результат как-то влияет ядро (кроме зависимостей) близка к абсолютному нулю. Так что запуск полноценной ВМ вряд ли оправдан. IMHO, здесь должно хватить простого chroot'а. -- Eugene Berdnikov -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150625121857.gp15...@protva.ru
Re: Контейнеры и кросс-компиляция
В сообщении от [Чт 2015-06-25 15:16 +0300] Vladimir Zhbanov vzhba...@gmail.com пишет: Ubuntu ставить мне некуда на работе. Я так понимаю, в Debian это docker.io? Если да, то вот что пишет 'apt-cache show docker.io': ... Using docker.io on non-amd64 hosts is not supported at this time. Please be careful when using it on anything besides amd64. ... Это правда? А то у меня всего одна i686. Видимо да, только 64-bit, но по вашим ответам я понял, что вам нужно ещё и ядро, тогда докер вам не подходит, потому что он контейнер для приложений, а вам нужен контейнер для операционной системы. В этом случае используйте debootstrap и не забудьте установить нужное ядро. Для jessie systemd-nspawn -bD ~/debian-tree/ Для wheezy (там ещё не было systemd по умолчанию). systemd-nspawn -D ~/debian-tree/ /sbin/init То есть вы можете загрузить внутри контейнера полноценную ОС, а не одну единственную оболочку как в chroot [1]. [1] http://lexpr.ru/node/504 -- http://google.com/+РусланКоротаев -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150625134311.GA1920@debian
Re: Контейнеры и кросс-компиляция
On Thu, Jun 25, 2015 at 02:49:11PM +0500, Руслан Коротаев wrote: В сообщении от [Чт 2015-06-25 10:23 +0300] Vladimir Zhbanov vzhba...@gmail.com пишет: Возникла у меня проблема: обновился до jessy и сломалась MinGW'шная кросс-компиляция одной нужной мне программы. Откатываться обратно на wheezy на рабочей машине не хочу, разобраться с налёту, что чего поломало, не получилось. Вот решил попробовать засунуть wheezy в контейнер и попробовать собирать в нём. Зависеть от внешних хостеров не хотелось бы, обламывали уже в самый неподходящий момент. Отсюда вопрос: подскажите, пожалуйста, что проще всего развернуть без чтения тонны документации? Вам подойдет docker, если не хотите возится с настройкой, то попробуйте Ubuntu Snappy, там всё заточено под docker. Ubuntu ставить мне некуда на работе. Я так понимаю, в Debian это docker.io? Если да, то вот что пишет 'apt-cache show docker.io': ... Using docker.io on non-amd64 hosts is not supported at this time. Please be careful when using it on anything besides amd64. ... Это правда? А то у меня всего одна i686. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150625121650.GC8231@localhost.localdomain
Re: Контейнеры и кросс-компиляция
25.06.2015 16:43, Руслан Коротаев пишет: В сообщении от [Чт 2015-06-25 15:16 +0300] Vladimir Zhbanov vzhba...@gmail.com пишет: Ubuntu ставить мне некуда на работе. Я так понимаю, в Debian это docker.io? Если да, то вот что пишет 'apt-cache show docker.io': ... Using docker.io on non-amd64 hosts is not supported at this time. Please be careful when using it on anything besides amd64. ... Это правда? А то у меня всего одна i686. Видимо да, только 64-bit, но по вашим ответам я понял, что вам нужно ещё и ядро, тогда докер вам не подходит, потому что он контейнер для приложений, а вам нужен контейнер для операционной системы. В этом случае используйте debootstrap и не забудьте установить нужное ядро Не важно установишь ли ты ядро или нет. Ядро будет использоваться то, которое использует корневая ОС. В случае если само по себе ядро не нужно, а нужны только библиотеки - обычного chroot хватит. Все остальные контейнеры - это продвинутые версии chroot. На один-два раза я бы сделал chroot и ничего бы не читал. Чаще/больше - настроил бы schroot на нужные мне операции. А докер это вообще надстройка над lxc. А сам по себе lxc без проблем заводится на i686. -- Best regards, Mikhail - WWW: http://www.antmix.ru/ XMPP: ant...@stopicq.ru signature.asc Description: OpenPGP digital signature
Re: Контейнеры и кросс-компиляция
В сообщении от [Чт 2015-06-25 17:01 +0300] Mikhail A Antonov mikh...@antfam.ru пишет: Не важно установишь ли ты ядро или нет. Ядро будет использоваться то, которое использует корневая ОС. Да, вы правы, нужно было написать не ядро, а архитектуру. Но в нашем примере, если я правильно понял, нужно воссоздать окружение для сборки или компиляции на основе debian wheezy 32-bit, на хосте с jessie 32-bit. Можно использовать chroot, можно virtualbox, а можно в контейнере, тем более systemd-nspawn идет «из коробки». Кому как удобнее. -- http://google.com/+РусланКоротаев -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150625160833.GA3486@debian
Re: Контейнеры и кросс-компиляция
25.06.2015 19:08, Руслан Коротаев пишет: В сообщении от [Чт 2015-06-25 17:01 +0300] Mikhail A Antonov mikh...@antfam.ru пишет: Не важно установишь ли ты ядро или нет. Ядро будет использоваться то, которое использует корневая ОС. Да, вы правы, нужно было написать не ядро, а архитектуру. Но в нашем примере, если я правильно понял, нужно воссоздать окружение для сборки или компиляции на основе debian wheezy 32-bit, на хосте с jessie 32-bit. Можно использовать chroot, можно virtualbox, а можно в контейнере, тем более systemd-nspawn идет «из коробки». Кому как удобнее. Да, всё верно. Я сторонник отсутствия systemd на своих машинах и из коробки его лучше выкинуть. Но это кому как удобнее. -- Best regards, Mikhail - WWW: http://www.antmix.ru/ XMPP: ant...@stopicq.ru signature.asc Description: OpenPGP digital signature
Re: Контейнеры и кросс-компиляция
25.06.2015 10:23, Vladimir Zhbanov пишет: Здравствуйте. Возникла у меня проблема: обновился до jessy и сломалась MinGW'шная кросс-компиляция одной нужной мне программы. Откатываться обратно на wheezy на рабочей машине не хочу, разобраться с налёту, что чего поломало, не получилось. Вот решил попробовать засунуть wheezy в контейнер и попробовать собирать в нём. Зависеть от внешних хостеров не хотелось бы, обламывали уже в самый неподходящий момент. Отсюда вопрос: подскажите, пожалуйста, что проще всего развернуть без чтения тонны документации? Зависит от того что делает программа. Может тебе хватит debootstrap и chroot. -- Best regards, Mikhail - WWW: http://www.antmix.ru/ XMPP: ant...@stopicq.ru signature.asc Description: OpenPGP digital signature
Re: Контейнеры и кросс-компиляция
В сообщении от [Чт 2015-06-25 10:23 +0300] Vladimir Zhbanov vzhba...@gmail.com пишет: Возникла у меня проблема: обновился до jessy и сломалась MinGW'шная кросс-компиляция одной нужной мне программы. Откатываться обратно на wheezy на рабочей машине не хочу, разобраться с налёту, что чего поломало, не получилось. Вот решил попробовать засунуть wheezy в контейнер и попробовать собирать в нём. Зависеть от внешних хостеров не хотелось бы, обламывали уже в самый неподходящий момент. Отсюда вопрос: подскажите, пожалуйста, что проще всего развернуть без чтения тонны документации? Вам подойдет docker, если не хотите возится с настройкой, то попробуйте Ubuntu Snappy, там всё заточено под docker. Запустите Snappy локально в KVM или в облаке [1]: $ kvm -m 512 -redir :8090::80 -redir :8022::22 ubuntu-15.04-snappy-amd64-generic.img $ ssh -p 8022 ubuntu@localhost Установите docker [2]: $ sudo snappy install docker Запустите контейнер с wheezy: $ docker run -t -i debian:wheezy /bin/bash Тоже самое можно сделать через debootstrap и systemd-nspawn (в мане есть пример), но у докера есть свой репозиторий с образами (Docker Hub), там вы можете найти специальный образ под вашу задачу или решить задачу самому, а потом создать образ и поделится с другими. Это не так сложно, достаточно прочитать несколько первых страниц руководства [3], оно того стоит. [1] https://developer.ubuntu.com/en/snappy/start/ [2] https://developer.ubuntu.com/en/snappy/tutorials/using-snappy/ [3] https://docs.docker.com/userguide/ -- http://google.com/+РусланКоротаев -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150625094911.GA2022@debian
Re: контейнеры
On Fri, Jan 11, 2008 at 03:40:16PM +0300, Alexey Pechnikov wrote: NS NSP.P.S. Имхо, для открытого софта ява не пригодна, для проприетарного годится NSтолько тогда, когда надо закрыть исходники (любой ценой, даже много теряя в NSкачестве софта и делая разработку намного дороже), но нет желания/возможности NSписать на С. Работая программером на яве, с большим интересом читал эту дискуссию. Но вот на этом месте уже не выдержал. Мы пишем коммерческий серверный код, получаем за него деньги. Чистые капиталисты. Все библиотеки, которые мы успользуем - проекты с открытым кодом. Так что на яве написано много открытого кода, который используется для решения реальных задач реальных клиентов. -- Nikita Salnikov-Tarnovski AS Webmedia +3725264536 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: контейнеры
12.01.08, Nikita Salnikov-Tarnovski[EMAIL PROTECTED] написал(а): Мы пишем коммерческий серверный код, получаем за него деньги. Чистые капиталисты. Не-а, вы пролетарии. Капиталисты - те, кто вас нанял.
Re: контейнеры
Nikita Salnikov-Tarnovski - Alexey Pechnikov @ Sat, 12 Jan 2008 11:23:40 +0200: NS Работая программером на яве, с большим интересом читал эту дискуссию. Но NS вот на этом месте уже не выдержал. Лучше уйти отсюда. Ничего интересного кроме траты времени эта дискуссия не даст. К сожалению. NS Мы пишем коммерческий серверный код, получаем за него деньги. Чистые капиталисты. NS Все библиотеки, которые мы успользуем - проекты с открытым кодом. Так NS что на яве написано много открытого кода, который используется для NS решения реальных задач реальных клиентов.. Вы не одиноки ;) -- .''`. Kirill A. Korinskiy [EMAIL PROTECTED] : :' : proud (maniac)? (developer|hacker) `. `'` http://catap.ru/ - +7 (916) 3-604-704 - xmpp:[EMAIL PROTECTED] `- Debian - when you have better things to do than fixing systems -- madduck pgpindGkwJLlW.pgp Description: PGP signature
Re: контейнеры
В сообщении от Monday 14 January 2008 19:20:52 Kirill A. Korinskiy написал(а): Nikita Salnikov-Tarnovski - Alexey Pechnikov @ Sat, 12 Jan 2008 11:23:40 +0200: NS Работая программером на яве, с большим интересом читал эту дискуссию. Но NS вот на этом месте уже не выдержал. Лучше уйти отсюда. Ничего интересного кроме траты времени эта дискуссия не даст. К сожалению. NS Мы пишем коммерческий серверный код, получаем за него деньги. Чистые капиталисты. NS Все библиотеки, которые мы успользуем - проекты с открытым кодом. Так NS что на яве написано много открытого кода, который используется для NS решения реальных задач реальных клиентов.. Вы не одиноки ;) Мы пишем на тикле под разные ОС (линукс-сервера, винмобайл, виндоус разных версий на десктопе). Что на яве _можно_ писать, согласен, но на тикле _у нас_ получается быстрее и надежнее. Я с ява работал (в том числе с j2me), а вы на тикле много написали? Если у вас есть аргументы для сравнения вышеназванных технологий, расскажите. Иначе получается, что ява лучше тем, что вы с ней умеете работать.
Re: контейнеры
Alexey Pechnikov - debian-russian@lists.debian.org @ Thu, 10 Jan 2008 22:45:53 +0300: AP Прикручивание томкатов с апачами и нужными библиотеками и классами доступа к AP БД (и указание их параметров) иначе назвать не могу. Ужас. Надругательство. Конечно. Для разработки и отладки я использую intellij idea и оттуда стартую tomcat. Для установки приложения я делаю deb'ы. Ужас, правда? Угу, много. j2me, j2se, j2ee. Причем первая уже умерла т.к. на телефонах/кпк можно запускать se. AP На первой, которую вы назвали умершей, написана туча приложений, для которых AP нет исходников. Как следствие, теперь активно пишут эмуляторы. Да и на многих AP сотовых это единственно доступная реализация. Вот тут появляется действительно минус явы. Можно распространять софт без исходника. Хотя есть jad… Хм. Да. В прямом смысле этого слова в java нет генерации кода. Но после lisp'а генерации кода нет нигде ;) AP В тикле есть. Тот же самый принцип - все есть строка, со всеми вытекающими. AP Скорость работы? Полно вам - написать нужную функцию на С и оформить в AP модуль, обращаясь потом к этой функции напрямую, много эффективнее, чем AP делать иерархию классов с конструкторами/деструкторами в каждом. Сменив AP фабрики классов на динамическую генерацию кода, обратно уже не вернусь.. 1) Иногда OO парадигма удобна. 2) Список генерировать намного, намного проще. Вы просто не работали с lisp. Зато это показатель популярности технологии. И чем больше написано, тем больше вероятность что то что тебе будет нужно уже написано. AP Ну тогда странно, что j2me вы мертвой назвали. По вашему критерию me живее AP многих живых. Я ее назвал мертвой т.к. sun сказала что развивать ее дальше не имеет смысла. Т.к. на pda можно пускать уже se. AP Это низкоуровневый интерфейс. Посмотрите, к примеру, функции работы с БД из AP OpenACS. Смотрите, например, hibernate AP А вы себе представляете стоимость модернизации и поддержки такого решения? При AP достаточно длительном жизненном цикле продукта затраты на создание становятся AP много меньше затрат на адаптацию и разработку модулей. С такой логикой можно отказаться и от db, а перейти на написание своей. Правда? AP Умея писать серверный код на ява, вы не напишите на той же яве программу AP для КПК. Почему? AP На тикле я могу легко переключиться с создания веб-портала на разработку AP программы анкетирования на смартфонах или работу с веб-камерой под AP оффтопик. Хм. А слабо на tcl да с web camera подключаемая по usb на macosx? AP К примеру, набор тиклевских функций для создания файлов в формате ms AP excel 2003 xml имеет размер в несколько килобайт и не имеет никаких AP зависимостей, что позволяет его использовать с любым интерпретатором AP тикля (в том числе, с написанным на ява интерпретатором). А в java есть native код для создания xsl файлов… Тоже без зависимостей. Весит jar не много. А в xml от офиса есть огранечение на обьем. Т.е. не огранечение а достаточно большой xml он просто не откроет. Или съест столько памяти, что лучше вешаться. AP Я на его создание потратил пару дней, зато при необходимости могу очень AP быстро модифицировать (прочитать код нужной функции и ее поправить), в AP отличии от иерархии классов на ява (классы ячейка, строка, лист, рабочая AP книга), где нужно еще тратить время на понимание структуры (нужно в том AP числе изучить _все_ конструкторы или деструкторы, чтобы понять порядок AP инициализации нужных переменных). Хм. Спорно. Очень спорно. -- .''`. Kirill A. Korinskiy [EMAIL PROTECTED] : :' : proud (maniac)? (developer|hacker) `. `'` http://catap.ru/ - +7 (916) 3-604-704 - xmpp:[EMAIL PROTECTED] `- Debian - when you have better things to do than fixing systems -- madduck pgpxMllPVRHQM.pgp Description: PGP signature
Re: контейнеры
В сообщении от Friday 11 January 2008 13:32:03 Kirill A. Korinskiy написал(а): Alexey Pechnikov - debian-russian@lists.debian.org @ Thu, 10 Jan 2008 22:45:53 +0300: AP Прикручивание томкатов с апачами и нужными библиотеками и классами доступа к AP БД (и указание их параметров) иначе назвать не могу. Ужас. Надругательство. Конечно. Для разработки и отладки я использую intellij idea и оттуда стартую tomcat. Я использую nano или редактор в mc. Как-то оттуда не очень удобно томкат запускать. Использование всяческих сред разработки и т.п. дело сугубо личное, но они далеко не всем нужны и совсем никуда не годится, если без них нельзя обойтись. Для установки приложения я делаю deb'ы. Ужас, правда? Да, ужас. Ставим опенофис и открытую яву. Открываем xml-документ m$ office и все висит. Оказывается, надо ставить сановскую яву. С ней xslt-процессинг на яве чуть лучше, но большой документ тоже не открыть. И что в этом хорошего? Вот тут появляется действительно минус явы. Можно распространять софт без исходника. Хотя есть jad… Беда в том, что открытые компоненты зачастую используют закрытые. И если из многообразия софта на яве выкинуть весь тот, что пользуется закрытыми компонентами, картина становится печальной. Притом разработчики зачастую и выбирают яву в целях спрятать исходные коды, так что ситуация меняться не будет. 1) Иногда OO парадигма удобна. Иногда. В тикле есть ресколько ОО-реализаций, выбирайте. 2) Список генерировать намного, намного проще. Вы просто не работали с lisp. Тикль работает со списками, взяв эту идею из лиспа. Попробуйте. Методологии все есть список и все есть строка отнюдь не противоречивы. AP А вы себе представляете стоимость модернизации и поддержки такого решения? При AP достаточно длительном жизненном цикле продукта затраты на создание становятся AP много меньше затрат на адаптацию и разработку модулей. С такой логикой можно отказаться и от db, а перейти на написание своей. Правда? AP Умея писать серверный код на ява, вы не напишите на той же яве программу AP для КПК. Почему? Потому что нет разработки, а есть использование компонентов. На сервере вы работаете с совершенно другими компонентами. Это как вижуал бейсик - сам язык настолько слаб, что без сторонних расширений (com-объекты, activex) ничего не умеет. Ява в этом отношении получше, но тоже требует множества чужого кода. Я не против повторного использования кода, но _модульного_ кода, где нет зависимости от десятков различных классов (а то и еще хуже - конкретной их реализации). В принципе, это все следствие закрытости многих компонентов, когда приходится писать тучи оберток, но зачем такие проблемы себе создавать, выбирая яву. Хм. А слабо на tcl да с web camera подключаемая по usb на macosx? В винде пробовал три способа, сейчас работаю через directx, поскольку самый переносимый способ (directx какой-нибудь версии есть во всех виндах). Так что при наличии драйвера для мака сделать можно, вопрос лишь в том, как добиться совместимости со всеми версиями ОС. Но не имея машины с MacOS не возьмусь. AP К примеру, набор тиклевских функций для создания файлов в формате ms AP excel 2003 xml имеет размер в несколько килобайт и не имеет никаких AP зависимостей, что позволяет его использовать с любым интерпретатором AP тикля (в том числе, с написанным на ява интерпретатором). А в java есть native код для создания xsl файлов… Тоже без зависимостей. Весит jar не много. jar это архив, еще бы он весил много. Это открытый компонент? А в xml от офиса есть огранечение на обьем. Т.е. не огранечение а достаточно большой xml он просто не откроет. Или съест столько памяти, что лучше вешаться. Файлы в десятки тысяч записей клиенты свободно открывают в m$ office и виндовом openoffice. Линуксовый опенофис вешается (на мощном компе) при попытке открыть файл с сотней записей. Я просто восхищен переносимостью решений на ява. P.S. Опенофис на платформе arm есть, но... где бы взять сановскую яву для arm, а с другой явой нормально не работает? Интерпретатор tcl для arm есть, и не один. java-шелл можете назвать? В tclsh работать удобно, очень удобно. Если попробуете софтину на яве запустить на linksys nslu2 узнаете, насколько ява тормозная и сколько ресурсов жрет (тикль, перл, питон там нормально работают). Попробуйте воспользоваться явой, удалив все библиотеки. Годится на что-нибудь? Думаю, нет. Вот и приходится таскать огромные наборы библиотек, и то с ними каши не сваришь - приходится искать дополнительные компоненты. В итоге установленный в системе объем кода ява становится все больше, поддержка этого безобразия заморочной, а быстродействие... лучше и не вспоминать. Посмотрите программы для ГИС, сделанные на ява (в том числе обертки для mapserver) - размером в десятки мегов! А если возьмете исходники mapserver, там есть несколько тиклевских утилит (не помню, занимают килобайты или десятки килобайт), работающих с тем же движком на С. P.P.S. Имхо, для
Re: контейнеры
Kirill A. Korinskiy пишет: [skip] AP На тикле я могу легко переключиться с создания веб-портала на разработку AP программы анкетирования на смартфонах или работу с веб-камерой под AP оффтопик. Хм. А слабо на tcl да с web camera подключаемая по usb на macosx? http://wiki.tcl.tk/5434 :) AP К примеру, набор тиклевских функций для создания файлов в формате ms AP excel 2003 xml имеет размер в несколько килобайт и не имеет никаких AP зависимостей, что позволяет его использовать с любым интерпретатором AP тикля (в том числе, с написанным на ява интерпретатором). А в java есть native код для создания xsl файлов… Тоже без зависимостей. Весит jar не много. А в xml от офиса есть огранечение на обьем. Т.е. не огранечение а достаточно большой xml он просто не откроет. Или съест столько памяти, что лучше вешаться. AP Я на его создание потратил пару дней, зато при необходимости могу очень AP быстро модифицировать (прочитать код нужной функции и ее поправить), в AP отличии от иерархии классов на ява (классы ячейка, строка, лист, рабочая AP книга), где нужно еще тратить время на понимание структуры (нужно в том AP числе изучить _все_ конструкторы или деструкторы, чтобы понять порядок AP инициализации нужных переменных). Хм. Спорно. Очень спорно. Спорно, действительно очень спорно, но что характерно, зачастую на тикле надо писать меньше кода для достижения аналогичного результата, чем на java или c++... А касательно генерации кода, но на wiki.tcl.tk достаточно примеров, кстати, некоторые тиклевые объектные системы активно используют генерацию кода, просто говоря о лиспе об этом часто упоминают, а в случае с тиклем реже. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: контейнеры
На Thu, 10 Jan 2008 18:32:15 +0300 Victor Wagner [EMAIL PROTECTED] записано: Perl, python и tcl - тоже давно уже не. Тоже байт-код, в который скрипт компилируется в момент загрузки. jit пока не прикрутили, но видимо просто потому, что и тмк быстро работает. Глядишь через год-другой в порядке какой-нимбудь дипломной работы и прикрутят. к пайтону, между прочим, прикрутили. в виде сторонней бибилиотеки. -- DamirX
Re: контейнеры
В сообщении от Wednesday 09 January 2008 23:03:58 Kirill A. Korinskiy написал(а): Alexey Pechnikov - debian-russian@lists.debian.org @ Wed, 9 Jan 2008 19:03:24 +0300: Посмотрите на alfresco. Много чего интересного можете узнать из нее. AP Спасибо, посмотрю. Хотя яву как рабочий вариант не рассматриваю, но AP документация может оказаться ценной. А что плохого в яве? Не язык красит задачу, правда. В случае java написано столько всего… Ява требует надругательства над системой, куда ставится, не сравнить с установкой интерпретатора tcl, perl, python и т.п. Огромное преимущество явы - наличие продвинутых серверов приложений сегодня уже не актуально - для всех языков они есть. Высокие требования к ресурсам, множество малосовместимых реализаций (тикль один и тот же хоть на сервере, хоть на виндовом КПК, а ява - разная). В яве не используется концепция динамической генерации кода, без чего я не представляю себе разработку (классы, виртуальные классы, родительские и производные классы - все это безобразие пытается заменить собой простую идею создания кода для нужной ситуации и выполнения его; зачем заранее писать вручную тучу кода, когда по месту можно создавать небольшие блоки кода и тут же их выполнять). А что много написано - это не показатель. На пхп написано еще больше, и с худшим качеством. Имхо, чем меньше кода решает поставленную задачу, тем качественнее он написан, а проекты на яве монстрообразны (да, системные библиотеки тоже считаю - их тоже периодически приходится проверять и править - скажем, выйдет постгрес 8.3, нужно будет оптимизировать под него функции доступа к базе данных; быстрее и надежнее сделать это самому, чем месяцами ждать появления нужной библиотеки в инете и тестировать появляющиеся их разновидности). AP Сейчас руководство пользователя подбирается по объему к сотне страниц, даже AP думать не хочется, какого объема будет техническая документация. Постараюсь к AP лету добраться, хотя за пару месяцев написать документацию может оказаться AP нереальной задачей. Правда, система модульная, но код логики в БД потребует AP разъяснений. По alfresco написана уже книга ;) По физике плазмы написано очень много книг, однако до сих пор непонятны параметры шаровой молнии. Да и книга книге рознь - если я там не найду аналитических выкладок, сочту чтение мало полезным, а кто-то захочет примеры внедрения найти (с комментариями менеджеров заказчика) и т.п. Так что наш читатель ждет нас :-) AP Может быть, появятся вопросы, с ответов на которые можно начать. Пока что я не AP задумывался о расширении области применимости проекта, нужны исходные данные AP о существующих задачах. Известно, что человек не может создать более того, AP чем способен представить себе. Часто бывает полезно пообщаться с заказчиками, у них с фантазиями очень хорошо, правда! Так я и общаюсь с _коммерческими_ заказчиками. Тут своя специфика - их интересует не модульность и проч. технические характеристики, а готовое решение для определенных задач. Что может заинтересовать _разработчиков_, я пока не в курсе.
Re: контейнеры
On Thursday 10 January 2008 16:22, Wladimir Krawtschunowsi wrote: On Thu, Jan 10, 2008 at 14:25 +0300, Alexey Pechnikov wrote: Что то вы всё в кучу смешали ... Во первых ява - это не интерпретируемый язык в полном понимании этого слова ... но при чём здесь классы ? Вам не нравиться ОО-подход вообще или что яву компилировать надо ? Ява конечно не мана небесная, но не надо аргументов типа жигули - машина хреновая, потому-что зелёная ... Да просто человек решил Artema Chuprina по количеству постов в d-r переплюнуть :) Вот и пишет, пишет, пишет... -- Макс Дмитриченко -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: контейнеры
On Thu, Jan 10, 2008 at 14:25 +0300, Alexey Pechnikov wrote: Ява требует надругательства над системой, куда ставится, не сравнить с установкой интерпретатора tcl, perl, python и т.п. Огромное преимущество явы - наличие продвинутых серверов приложений сегодня уже не актуально - для всех языков они есть. Высокие требования к ресурсам, множество малосовместимых реализаций (тикль один и тот же хоть на сервере, хоть на виндовом КПК, а ява - разная). Это вы про что ? Про какое МНОЖЕСТВО малосовместимых реализаций вы говорите - нельзя ли уточнить ? Высокие требования к ресурсам тоже довольно спроное утверждение да и никакого извращения над системой я не замечал. В яве не используется концепция динамической генерации кода, без чего я не представляю себе разработку (классы, виртуальные классы, родительские и производные классы - все это безобразие пытается заменить собой простую идею создания кода для нужной ситуации и выполнения его; зачем заранее писать вручную тучу кода, когда по месту можно создавать небольшие блоки кода и тут же их выполнять). Что то вы всё в кучу смешали ... Во первых ява - это не интерпретируемый язык в полном понимании этого слова ... но при чём здесь классы ? Вам не нравиться ОО-подход вообще или что яву компилировать надо ? Ява конечно не мана небесная, но не надо аргументов типа жигули - машина хреновая, потому-что зелёная ... С уважением Владимир signature.asc Description: Digital signature
Re: контейнеры
On 2008.01.10 at 14:22:29 +0100, Wladimir Krawtschunowsi wrote: Что то вы всё в кучу смешали ... Во первых ява - это не интерпретируемый язык в полном понимании этого слова ... но при чём Perl, python и tcl - тоже давно уже не. Тоже байт-код, в который скрипт компилируется в момент загрузки. jit пока не прикрутили, но видимо просто потому, что и тмк быстро работает. Глядишь через год-другой в порядке какой-нимбудь дипломной работы и прикрутят. здесь классы ? Вам не нравиться ОО-подход вообще или что яву компилировать надо ? Самое вредное свойство Java это то, что она позволяет РАСПРОСТОАНЯТЬ байт-код без приложения исходников. А вообще OO-подход в каждую дырку совать - действительно плохо. Это слишком тяжелая артиллерия, чтобы по воробьям стрелять. Подозреваю что основные проблемы с прожорливостью Java происходят ровно от того, что многие широко распространенные библиотеки написаны индустриальными программистами с пробелом после буквы с, которые до уровня системного архитектора со знанием OOD не доросли. А таких к OOP близко подпускать не надо. В этой методологии для того, чтобы получился хороший код, нужно 90% работы сделать на этапе дизайна. То же самое касается мультитридинга, который в Java опять же по каждому чиху. Если в языке есть присваивание, то писать мультитредед программы на нем можно позволять только настоящим виртуозам, которые все адресное пространство процесса в голове удерживают. Если присваивания нет, а есть только Message Passing как в erlang - тогда дело другое, можно позволять детишкам играться с light weight процессами. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: контейнеры
Alexey Pechnikov - debian-russian@lists.debian.org @ Thu, 10 Jan 2008 14:25:56 +0300: Позволите кусками, да? AP Ява требует надругательства над системой, куда ставится, не сравнить с AP установкой интерпретатора tcl, perl, python и т.п. Что-то я не заметил особых надругательств над системой при установки deb пакета из репозитория. Честно. AP Огромное преимущество явы - наличие продвинутых серверов приложений AP сегодня уже не актуально - для всех языков они есть. Гм. А есть application server уровня jboss для tcl? А что-то подобное gwt для python? Мне вот не известно. AP Высокие требования к ресурсам, Хм. Спорное утверждение, честно. То что программисты на яве, в большинстве своем не умеют писать, так это не проблема. Сейчас программисты вообще не особо умеют писать. Просто других слов уже нет. AP множество малосовместимых реализаций (тикль один и тот же хоть на AP сервере, хоть на виндовом КПК, а ява - разная). Угу, много. j2me, j2se, j2ee. Причем первая уже умерла т.к. на телефонах/кпк можно запускать se. AP В яве не используется концепция динамической генерации кода, без чего я AP не представляю себе разработку (классы, виртуальные классы, родительские AP и производные классы - все это безобразие пытается заменить собой простую AP идею создания кода для нужной ситуации и выполнения его; зачем заранее AP писать вручную тучу кода, когда по месту можно создавать небольшие AP блоки кода и тут же их выполнять). Хм. Да. В прямом смысле этого слова в java нет генерации кода. Но после lisp'а генерации кода нет нигде ;) На самом деле во время работы можно создавать свои классы и их динамически загружать. Просто делается это не совсем очевидно. Но делается. AP А что много написано - это не показатель. Зато это показатель популярности технологии. И чем больше написано, тем больше вероятность что то что тебе будет нужно уже написано. AP На пхп написано еще больше, и с худшим качеством. Нет, на php написано меньше чем на java. Больше чем на(о) java написано только на(о) cobol. AP Имхо, чем меньше кода решает поставленную задачу, тем качественнее он AP написан, а проекты на яве монстрообразны Не все. Далеко не все. Есть изящные проекты. Но они теряются в стае уродливых. А уродливый код я вам могу написать на любом языке программирования. Честно‑честно. AP (да, системные библиотеки тоже считаю - их тоже периодически приходится AP проверять и править - скажем, выйдет постгрес 8.3, нужно будет AP оптимизировать под него функции доступа к базе данных; быстрее и надежнее AP сделать это самому, чем месяцами ждать появления нужной библиотеки в AP инете и тестировать появляющиеся их разновидности). http://jdbc.postgresql.org/ AP Так я и общаюсь с _коммерческими_ заказчиками. Тут своя специфика - их AP интересует не модульность и проч. технические характеристики, а готовое AP решение для определенных задач. Что может заинтересовать _разработчиков_, я AP пока не в курсе.. Угу. И готовое решение появляется тем быстрее, чем больше кусков уже написано. -- .''`. Kirill A. Korinskiy [EMAIL PROTECTED] : :' : proud (maniac)? (developer|hacker) `. `'` http://catap.ru/ - +7 (916) 3-604-704 - xmpp:[EMAIL PROTECTED] `- Debian - when you have better things to do than fixing systems -- madduck pgpBRJA3Dmlgb.pgp Description: PGP signature
Re: контейнеры
В сообщении от Thursday 10 January 2008 18:38:18 Kirill A. Korinskiy написал(а): Alexey Pechnikov - debian-russian@lists.debian.org @ Thu, 10 Jan 2008 14:25:56 +0300: Позволите кусками, да? AP Ява требует надругательства над системой, куда ставится, не сравнить с AP установкой интерпретатора tcl, perl, python и т.п. Что-то я не заметил особых надругательств над системой при установки deb пакета из репозитория. Честно. Прикручивание томкатов с апачами и нужными библиотеками и классами доступа к БД (и указание их параметров) иначе назвать не могу. AP Огромное преимущество явы - наличие продвинутых серверов приложений AP сегодня уже не актуально - для всех языков они есть. Гм. А есть application server уровня jboss для tcl? А что-то подобное gwt для python? Мне вот не известно. AOL Web server. Я про него уже упоминал. Смотрите платформу OpenACS (мне и она показалась монстром, но кое-какие идеи оттуда чрезвычайно полезны). AP Высокие требования к ресурсам, Хм. Спорное утверждение, честно. То что программисты на яве, в большинстве своем не умеют писать, так это не проблема. Сейчас программисты вообще не особо умеют писать. Просто других слов уже нет. Интерпретатор тикль на КПК (etcl) вместе с огромным набором библиотек весит несколько мегабайт и представляет собой один бинарь (так же, как под линукс или виндоус или макос). После запуска библиотеки доступны в виртуальной ФС, что позволяет с ними комфортно работать (упаковка классов ява малость отличается... не в лучшую сторону). В результате закрытости базовых библиотек и для быстроты разработки при открытости этих библиотек над ними громоздятся наслоения очередных классов, что вовсе не идет на пользу. Ну и то, что разработчики используемых вами классов не умеют писать код мне тоже не кажется достоинством технологии. AP множество малосовместимых реализаций (тикль один и тот же хоть на AP сервере, хоть на виндовом КПК, а ява - разная). Угу, много. j2me, j2se, j2ee. Причем первая уже умерла т.к. на телефонах/кпк можно запускать se. На первой, которую вы назвали умершей, написана туча приложений, для которых нет исходников. Как следствие, теперь активно пишут эмуляторы. Да и на многих сотовых это единственно доступная реализация. AP В яве не используется концепция динамической генерации кода, без чего я AP не представляю себе разработку (классы, виртуальные классы, родительские AP и производные классы - все это безобразие пытается заменить собой простую AP идею создания кода для нужной ситуации и выполнения его; зачем заранее AP писать вручную тучу кода, когда по месту можно создавать небольшие AP блоки кода и тут же их выполнять). Хм. Да. В прямом смысле этого слова в java нет генерации кода. Но после lisp'а генерации кода нет нигде ;) В тикле есть. Тот же самый принцип - все есть строка, со всеми вытекающими. Скорость работы? Полно вам - написать нужную функцию на С и оформить в модуль, обращаясь потом к этой функции напрямую, много эффективнее, чем делать иерархию классов с конструкторами/деструкторами в каждом. Сменив фабрики классов на динамическую генерацию кода, обратно уже не вернусь. На самом деле во время работы можно создавать свои классы и их динамически загружать. Просто делается это не совсем очевидно. Но делается. AP А что много написано - это не показатель. Зато это показатель популярности технологии. И чем больше написано, тем больше вероятность что то что тебе будет нужно уже написано. Ну тогда странно, что j2me вы мертвой назвали. По вашему критерию me живее многих живых. AP На пхп написано еще больше, и с худшим качеством. Нет, на php написано меньше чем на java. Больше чем на(о) java написано только на(о) cobol. В мегабайтах кода точно больше написано. Потому и хуже :-) И серверных приложений больше, а для других пхп не годится. AP Имхо, чем меньше кода решает поставленную задачу, тем качественнее он AP написан, а проекты на яве монстрообразны Не все. Далеко не все. Есть изящные проекты. Но они теряются в стае уродливых. А уродливый код я вам могу написать на любом языке программирования. Честно‑честно. Изящные есть, однако и в них видна явная избыточность кода. Скажем, функции для доступа к закрытым переменным класса... в противовес общему запрету на изменение переменных в более интересных языках. AP (да, системные библиотеки тоже считаю - их тоже периодически приходится AP проверять и править - скажем, выйдет постгрес 8.3, нужно будет AP оптимизировать под него функции доступа к базе данных; быстрее и надежнее AP сделать это самому, чем месяцами ждать появления нужной библиотеки в AP инете и тестировать появляющиеся их разновидности). http://jdbc.postgresql.org/ Это низкоуровневый интерфейс. Посмотрите, к примеру, функции работы с БД из OpenACS. AP Так я и общаюсь с _коммерческими_ заказчиками. Тут своя специфика - их AP интересует не модульность и проч. технические характеристики, а готовое AP решение для
Re: контейнеры
В сообщении от Wednesday 09 January 2008 02:22:54 Michael Shigorin написал(а): On Fri, Dec 28, 2007 at 08:27:14PM +0300, Alexey Pechnikov wrote: При проектировании обеих систем я не нашел ничего подходящего, что имеет высокую производительность (поддержка не менее 50-100 одновременных пользователей на сервере целерон 2,6 ГГц с гигом оперативки и SATA жестким диском) FYI в ТЗ видно сходу три изъяна по железу: процессор, память и количество дисков. Celeron -- это не процессоры, а недоразумение. Гиг оперативки при дешёвом диске -- это экономия на кэше. А один диск -- это перегрузка и недостраховка, если вообще хоть что-то происходит и что-то надо хранить. Сейчас дешёвый сервер -- это Athlon64 X2, от пары гиг оперативки (которые стоят чуть ли не дешевле того целерона) и _два_ хотя бы винта. Где как минимум система и важные данные лежат на softRAID1. У меня рабочий сервер pentium D 2.8 GHz, 2 Gb RAM, soft RAID 1. Но для минимальных требований этого слишком много, так что тестовый сервер как указан ранее. А постгрес в свое время тестировал с прототипом БД на ARM 266 MHz+32 Mb RAM и нашел несколько узких мест. Если вы назовете проекты, в которых проведена подобная работа, буду рад расширить свой кругозор. написано на функциональном языке (тикль, лисп, erlang, etc.), Ой, тикль уже функциональный... надо же. И сваливание в кучу тоже радует. Или это описание разведённого зоопарка? Тикль уже почти функциональный, кое-что не реализовано, но мне жить не мешает. В кучу не сваливал, просто это список языков, на которых имхо резонно делать задуманное. Кстати, первые версии разрабатывались на перле, но на тикле оказалось существенно удобнее. Конечно, этот выбор в значительной мере вопрос личных предпочтений, но для нас важно то, что на тикле объем кода в три раза меньше, чем на перле и в десять раз меньше, чем на С++ (может, у кого-то наоборот? интересно будет узнать об этом). заточено на работу с PostgreSQL Вы если наслушались про ФП -- может, ещё про иерархические или фреймовые БД где наслушаетесь? ;-) Каждый день пользуюсь файловой системой ext3. Иерархическая, аж жуть. И вовсе не вижу резона хранить все данные в реляционной БД. имеет устраивающую меня модель безопасности, умеет работать с веб-камерами на виндовых ПК любой версии, с камерами на КПК и смартфонах, умеет работать с КПК и смартфонами с виндоус-хоста путем выполнения сценария, имеет написанный на функциональном языке клиент для КПК и смартфонов и проч. Хм, что-то не помню Вас в synce-devel@, ну да ладно. Виндовс-хост так виндовс-хост. synce работает только со старыми версиями винмобайл, увы (и при существующей стабильности имеет смысл только под линуксом). Так что использую ffidl, успешно работает с rapi.dll из активсинка версий 4.1, 4.2, 4.5. Знаю, что аналог ffidl есть, например, в питоне, но по ряду причин не считаю его промышленно пригодным (посмотрел синтаксис, попробовал, впечатление такое, что даже для домашних утилит использовать не стану). Далее, для документооборота решил применить аналогию из квантовой механики - проквантовать допустимые состояния документов и описать правила их изменения. Подобного проекта я также не нашел (независимо от требований выше). Почему-то все описания сводятся к рекламным заявлениям и некоторым интересным идеям, но мат. или физ. модели разработчики делать не удосуживаются. Хотя бы тот же NauDoc из близлежащего уже посмотрели? У них ограничение на несколько тысяч документов _в год_. У меня нагрузка такого порядка _в день_. Я ведь не зря говорил про железо и количество поддерживаемых пользователей. У NauDoc и других подобных систем довольно широкие возможности, но низкая эффективность. Плюс возможны проблемы с транзакционностью состояний документов - например, при выполнении одной из операций над документом должны быть разосланы сообщения заинтересованным пользователям, сохранена запись о произведенном изменении и т.п. и все это в одной транзакции. Таким образом, вся логика должна быть реализована в БД, чего я не нашел ни в одной из открытых систем (можно, конечно, делать на прикладном уровне, но поддержка в этом случае значительно усложнится). Думаю, у меня довольно типичные требования к системе документооборота, ничего сверхестественного. Позвольте вопрос - хоть одну из открытых систем документоборота вы сами стали бы использовать хотя бы для 1000 пользователей? Думаю, что нет. Итак, было принято решение делать с нуля. Это было мое личное решение, не будем его обсуждать, достаточно того, что созданная система успешно работает в нескольких десятках регионов. Ну мне лично таких доводов недостаточно -- зная недостатки наших систем, работающих в нескольких десятках регионов... и той же винды, работающей по всему миру. Ну конечно, мне бы этого тоже было недостаточно :-) Я имел в виду, что поставленная передо мной задача решена. Опен-сорс проект делать у меня нет свободных ресурсов - трудозатраты
Re: контейнеры
Alexey Pechnikov - debian-russian@lists.debian.org @ Wed, 9 Jan 2008 11:32:44 +0300: AP У них ограничение на несколько тысяч документов _в год_. У меня нагрузка AP такого порядка _в день_. Я ведь не зря говорил про железо и количество AP поддерживаемых пользователей. У NauDoc и других подобных систем довольно AP широкие возможности, но низкая эффективность. Плюс возможны проблемы с AP транзакционностью состояний документов - например, при выполнении одной из AP операций над документом должны быть разосланы сообщения заинтересованным AP пользователям, сохранена запись о произведенном изменении и т.п. и все это в AP одной транзакции. Таким образом, вся логика должна быть реализована в БД, AP чего я не нашел ни в одной из открытых систем (можно, конечно, делать на AP прикладном уровне, но поддержка в этом случае значительно усложнится). Посмотрите на alfresco. Много чего интересного можете узнать из нее. AP Думаю, у меня довольно типичные требования к системе документооборота, ничего AP сверхестественного. Позвольте вопрос - хоть одну из открытых систем AP документоборота вы сами стали бы использовать хотя бы для 1000 пользователей? AP Думаю, что нет. А я думаю что да ;) AP Думаю, что рунет-сообщество там и остановилось. Как всегда в россии, есть AP талантливые одиночки, но им есть чем заняться и без моих проектов. А вы создайте проект, откройте и покажите. Я например с радостью посмотрю на него, и быть может чем‑то помогу. -- .''`. Kirill A. Korinskiy [EMAIL PROTECTED] : :' : proud (maniac)? (developer|hacker) `. `'` http://catap.ru/ - +7 (916) 3-604-704 - xmpp:[EMAIL PROTECTED] `- Debian - when you have better things to do than fixing systems -- madduck pgpU1P8B3dLDt.pgp Description: PGP signature
Re: контейнеры
В сообщении от Wednesday 09 January 2008 17:36:44 Kirill A. Korinskiy написал(а): Alexey Pechnikov - debian-russian@lists.debian.org @ Wed, 9 Jan 2008 11:32:44 +0300: AP У них ограничение на несколько тысяч документов _в год_. У меня нагрузка AP такого порядка _в день_. Я ведь не зря говорил про железо и количество AP поддерживаемых пользователей. У NauDoc и других подобных систем довольно AP широкие возможности, но низкая эффективность. Плюс возможны проблемы с AP транзакционностью состояний документов - например, при выполнении одной из AP операций над документом должны быть разосланы сообщения заинтересованным AP пользователям, сохранена запись о произведенном изменении и т.п. и все это в AP одной транзакции. Таким образом, вся логика должна быть реализована в БД, AP чего я не нашел ни в одной из открытых систем (можно, конечно, делать на AP прикладном уровне, но поддержка в этом случае значительно усложнится). Посмотрите на alfresco. Много чего интересного можете узнать из нее. Спасибо, посмотрю. Хотя яву как рабочий вариант не рассматриваю, но документация может оказаться ценной. AP Думаю, у меня довольно типичные требования к системе документооборота, ничего AP сверхестественного. Позвольте вопрос - хоть одну из открытых систем AP документоборота вы сами стали бы использовать хотя бы для 1000 пользователей? AP Думаю, что нет. А я думаю что да ;) AP Думаю, что рунет-сообщество там и остановилось. Как всегда в россии, есть AP талантливые одиночки, но им есть чем заняться и без моих проектов. А вы создайте проект, откройте и покажите. Я например с радостью посмотрю на него, и быть может чем‑то помогу. Сейчас руководство пользователя подбирается по объему к сотне страниц, даже думать не хочется, какого объема будет техническая документация. Постараюсь к лету добраться, хотя за пару месяцев написать документацию может оказаться нереальной задачей. Правда, система модульная, но код логики в БД потребует разъяснений. Кстати, если вам интересна система документооборота, найдите часок глянуть руководство http://mobigroup.ru/files/offline/Off-line_help_3.0.0.6.pdf Может быть, появятся вопросы, с ответов на которые можно начать. Пока что я не задумывался о расширении области применимости проекта, нужны исходные данные о существующих задачах. Известно, что человек не может создать более того, чем способен представить себе.
Re: контейнеры
Alexey Pechnikov - debian-russian@lists.debian.org @ Wed, 9 Jan 2008 19:03:24 +0300: Посмотрите на alfresco. Много чего интересного можете узнать из нее. AP Спасибо, посмотрю. Хотя яву как рабочий вариант не рассматриваю, но AP документация может оказаться ценной. А что плохого в яве? Не язык красит задачу, правда. В случае java написано столько всего… AP Сейчас руководство пользователя подбирается по объему к сотне страниц, даже AP думать не хочется, какого объема будет техническая документация. Постараюсь к AP лету добраться, хотя за пару месяцев написать документацию может оказаться AP нереальной задачей. Правда, система модульная, но код логики в БД потребует AP разъяснений. По alfresco написана уже книга ;) AP Кстати, если вам интересна система документооборота, найдите часок глянуть AP руководство AP http://mobigroup.ru/files/offline/Off-line_help_3.0.0.6.pdf Завтра буду читать, спасибо. AP Может быть, появятся вопросы, с ответов на которые можно начать. Пока что я не AP задумывался о расширении области применимости проекта, нужны исходные данные AP о существующих задачах. Известно, что человек не может создать более того, AP чем способен представить себе. Часто бывает полезно пообщаться с заказчиками, у них с фантазиями очень хорошо, правда! -- .''`. Kirill A. Korinskiy [EMAIL PROTECTED] : :' : proud (maniac)? (developer|hacker) `. `'` http://catap.ru/ - +7 (916) 3-604-704 - xmpp:[EMAIL PROTECTED] `- Debian - when you have better things to do than fixing systems -- madduck pgp8codduFIsR.pgp Description: PGP signature
Re: контейнеры
On Fri, Dec 28, 2007 at 08:27:14PM +0300, Alexey Pechnikov wrote: При проектировании обеих систем я не нашел ничего подходящего, что имеет высокую производительность (поддержка не менее 50-100 одновременных пользователей на сервере целерон 2,6 ГГц с гигом оперативки и SATA жестким диском) FYI в ТЗ видно сходу три изъяна по железу: процессор, память и количество дисков. Celeron -- это не процессоры, а недоразумение. Гиг оперативки при дешёвом диске -- это экономия на кэше. А один диск -- это перегрузка и недостраховка, если вообще хоть что-то происходит и что-то надо хранить. Сейчас дешёвый сервер -- это Athlon64 X2, от пары гиг оперативки (которые стоят чуть ли не дешевле того целерона) и _два_ хотя бы винта. Где как минимум система и важные данные лежат на softRAID1. написано на функциональном языке (тикль, лисп, erlang, etc.), Ой, тикль уже функциональный... надо же. И сваливание в кучу тоже радует. Или это описание разведённого зоопарка? заточено на работу с PostgreSQL Вы если наслушались про ФП -- может, ещё про иерархические или фреймовые БД где наслушаетесь? ;-) имеет устраивающую меня модель безопасности, умеет работать с веб-камерами на виндовых ПК любой версии, с камерами на КПК и смартфонах, умеет работать с КПК и смартфонами с виндоус-хоста путем выполнения сценария, имеет написанный на функциональном языке клиент для КПК и смартфонов и проч. Хм, что-то не помню Вас в synce-devel@, ну да ладно. Виндовс-хост так виндовс-хост. Далее, для документооборота решил применить аналогию из квантовой механики - проквантовать допустимые состояния документов и описать правила их изменения. Подобного проекта я также не нашел (независимо от требований выше). Почему-то все описания сводятся к рекламным заявлениям и некоторым интересным идеям, но мат. или физ. модели разработчики делать не удосуживаются. Хотя бы тот же NauDoc из близлежащего уже посмотрели? Итак, было принято решение делать с нуля. Это было мое личное решение, не будем его обсуждать, достаточно того, что созданная система успешно работает в нескольких десятках регионов. Ну мне лично таких доводов недостаточно -- зная недостатки наших систем, работающих в нескольких десятках регионов... и той же винды, работающей по всему миру. И что по второму? Не стесняйтесь, многим нужен хороший -- особенно свободный -- документооборот. И многие оценят великолепный и продуманный код. И архитектуру. Опен-сорс проект делать у меня нет свободных ресурсов - трудозатраты огромные, а кому оно надо... Надо-надо. Трудозатраты огромные, если планировать не уметь совсем, а взаимодействовать -- совершенно. Иначе зачастую уже не полвелосипеда изобретено, а большая часть. Иначе они _могут_ быть и не огромными по сравнению с пилим всё сами. Кое-что публикую в своем блоге по постгресу, но постгресом мало кто пользуется всерьез. Разумеется. Все так, поверхностно. Ну подумаешь, подпилили в LTC, ну что вы, право. Также мало кто готов изучить новый язык/технологии (postgresql+pltcl + tcl + aolserver+sqlite). AOL-то каким боком очутился? Писать на апач+мускуль+пхп не собираюсь, а это единственные технологии, где можно организовать более-менее жизнеспособное сообщество. Ойданупрям. О великолепном речь не идет. Есть реализованные идеи, не могу сказать, насколько они хороши, но они работают, а это уже немало. Помогает смотреть по сторонам, чтоб не изобретать чужой пройденный этап... проверено. На идеал это ни с какой стороны не похоже, хотя я идеал не видел. Аналогично. Потому и открытое сообщество в рунете остановилось на уровне как настроить апач Ой, не смешите мои тапочки. в то время как во всем мире создаются и успешно развиваются прекрасные открытые проекты. И в рунете создаются да успешно развиваются. Просто места знать надо, как обычно. (ну да сейчас меня опять за рекламу погонють ;) -- WBR, Michael Shigorin [EMAIL PROTECTED] -- Linux.Kiev http://www.linux.kiev.ua/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: контейнеры
Цитировать предыдущую часть письма не буду, просто скажу спасибо, что помогли упорядочить мысли. Админу писать свой -- заведомо хуже. Даже компетентному разработчику, как правило, полезней поискать хорошую открытую базу и отталкиваться от неё, возвращая свои наработки для общей пользы, чем городить своё. Исключение мне известно одно: когда мера безопасности шоб никто не догадался такой ценой считается оправданной. В определенных областях хороших наработок не удается найти, потому и пишется свое. Можно пример области, пути поиска наработок и ссылки на написанное, которое лучше того, что существует? Несомненно, это должны быть весьма ценные проекты. Несомненно, эти проекты ценны для меня, так что стоило писать самому. Не знаю, покажутся ли они вам заслуживающими внимания. Сразу скажу, что системы заточены под заказчиков, это не коробочные версии. При проектировании обеих систем я не нашел ничего подходящего, что имеет высокую производительность (поддержка не менее 50-100 одновременных пользователей на сервере целерон 2,6 ГГц с гигом оперативки и SATA жестким диском), написано на функциональном языке (тикль, лисп, erlang, etc.), заточено на работу с PostgreSQL, имеет устраивающую меня модель безопасности, умеет работать с веб-камерами на виндовых ПК любой версии, с камерами на КПК и смартфонах, умеет работать с КПК и смартфонами с виндоус-хоста путем выполнения сценария, имеет написанный на функциональном языке клиент для КПК и смартфонов и проч. Эти требования относятся к обоим проектам сразу, но мне хотелось иметь общий движок, чтобы упростить разработку и поддержку (коллектив у нас небольшой, мы же не в америке, где стартап может получить финансирование иначе, чем продавая созданные продукты). Далее, для документооборота решил применить аналогию из квантовой механики - проквантовать допустимые состояния документов и описать правила их изменения. Подобного проекта я также не нашел (независимо от требований выше). Почему-то все описания сводятся к рекламным заявлениям и некоторым интересным идеям, но мат. или физ. модели разработчики делать не удосуживаются. Итак, было принято решение делать с нуля. Это было мое личное решение, не будем его обсуждать, достаточно того, что созданная система успешно работает в нескольких десятках регионов. И что по второму? Не стесняйтесь, многим нужен хороший -- особенно свободный -- документооборот. И многие оценят великолепный и продуманный код. И архитектуру. Опен-сорс проект делать у меня нет свободных ресурсов - трудозатраты огромные, а кому оно надо... Кое-что публикую в своем блоге по постгресу, но постгресом мало кто пользуется всерьез. Также мало кто готов изучить новый язык/технологии (postgresql+pltcl + tcl + aolserver+sqlite). Писать на апач+мускуль+пхп не собираюсь, а это единственные технологии, где можно организовать более-менее жизнеспособное сообщество. О великолепном речь не идет. Есть реализованные идеи, не могу сказать, насколько они хороши, но они работают, а это уже немало. На идеал это ни с какой стороны не похоже, хотя я идеал не видел. Опять же, проект далек от коробочной версии, которая мне и не нужна (по крайней мере, сейчас). Вот недавно обнаружил, что поддержку временных зон не продумал - как менеджеры в разных часовых поясах должны видеть отчеты по нескольким регионам в разных часовых поясах на текущий момент? И самое странное, что решение этого мелкого вопроса, одного из многих, я что-то не наблюдаю в существующих системах (может, опять плохо искал). Я уж не говорю про утилиты, решающие задачи вида ткнул на ссылку в браузере, получил превью, при подтверждении фотография с веб-камеры отправилась на сервер. Причём можно биться об заклад, что выгуглить их или эквивалентные -- дело максимум получаса при наличии элементарного интереса. Если вы можете правильно задать вопрос, то уже знаете большую часть ответа... Потому и предложил побольше читать, поменьше писать: пока пишешь толковый вопрос _и при этом уточняешь его по гуглю_, зачастую письмо выбрасывается или превращается в постановку проблемы и найденный ответ -- мож кому ещё пригодится. У всякого сообщества и его участников есть общий и персональный лимит времени на ответы на вопросы. Не стоит его искать. Да, именно так. Потому и открытое сообщество в рунете остановилось на уровне как настроить апач, в то время как во всем мире создаются и успешно развиваются прекрасные открытые проекты. Технические вопросы можно в интернет выяснить, но я еще не видел никого, кто бы разобрался, к примеру, с четырехмерным пространством Минковского с помощью гугла. Впрочем, нашелся человек, кто даже без гугла разобрался, после чего эту популяризацию назвали теорией относительности его имени :-) P.S. Сожалею, что совсем ушел от первоначальной темы, если кому-то интересны поднятые вопросы, пишите в личку, поскольку большинству это все наверняка не интересно.
