LINUX.ORG.RU

Шаттлворт: Oracle губит свои перспективы в бизнесе с открытым исходным кодом.

 , ,


0

0

Марк Шаттлворт критично высказался по поводу иска Oracle к Google и призвал одуматься:

Oracle существенно подорвали связь с открытым исходным кодом и сообществом разработчиков. Это может иметь или не иметь непосредственный результат, но это, представляет реальные проблемы для темпов внедрения ключевых технологий Oracle,таких как Java и MySQL. Разработчики будут избегать платформ, которые выглядят как патент-ловушка.

Крупные производители программного обеспечения исторически были покровителями патентов, они говорили, что патенты помогут им защитить свои прибыли, и их действующие позиции на прибыльном рынке. Microsoft, например, провел большую часть последнего десятилетия подавая иски, чтобы не пропустить Linux на рынок, а так же получить доход от его открытого портфолио. Но, если смотреть на цифры, то все очевидно, что патентные иски бьют, в основном, по крупнейшиим компаниям, производящим ПО - т.е. по тем, кто обязан поставлять новые продукты для большого числа пользователей, а также наиболее уязвимые для атак патенты.

Крупнейшие компании-разработчики ПО только выиграют от уменьшения сферы применения патентов в отрасли программного обеспечения.Может быть Oracle это поймет.

>>> Подробности

★★★★★

Проверено: isden ()
Последнее исправление: madgnu (всего исправлений: 2)
Ответ на: комментарий от darkfire

Oracle:

выручка 26.82 миллиарда

чистая прибыль 6.14 миллиардов

активы: 60 миллиардов

сотрудников: 115 000

Canonical:

выручка: 30 миллионов

чистая прибыль: только убытки

сотрудников: ~350

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

> упоротый спор 2х стен о том что мое лучше потому что оно лучше ))))

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

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

> Привеи пример обратного.

ты просто неуч, новый софт требует новую libc - и никак не станет на дистрибутив 10-ней давности

ahonimous
()

«Ай, Моська! знать она сильна, Что лает на Слона!»

Пока Red Hat работает, Novell работает, некий демагог «Косможоров» пиарится настолько же громкими, насколько и бессмесленными сотрясаниями воздуха, приманками для воинствующей школоты. Противно.

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

> У Оракла кроме купленого сана и ни кому не нужной БД нет ничего, а у Canonical третая по популярности (после винды и мака) десктопная ОС в мире.


лаба по троллингу? слабовато совсем...

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

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


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

Например:
1)устанавливает макака дебиан посмотреть что такое линукс
2)пробует установить хоть что-то
3)пугается
4)...
5)UNPROFIT!

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

>>> Поэтому в пакетах никогда не прописывают максимальную версию другого пакета

Чушь.

Привеи пример обратного.

Из того, что у меня на диске завалялось с древних времен:

XFree86-devel-4.2.1-13.73.23.i386.rpm: XFree86-libs = 4.2.1

autoconf-2.53-8.noarch.rpm: perl >= 0:5.005_3

omniORB-4.0.2-2.i386.rpm: python >= 2.0

rpm-4.0.5-1.7x.i386.rpm: popt = 1.6.5

xine-0.9.13-fr2.i386.rpm: xine-libs = 0.9.13

xmms-1.2.7-1.i386.rpm: gtk+ >= 1.2.2

Ндеюсь, хватит, а то мне надоело перечислять.

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

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

вы наверное Столлмана лютой ненавистью ненавидите? «космонавт» на данный момент хотя бы спонсирует дистрибутив + опенсорсные организации + разработки, а Столлман просто ругает всех проприетарщиков, или Столлман - это святое?

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

> ты просто неуч, новый софт требует новую libc - и никак не станет на дистрибутив 10-ней давности

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

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

> например после установки дебиана пользователя нет в судоерсах, а в убунте есть

То есть, кроме убунты и дебиана ничего не знаем? Ну тогда уж Рунту до кучи можно присобачить.

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

> например после установки дебиана пользователя нет в судоерсах, а в убунте есть, да для меня это не проблема, но убунту может поставить макака с закрытыми глазами и даже не знать о файлике /etc/sudoers.

и что происходит потом? когда эта макака, продолжая сидеть с закрытыми глазами, начинает это все юзать?

нужно ли это все таким образом - философский вопрос...

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

> Если библиотеки сохраняют совместимость по API - встанет прекрасно. А в deb-дистре не встанет потому что там прописывают максимальную версию зависимостей в каждом пакете, то есть, вводят искусственное ограничение.

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

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

> Ндеюсь, хватит, а то мне надоело перечислять.

Надеюсь, ты видишь разницу между >= и <= ?

<= - это метод Дебиана.

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

>> Ндеюсь, хватит, а то мне надоело перечислять.

Надеюсь, ты видишь разницу между >= и <= ?

Надеюсь, ты видишь там три оператора «=».

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

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

Про «работать» он не говорил :)

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

> ты можешь хоть руками все скопировать - но работать оно не будет

Еще раз. Если API не изменился (читай - имена файлов библиотек не изменились), то работать будет. И ругаться на зависимости не будет.

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

нужно ли это все таким образом - философский вопрос...


для вендекапца нужно, а макака потом поумнеет... со временем... может быть...

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

> Надеюсь, ты видишь там три оператора «=».

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

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

> Если API не изменился (читай - имена файлов библиотек не изменились)

/me пустил скупую мужскую слезу. Какой, блин, API? ABI. И он может быть разным даже у библиотек с одинаковым soname.

И ругаться на зависимости не будет.

В пакетах разных дистрибутивов зависимости могут быть (и бывают) разными.

man LSB, короче говоря.

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

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

Особенно это истинно в отношении rpm и popt. Ты хоть Maximum RPM читал?

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

> Еще раз. Если API не изменился (читай - имена файлов библиотек не изменились), то работать будет. И ругаться на зависимости не будет.

тебя носом ткнули в то, что проблема с libc, а ты рассказываешь про имена файлов

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

> И он может быть разным даже у библиотек с одинаковым soname.

Если API разный, то разными будут цифровые индексы. soname совпадает, но имена файлов разные. А в зависимости автоматом прописываются полные имена файлов.

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

> В пакетах разных дистрибутивов зависимости могут быть (и бывают) разными.

Зависимости прописываются автоматом при сборке пакета rpmbuild. Руками зависимости практически никогда в мире RPM никто не прописывает (исключение - файлы со скриптами, картинки, тексты и прочая не бинарная муйня).

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

>> И он может быть разным даже у библиотек с одинаковым soname.

Если API разный

Ты API от ABI не отличаешь походу.

в зависимости автоматом прописываются полные имена файлов.

Приехали. Ты хоть зависимости смотрел, теоретик?

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner
libc.so.6()(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libQtCore.so.4()(64bit)
libstdc++.so.6()(64bit)
libstdc++.so.6(CXXABI_1.3)(64bit)
libstdc++.so.6(GLIBCXX_3.4)(64bit)
libQtGui.so.4()(64bit)
libkdecore.so.5()(64bit)
libkdeui.so.5()(64bit)
libkio.so.5()(64bit)
libc.so.6(GLIBC_2.4)(64bit)
libm.so.6()(64bit)
libm.so.6(GLIBC_2.2.5)(64bit)
libQtDBus.so.4()(64bit)
libc.so.6(GLIBC_2.3.4)(64bit)
libpthread.so.0()(64bit)
libpthread.so.0(GLIBC_2.2.5)(64bit)
libQtXml.so.4()(64bit)
libkfile.so.4()(64bit)
libQtSql.so.4()(64bit)
libX11.so.6()(64bit)
libsolid.so.4()(64bit)
libqt4-sql-sqlite
libXss.so.1()(64bit)
libksuseinstall.so.1()(64bit)
libxine.so.1()(64bit)
kdebase4-runtime >= 4.4.4
libqt4-x11 >= 4.6.1
/sbin/ldconfig
Nxx ★★★★★
()
Ответ на: комментарий от Nxx

>> Приехали. Ты хоть зависимости смотрел, теоретик?

Естественно.


Давай имя пакета и список зависимостей.

А ты?


Да. Вот, например, зависимости lame-3.92-fr4.i386.rpm, который у меня завалялся:

ncurses >= 5.0
/sbin/ldconfig
/sbin/ldconfig
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(CompressedFileNames) <= 3.0.4-1
ld-linux.so.2
libc.so.6
libm.so.6
libncurses.so.5
libc.so.6(GCC_3.0)
libc.so.6(GLIBC_2.0)
libc.so.6(GLIBC_2.1)
libc.so.6(GLIBC_2.1.3)
libm.so.6(GLIBC_2.0)

Заметь указанное _имя пакета_ (ncurses), и покажи мне полные имена библиотек.

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

> libc.so.6(GLIBC_2.4)(64bit)

видишь эту «волшебную» надпись - GLIBC_2.4?, а теперь я сообщу тебе новость - на машине, где версия glibc ниже 2.4, ты получишь что-что вроде:

/lib/tls/libc.so.6: version `GLIBC_2.4' not found

потому все твои рассказы про новый софт на старом дистрибутиве - полный бред, будь там хоть 100% совпадение имен файлов и остальных библиотек

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

Зависимости Gnumeric:

Requires:
libc.so.6()(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libpthread.so.0()(64bit)
libglib-2.0.so.0()(64bit)
libc.so.6(GLIBC_2.4)(64bit)
libgobject-2.0.so.0()(64bit)
libc.so.6(GLIBC_2.3.4)(64bit)
libpthread.so.0(GLIBC_2.2.5)(64bit)
libgtk-x11-2.0.so.0()(64bit)
libgdk-x11-2.0.so.0()(64bit)
libgdk_pixbuf-2.0.so.0()(64bit)
libc.so.6(GLIBC_2.3)(64bit)
libpango-1.0.so.0()(64bit)
libc.so.6(GLIBC_2.7)(64bit)
libm.so.6()(64bit)
libm.so.6(GLIBC_2.2.5)(64bit)
libgthread-2.0.so.0()(64bit)
libxml2.so.2()(64bit)
libxml2.so.2(LIBXML2_2.4.30)(64bit)
libgmodule-2.0.so.0()(64bit)
libcairo.so.2()(64bit)
libpangocairo-1.0.so.0()(64bit)
libglade-2.0.so.0()(64bit)
libz.so.1()(64bit)
libatk-1.0.so.0()(64bit)
/usr/bin/perl
libgoffice-0.8.so.8()(64bit)
libgsf-1.so.114()(64bit)
libperl.so()(64bit)
libpsiconv.so.6()(64bit)
libspreadsheet-1.10.8.so()(64bit)
gnumeric-lang = 1.10.8
/bin/sh
/usr/bin/gconftool-2
coreutils
diffutils

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

> потому все твои рассказы про новый софт на старом дистрибутиве - полный бред, будь там хоть 100% совпадение имен файлов и остальных библиотек

Еще раз. Речь идет о случае, если API не менялось. Если менялось, то естественно, будет ругаться на зависимости. Но искусственных ограничений нет.

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

> Ты имена файлов библиотек видишь?

Я не вижу имен, которые можно было бы назвать «полными». Кстати, имен файлов я тоже не вижу - я вижу soname'ы (разве что ты станешь утверждать, что libc.so.6(GLIBC_2.1.3) - это такое имя файла).

Как насчет примера Debian-пакета с «<=»?

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

Вы просто «не умеете» хранить свои конфиги. Я тоже не умел, теперь научился и кучу времени экономлю.

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

Разве эти цифры оправдывают ублюдское поведение Оракла? Таки какие бы не были там у Марка цели, в данном случае, он прав.

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

> Как насчет примера Debian-пакета с «<=»?

Ну можно <= и не прописывать, но тогда при обновлении библиотеки при изменении API рискуешь получить абсолютно нестабильную не работоспособную систему (при этом с зависимостями будет «все в порядке»). Поэтому в мире Дебиана софт надо ставить только на тот релиз системы, для которого он скомпилирован.

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

> Еще раз. Речь идет о случае, если API не менялось

facepalm.xcf, нет такого случая, в 10-летней давности дистрибутиве версия glibc максимум 2.0/2.1, т.к. это самые последние на тот момент( а самые последние обычно не используют - по понятным причинам ), ___практически любой___ современный софт требует версию glibc выше, даже в red hat и debian, где стараются ту самую glibc без надобности не трогать, чтоб как раз не ломать совместимость

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

> Разве эти цифры оправдывают ублюдское поведение Оракла? Таки какие бы не были там у Марка цели, в данном случае, он прав.

Все верно, но до Марка это уже тысячи раз говорили (даже Микрософт уже заявила, что согласна с тем, что софтверные патенты мешают инновациям). Он просто сказал общеизвестную истину.

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

> facepalm.xcf, нет такого случая, в 10-летней давности дистрибутиве версия glibc максимум 2.0/2.1, т.к. это самые последние на тот момент( а самые последние обычно не используют - по понятным причинам ), ___практически любой___ современный софт требует версию glibc выше, даже в red hat и debian, где стараются ту самую glibc без надобности не трогать, чтоб как раз не ломать совместимость

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

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

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

> Ну можно <= и не прописывать

Пример. Дай мне пример.

но тогда при обновлении библиотеки при изменении API рискуешь получить абсолютно нестабильную не работоспособную систему

Похоже, ты вообще ничего не знаешь о Debian. Там версия API включается в имя пакета библиотеки: libc6, например (ага, Epoch тоже есть).

Поэтому в мире Дебиана софт надо ставить только на тот релиз системы, для которого он скомпилирован.

То есть ни теоретического, ни практического знакомства с Debian у тебя нет. А сколько апломба...

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

> Там версия API включается в имя библиотеки

Да что ты говоришь.

libgtk2.0 - любая gtk, что 2.20, что 2.30

libqt4 - любая qt4. Что 4.0, что 4.5.

Скажешь, API не менялся?

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

А kdelibs вообще что от КДЕ3, что от КДЕ4 все равно kdelibs. Если система с КДЕ3 увидит репозиторий с КДЕ4, она полезет оттуда обновлять Kdelibs и будет системе кирдык.

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

Этот господин, если прочитает в треде более двух раз слово Debian, то сразу начинает продвигать rpm и нести густую и обильную ахинею про deb.
Я уже даже не обращаю внимание на все это.
Что-то доказанное и разжованное ему одном месте, спутся некоторое время, можно уже с нуля доказывать (и все по новой) уже другом месте.))

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

>У слаквари тоже есть пакетный менеджер или это к чему?
Нифигасебе как всё меняется!
Давно?
Да, если вы о том, что там можно удалить программу, то это не совсем менеджер пакетов.

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

>Вы просто «не умеете» хранить свои конфиги. Я тоже не умел, теперь научился
??
Зачем?

и кучу времени экономлю.

И как?
Я тоже хочу время экономить!

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

> На rpm систему ничего не мешает установить сразу обе версии

опять видно теоретика :) кроме примитива( поставить еще libgcc нужной версии + зависимости ), тебя ждет то, что будут подгружены две libc разных версий( благодаря системным библиотекам, которые ес-но не видят твою новую libc ) - и ес-но будет креш даже на банальном malloc/free

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