Линукс изменил многое, возможно в этот раз СКО проиграет и сдохнет (с большой буквы З).

Nea, ne Zdoxnit -- slishkom mnogo vliyatel'nblx peoplez vovlechenbl v razborky.

Чтение этой статьи это просто радость какая-то. В кратком пересказе: SCO (в прошлом Caldera) практически принадлежит Canopy Group. Это же группе принадлежали компании Lineo (делали риал-тайм линукс) и Troll Tech (делает QT) :) Это цирк какой-то...

Продолжая читать статью: IBM владеет 46% акции Canopy Group. Что там будет в следующем абзацее :)))

Canopy имеет 46% акций SCO.

to anonymous (*) (2003-06-19 21:12:41.554438)
>Продолжая читать статью: IBM владеет 46% акции Canopy Group.
>Что там будет в следующем абзацее :)))
это не IBM владеет 46% акций Canopy Group, это Canopy Group владеет 46% акций SCO, у Вас с английским не очень :)

2prev. anonymous:

"The IBM lawsuit could bring a windfall to Canopy, which owns 46% of SCO" переводится как "Тяжба с IBM может принести плоды Canopy, которая владеет 46% акций SCO. То есть IBM _не_ со-владелец SCO - иначе бы получился полный бред. А вообще статья очень крутая. Мне еще понравилось про компанию, бывшую SCO (ныне Tarantella, а теперяшняя SCO это бывшая Caldera) - изначальную владелицу (после AT&T) кода Unix и производителя SCO Unix. Они продали Calder'e код Unix, купили, видимо из полученных денег, акций Calder'ы, потом продали и эти акции (по дешевке) и свой brend, в результате потеряв 36 мегабаксов. Да, вот как в развитых странах делается бизнес :) Теперь понятно, почему крупные компании держат армии юристов и обкладываются патентами - иначе вмиг разорвут и растащат по частям. Надеюсь, IBM не оплошает.

>>>Чтение этой статьи это просто радость какая-то.

Точно, особенно в качестве иллюстрации по теме "Практика информационных войн".

Статья про историю "торговли лошадьми", то есть акциями SCO, но тогда зачем в ней совершенно отдельно от темы несколько раз пинается linux-комьюнити и эти пинки стилистически выделены, а один пассаж дословно повторён дважды и второй раз последним абзацем. Видать, чтоб лучше FUD читателем донести и нужные ассоциации закрепить!

В отношении комьюнини употребляются весьма несолидные эпитеты - Linux-loving crunchies, religious folks, причем последний они получают за именно то, что уверены в своей правоте и ведут себя поэтому спокойно :))

Собственно про содержание конфликта в статье ничего и нет, зато в абстрактый "Linux" грязь мечут прицельно. Ни слова, что кроме угроз к _IBM_ SCO дальше пока не продвинулась, где уж ей до комьюнити дотянуться. И ессно молчок про ультиматум "пятница, 13", который для скотов завершился очередным пшиком...

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

"И ессно молчок про ультиматум "пятница, 13", который для скотов завершился очередным пшиком..."

А вот тут вы очень сильно ошибаетесь.:-) Формально лицензию отозвали, IBM на это, естественно, чхать. Пока, чхать. А вот покупателям? Недаром San засуетилась, предлагая свои решения взамен IBM-их.

>>>А вот тут вы очень сильно ошибаетесь.:-) Формально лицензию отозвали,

IBM официально прекратила поставки Linux за две недели до ультиматума. Но после отзыва теперь получается что удар-то не по Linux, а по AIX нанесён. Но FUD по прежнему в сторону линукса льётся и льётся. А люди, не обращающие на него внимания характеризуются религиозными фанатиками... Замечательно, не правда ли?!

Формально лицензию не отозвали. Ее можно "отозвать" только по суду, если вообще можно, IBM считает что нельзя. Вот суд и решит.

А на практике отозвать лицензию у IBM нельзя. Это тоже самое что начать судиться с электрническими кампаниями и потребовать чтобы те немедленно прекратили давать электричество. Отрубить рубитльник всей америке нельзя ни по какому суду и по какой лицензии. Так же и остановить компьютинг а IBM это и есть вычислительная мощь америки просто нельзя ни по какому суду. Поэтому IBM и плевало на скотов.

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

Логика всегда была слабым местом борзописцев. :)

> Формально лицензию не отозвали. Ее можно "отозвать" только по суду, если вообще можно, IBM считает что нельзя. Вот суд и решит.

Именно вормально лицензию отозвали. Теперь собственно суд и будет решать имела ли право SCO отзывать лицензию. И если суд решит, что да - имела, тогда IBM будет обязана заплатить n-ную сумму за наршуение контракта и использование не лицензионного ПО (начиная с даты прекращения лицензии, т.е. 13 июня), со штрафными санкциями за каждую копии используемую их покупателями... В общем денег куча.

Дааа. SCO всех так зацепила.

Вон что Фёдор пишет в Nmap 3.28 release announce:

...
o SCO operating systems are no longer supported due to their recent
  (and absurd) attacks against Linux and IBM.  Bug reports relating to
  UnixWare will be ignored, or possibly even laughed at derisively.
  Note that I have no reason to believe anyone has ever used Nmap on
  SCO systems.  Unixware and OpenServer suck.
...

Во как :-))))

Интересно, если то же самое сделают остальные (большинство) гнушников, 
SCO таки само отвалится?

Фёдор молодца. Надеюсь, его пример станет заразительным. Всем искать дыры в SCO-шных продуктах и писать сплойты, юзать их и не выкладывать на всеобщее обозрение.

Чтобы отозвать лицензию у IBM, СТОтам нужно доказать, что IBM ее нарушила => показать код из UNIX в Linux...
А поскольку IBM подала встречный иск, думаю загнутся.
Пицес, 3 миллиарда - это типа чем борзее, тем лучше, что ли?

а когда суд то будет? дата?

:>Unixware and OpenServer suck...

Хехехехе - вот тебе и проффи юникс 8) Он мог бы сюда смело и соплярис добавить - хотя в свете последних телодвижений сана - чую за этим дело не станет 8)

Мда, заварили скоты кашу - как бы не подавиться ....

В сКО сидят стукачки (насчет нарушений экспортных ограничений). В америке так все поступают?

-- slishkom mnogo vliyatel'nblx peoplez vovlechenbl v razborky --

Да скоты всю жизнь торчали на оВракле - и тот их нахер послал. Агония - сучат конечностями.

Братва! Есть конструктивный вопрос: хочется мигрировать с СКО/Оракл7 на что нить более правильное (Linux/BSD :-)))). Надо чтоб там оракл_формс3.0 работали. Может кто подскажет? А то юниксварь затрахала ваще!!! После линуха это мучения сплошные.

Хз - в глубокой древности, каждый уважающий себя дистрибьютор линухов поставлял библиотеки совместимости со скотиной, соплярисом, бздей e.t.c.

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

To sabonez:

Братан, переезжай на Solaris/SPARC, а о пингвиниксе и думать забудь. Оракла его только из маркетинговых соображений толкает. А так для DBMS линьюкс весьма кривая система. Ни тредов прилично реализованых, AIO существует только в виде кривых патчей типа как в RH Advansed Server. А это значит, что с raw partiшнами один геморой будет. Если уж и юзать юникс для серьёзных задач, так использовать что нить приличное типа Solaris, AIX, HP-UX и на приличном железе. А на x86 SCO UnixWare куда приличнее для базюк будет, чем пингвиникс.

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

Чушь порете, батенька

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

To: anonymous (*) (2003-06-20 11:20:25.832011)

Without load and on small servers with small (<10Gb) databases maybe

Да ну ? 8)

На 3,7Tb база ~1200 активных коннетов - это нагрузка или нет ? Пашет как ни странно 8)

To anonymous (*) (2003-06-20 11:30:25.457798)

Pizdezh

А вот, кстати, интересная информация. Только что пришло письмо
из списка рассылки The Unix Heritage Society.

Цитирую дословно.

----
[TUHS] SCO removed the anchient UNIX offer web page
Date: Thu, 19 Jun 2003 16:31:06 -0700 (PDT)
From: Kenneth Stailey <kstailey@yahoo.com>
To: tuhs@tuhs.org

http://www.sco.com/offers/ancient_unix.html

http://web.archive.org/web/*/http://www.sco.com/offers/ancient_unix.html

----

А с текстом лицензии можно ознакомится здесь:

http://public.planetmirror.com/pub/ancient-unix/

Сам еще не знаю, что бы это значило...

2anonymous (*) (2003-06-20 10:22:11.977985)
>Братан, переезжай на Solaris/SPARC, а о пингвиниксе и думать забудь. Оракла его только из маркетинговых соображений толкает.
Ага, и железо заодно прикупи, Oracle+solaris/i86 работает медленнее Oracle+Linux/i86.
>А так для DBMS линьюкс весьма кривая система.
Примеры в студию, Real Application Cluster не предлагать :-)
>Ни тредов прилично реализованых, AIO существует только в виде кривых патчей типа
Кривизну патчей в студию :-)
>как в RH Advansed Server. А это значит, что с raw partiшнами один геморой будет.
Это ничего не значит, raw partition для базы ... вопрос спорный, не раз обсуждавшийся в конференциях по Ораклу, каждый dbadmin сам решает, юзать их или нет, свобода выбора :-) В любом случае рассматривается конкретное РЕШЕНИЕ, а не операционка :-)
>Если уж и юзать юникс для серьёзных задач, так использовать что нить приличное типа Solaris, AIX, HP-UX и на приличном железе.
Серьезность задачи зависит от задачи(сорри за тавтологию), понятие весьма растяжимое, как и стоимость решения.
>А на x86 SCO UnixWare куда приличнее для базюк будет, чем пингвиникс.
Приличнее - это из области этики, подробности пожалуйста, с примерами ...
>Не надо, браток, к религиозным войнам присоединяться. Поверь, не к чему тебе это. А скотину жалко. Хорошая система, не то что линьюкс.
Сказал анонимус, ветеран HolyWar, забыв добавить IMHO :-)
З.Ы. SPARC Solaris/Oracle хорошее решение, надежное, дорогое, возражений не имею, а на i86 IMHO, Linux+Oracle вполне хорошо себя чувствует, убить такую связку может только кривость железа/рук админа :-)

Sun вышел на тропу войны

Претензии SCO к IBM касаются поддержки SMP (как и ожидалось) и

поддержки NUMA

http://vnunet.com/News/1141726

2anonymous (*) (2003-06-20 11:24:32.498673)
>Without load and on small servers with small (<10Gb) databases maybe
Connected to:
Oracle9i Enterprise Edition Release 9.2.0.3.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.3.0 - Production

SQL> show sga

Total System Global Area 2719028840 bytes
Fixed Size 452200 bytes
Variable Size 1040187392 bytes
Database Buffers 1677721600 bytes
Redo Buffers 667648 bytes
SQL> !du -sh /u01/data/BASED
49G /u01/data/BASED

SQL> !cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel(R) Xeon(TM) CPU 2.40GHz
stepping : 7
cpu MHz : 2400.023
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
bogomips : 4784.12

processor : 1
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel(R) Xeon(TM) CPU 2.40GHz
stepping : 7
cpu MHz : 2400.023
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
bogomips : 4797.23

processor : 2
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel(R) Xeon(TM) CPU 2.40GHz
stepping : 7
cpu MHz : 2400.023
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
bogomips : 4784.12

processor : 3
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel(R) Xeon(TM) CPU 2.40GHz
stepping : 7
cpu MHz : 2400.023
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
bogomips : 4784.12


или
Oracle8i Enterprise Edition Release 8.1.7.4.0 - Production
With the Partitioning option
JServer Release 8.1.7.4.0 - Production

SQL> show sga

Total System Global Area 1019326624 bytes
Fixed Size 73888 bytes
Variable Size 657747968 bytes
Database Buffers 360448000 bytes
Redo Buffers 1056768 bytes
SQL> !du -sh /u01/data/BASE/ /u01/data1/BASE/
56G /u01/data/BASE
20G /u01/data1/BASE

SQL> !cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 8
model name : Pentium III (Coppermine)
stepping : 3
cpu MHz : 863.974
cache size : 256 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse
bogomips : 1723.59

processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 8
model name : Pentium III (Coppermine)
stepping : 6
cpu MHz : 863.974
cache size : 256 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse
bogomips : 1723.59

Так что не надо ля-ля, главное - голова на плечах и железо не с барахолки :-)
А насчет нагрузки - специально тестировали до 25-30 la и сервер еще раздает коннекты, правда медленно, и загрузка по процессам распределяется практически равномерно (но это зависит от настроек базы).

To: sco-killer

49G /u01/data/BASED - not a terabytes

15-25 la on 4 cpu? Slightly too many:) Is this usual workload? Its time to upgrade! SF 480 or 3800 become cheaper than intel's shit with these requirements

>Братва! Есть конструктивный вопрос: хочется мигрировать с СКО/Оракл7 на >что нить более правильное (Linux/BSD :-)))). Надо чтоб там >оракл_формс3.0 работали. Может кто подскажет? А то юниксварь затрахала >ваще!!! После линуха это мучения сплошные.

А сам Oracle не прикрыл поддержку своих Forms? Спрашиваю, ибо знаю бывших пользователей, участвующих в проекте http:://www.gnuenterprise.org и мигрирующих и с oracle-forms тоже.

2anonymous (*) (2003-06-20 12:30:28.395709)
>49G /u01/data/BASED - not a terabytes
А кто про терабайты говорил? я привел реальные данные со своих серверов. Ну нету у меня терабайтных массивов и соответствующих баз, а у кого есть? Можно примеры с больших юниксов?
>15-25 la on 4 cpu?
Нет, на 4-х cpu удалось добиться только 7-8 la. 25-50 la было на 1-проц машинке, когда выбор стоял, c SCO OpenServer переходить на UnixWare или Linux, выбрали Linux :-).

2sco-killer - не спорь с воинствующими фанатами сана - они хуже виндовзятников - хоть кол на голове теши - будет ходить и орать: сан - лучше .... забей 8)

Фанаты это всегда хреново. А фанаты линукса уж куда зло%бучей фанатов сана или мокросовта. Но хуже всех вообще - это вообще фанаты Спартака;)

2anonymous (*) (2003-06-20 13:05:45.108034)
да не спорю, Sun SPARC - надежное и дорогое решение, каждой мухе - своя котлета, тем более, что на моем рабочем столе стоит 2 машины: Sun Blade 100 и нонейм Интел, и на каждой - Linux :-)

Slashdotter lspd pointed this out in a recent thread, thereby
demonstrating that slashdot isn't completely useless.

Compare:
/usr/src/linux/arch/ia64/sn/io/ate_utils.c in Linux
to:
unix/malloc.c in UNIX 6th Edition (page 25 of the Lions code,
lines 2522--2589)

atefree() is very obviously based on Unix's mfree(), and atealloc() on
malloc(). atefree()/mfree() even have the *same leading comment*. Of
course, there are some changes, but the overall structure and many of
the details remain.

The copyright notice on ate_utils.c says:

* This file is subject to the terms and conditions of the GNU General Public
* License. See the file "COPYING" in the main directory of this archive
* for more details.
*
* Copyright (C) 1992 - 1997, 2000-2002 Silicon Graphics, Inc. All rights reserved.


This code is obviously not a trade secret, since it has been published
in the 1996 version of the Lions book. However, it is copyrighted,
and the book's (C) notice says:
. . . SCO [i.e. the Santa Cruz Operation, not The SCO Group] has
granted a license to publish solely for the purpose of creating an
educational work. SCO grants no license for any other use of this
material . . . .

<offtopic>

Тут промелькнуло AIO. Проверьте, у кого-нибудь это работает на РХ9 ?
--
#include <stdio.h>
#include <signal.h>
#include <errno.h>
#include <unistd.h>
#include <aio.h>

#define SIZE (64 * 1024 * 1024)

struct aiocb output;
char *buffer;

void aio_finished(int sig)
{
	printf("AIO finished, status %d\n", aio_error(&output));
	free(buffer);
}

int main(int argc, char *argv[])
{
	char *filename;
	int n;

	setbuf(stdout, NULL);

	buffer = (char *)malloc (SIZE);
	if (!buffer) {
		printf("No memory :-(\n");
		exit(ENOMEM);
	}
	for (n = 0; n < SIZE; buffer[n] = n % 1024, n++);

	filename = ((argc == 2) ? argv[1] : "aio.test");
       	signal(SIGUSR1, aio_finished);

	output.aio_fildes = open(filename, O_WRONLY | O_CREAT | O_TRUNC, 0644);
	if (output.aio_fildes < 0) {
		printf("Can't open %s (%s)\n", filename, strerror(errno));
		exit(errno);
	}
	output.aio_offset = 0;
	output.aio_buf = buffer;
	output.aio_nbytes = SIZE;
	output.aio_sigevent.sigev_notify = SIGEV_SIGNAL;
	output.aio_sigevent.sigev_signo = SIGUSR1;
	
	if(aio_write(&output) < 0) {
		printf("Write failed (%s)\n", strerror(errno));
		exit(errno);
	}
	while (1) {
		printf("AIO test end, wait for I/O termination (%d)...\n", aio_error(&output));
		usleep(10000);
	}
	return 0;
}
--
Насколько я понимаю, после получения SIGUSR1 мы должны навечно
застрять в последнем цикле. У меня почему-то падает:
...
AIO test end, wait for I/O termination (115)...
AIO test end, wait for I/O termination (115)...
AIO test end, wait for I/O termination (0)...
AIO test end, wait for I/O termination (0)...
AIO test end, wait for I/O termination (0)...
AIO finished, status 0
AIO test end, wait for I/O termination (0)...
...
Segmentation fault (core dumped)

Падает где-то в libpthread:

(gdb) bt
#0  0x00000000 in ?? ()
#1  0x40041d19 in __pthread_cleanup_upto () from /lib/tls/libpthread.so.0
#2  0x42027301 in _longjmp_unwind () from /lib/tls/libc.so.6
#3  0x4202726c in siglongjmp () from /lib/tls/libc.so.6
#4  0x4003edea in pthread_exit () from /lib/tls/libpthread.so.0
#5  0x420eb206 in pthread_exit () from /lib/tls/libc.so.6
#6  0x4002a940 in handle_fildes_io () from /lib/librt.so.1
#7  0x4003e2b6 in start_thread () from /lib/tls/libpthread.so.0
(gdb) 

</offtopic>

Как и ожидалось скоты охренели

Дело не в SMP или NUMA, а в уверенности SCO, что все чего коснулась божья благодать SCO и, что было названо святым словом UNIX теперь их на веки веков. То, что код писали люди из IBM они и не отрицают Как и не утверждают, что они его купили. Понятно, что IBM уперлось, так можно лапу на весь их код наложить...

<offtopic_again>
Насчет AIO - после update kernel (на 2.4.20-18.9) и glibc (на 2.3.2-27.9) все ок. Так что всем рекомендую :-)
</offtopic_again>

2green (*) (2003-06-20 14:41:41.185317): И что?
Во-первых, кодом из arch/ia64 пользуются дай Бог с тысячу человек во всём мире... ;-)
Далее, в файле явно написано, откуда уши: из SGI. С чего СКОты на IBM-то наехали?
В-третьих, СКОты орали о "тысячах строк ИДЕНТИЧНОГО кода", а тут - 67 строчек.
В-четвертых, если ДЕЙСТВИТЕЛЬНО посмотреть в код, то ничего такого уж экстраординарного там нету. А потому, вполне естественно, что структура файла и комментарии будут аналогичными вплоть до 100% совпадения.

В общем, на мой взгляд, если у СКОтов нет ничего более существенного, чем этот файл, то надеяться им абсолютно не на что.

Ты считаешь этот кусок неважным? А вот адвокаты могут думать по другому.

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

2sabonez

В городе Самара в институте "Радио" успешно используется Oracle с Linux. Тамошний админ бухгалтерию на этом сделал с WEB-интерфейсом.

2green (*) (2003-06-20 16:51:49.42179): В твоём постинге сказано, что совпадение, всё же, не 100%. В этом случае, на месте IBM (и SGI) я бы гнул линию именно в направлении того, что тривиальный код реализуется тривиально... И что различия вызваны как раз-таки естественной субъективной реализацией. Т. е., свести дело к той же теме, что и с торговыми марками: Microsoft до сих пор не смогла доказать, что "Windows" и "Lindows" - это одинаковые торговвые марки.
Да и, в любом случае, общий объём продаж _РЕШЕНИЙ_ (даже не ОС, а полностью готового решения) на базе IA64 во всём мире не дотягивает до $1 млрд. => любые вые*оны СКОтов в стиле "мы потеряли $3 млрд." попросту БРЕД.
Более того, надо отметить фразочку "granted a license to publish solely for the purpose of creating an educational work". На мой взгляд, это означает следующее: "Учитесь, ребятки, как надо писать код!". Вот и естественно, что наученные на конкретных примерах программеры и реализовали нечто похожее: так и должно быть...
Теперь вот еще момент: предположим, ты владеешь правами на софтинку
void main(void){
printf("Hello world!");
}

А я написал софтинку такую:
void main(void){
printf("HI world!")
}

Вопрос: имеешь ли ты право предъявить ко мне какие-то патентные требования?

А полное совпадние комментариев как ты об'яснишь?

(другое дело что этот код вполне мог быть частью K&R книжки по программированию да си, как нам подсказывают в lkml)

Вопрос: имеешь ли ты право предъявить ко мне какие-то патентные требования?

Конечно! Гони две банки пива и все будет ОК.
Именно этих двух банок пива и хотят СКОты.

http://www.linuxjournal.com/article.php?sid=6956