форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+/–
Сообщение от opennews (??) on 25-Авг-14, 12:10
Большинство разработчиков свободной операционной системы Haiku, продолжающей развитие идей BeOS, не приняли предложение (http://www.freelists.org/post/haiku-development/Whats-the-st...) по миграции операционной системы на ядро Linux. Обсуждение возможности перехода на ядро Linux было инициировано после того, как один из разработчиков подготовил прототип порта Haiku, в котором специфичные службы  и слой BeOS API, в том числе API для разработки приложений и сетевого взаимодействия, были реализованы поверх ядра Linux. По мнению разработчика, развитие собственного ядра является монументальной ошибкой Haiku, в условиях небольшой команды разработчиков не позволяющей угнаться за эволюционированием оборудования и ростом требований к безопасности. Использование ядра Linux помогло бы решить проблемы с поддержкой оборудования и сосредоточиться на развитии технологий BeOS. С другой стороны, без собственного ядра Haiku потеряет самобытность и превратиться в зависящую от сторонней разработки надстройку. В итоге, в качестве наиболее разумного компромисса называется продолжение развития проекта использования технологий Haiku поверх ядра Linux в отдельном репозитории, к которому могут присоединиться все заинтересованные разработчики, без изменения текущей организации Haiku в основном проекте. URL: http://www.osnews.com/story/27907/Haiku_debates_kernel_switc... Новость: http://www.opennet.dev/opennews/art.shtml?num=40449
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+23 +/–
Сообщение от Аноним (??) on 25-Авг-14, 12:10
Хм, и где же там "в штыки"? Адекватыне ответы в приветливой манере, с уважением.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	12. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+1 +/–
	Сообщение от annualslayer (ok) on 25-Авг-14, 14:11
	Адекватными ответами в приветливой манере, с уважением дали понять, что им не нужно.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	47. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+4 +/–
	Сообщение от Аноним (??) on 26-Авг-14, 00:37
	А что вы ожидали от горстки психопатов, которые в 2014 году с gcc 2.95 возятся? Приступов здраворо смысла чтоли? Они с самого начала нацелились ударно повкалывать на мусорный бак.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	112. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+/–
	Сообщение от Аноним (??) on 27-Авг-14, 06:46
	ну да, запишем также к психопатам и разработчиков dosbox, freedos и множество других
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	118. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+/–
	Сообщение от Алексей Морозов (ok) on 27-Авг-14, 08:42
	У dosbox'а & Co возможно некоторое количество "real world" заказчиков, т.к. 286 для имбеда в "странах третьего мира" вполне годится (и у многих есть технологии производства). Куда девать beos в нашем непростом мире...
	Ответить | Правка | ^ к родителю #112 | Наверх | Cообщить модератору

	125. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+/–
	Сообщение от Аноним (??) on 27-Авг-14, 11:00
	> есть технологии производства). Куда девать beos в нашем непростом мире... Скорее, применяется для всяких там древних касс и прочего, которые выбросить жалко, т.к. работает вроде и дело делает. И для всяких там прошивалок BIOS/прошивок, etc. А смысла производить 80286 на данный момент просто нет. Кому надо мелкое, маложручее и простое - могут ARM взять, так что даже нонеймовые китайцы его шлепают по цене песка под ногами. А если жаба давит лицензировать - ну ок, взять OpenRISC какой-нибудь...
	Ответить | Правка | ^ к родителю #118 | Наверх | Cообщить модератору

	124. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+/–
	Сообщение от Аноним (??) on 27-Авг-14, 10:57
	У досбокса и фридоса есть некие реально практикующиеся применения. А сабж просто онaнизм в чистейшем, эталонном виде. Потому что в реальном мире найти хоть что-то завязанное на окаменелую проприетарь из не взлетевшей операционки - невозможно даже под микроскопом.
	Ответить | Правка | ^ к родителю #112 | Наверх | Cообщить модератору

3. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+8 +/–
Сообщение от AlexYeCu_not_logged on 25-Авг-14, 12:21
А что за чудо-технологии есть в Haiku? Такие, что даже без родного ядра кому-то нужны?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	6. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+7 +/–
	Сообщение от Аноним (??) on 25-Авг-14, 12:37
	Программы выполняются не как отдельные процессы, а как потоки. Многопоточная обработка всего и вся.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	24. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+3 +/–
	Сообщение от Я (??) on 25-Авг-14, 15:33
	это уникальная фича?
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	25. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+3 +/–
	Сообщение от Аноним (??) on 25-Авг-14, 15:35
	> Программы выполняются не как отдельные процессы, а как потоки. Господи, что бы это могло значить?
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	119. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+/–
	Сообщение от Алексей Морозов (ok) on 27-Авг-14, 08:45
	>> Программы выполняются не как отдельные процессы, а как потоки. > Господи, что бы это могло значить? Я думаю, кооперативная многозадачность :) Здравствуй, обязательный Thread.yield()! :)
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	27. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+/–
	Сообщение от Xasd (ok) on 25-Авг-14, 16:04
	> Программы выполняются не как отдельные процессы, а как потоки. Многопоточная обработка всего и вся. а чем Потоки (Нити, Threads) отличаются от Процессов --- с точки зрения ядра? а-то ведь так можно и про Linux-kernel сказать что с точки зрения ядра там все программы выполняются как Нити :-) ядро Linux-kernel ведь не отличает Нити от Процессов.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	34. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	–4 +/–
	Сообщение от pavlinux (ok) on 25-Авг-14, 17:18
	Нету нитей, нету процессов, есть таски :)
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	40. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+/–
	Сообщение от ананим on 25-Авг-14, 19:33
	Нет. Есть контекст выполнения! :D
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	44. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	–1 +/–
	Сообщение от pavlinux (ok) on 25-Авг-14, 22:18
	Всё бренно, кроме потока электронов в проводниках.
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	48. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+/–
	Сообщение от Аноним (??) on 26-Авг-14, 00:38
	> Нету нитей, нету процессов, есть таски :) Нету нитей, нету процессов. Все суть LWP, просто у некоторых LWP один, а у некоторых - несколько :).
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	73. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+/–
	Сообщение от Аноним (??) on 26-Авг-14, 06:02
	Не отличало. С некоторых пор разница есть. Единицей планирования является поток, есть различия при порождении процесса/потока.
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	55. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+/–
	Сообщение от metallica (ok) on 26-Авг-14, 01:09
	> Программы выполняются не как отдельные процессы, а как потоки. Многопоточная обработка > всего и вся. Как в solaris. Там единицей планирования является сущность kernel thread, некоторые из которых предназначены, выставляя регистры в значения, соответствующее определённым контекстам, тратить свои кванты времени на исполнение кода из  memory image загруженных программ ползовательского уровня. Причём код определённого иммаджа, могут в разное время исполнять разные kernel threads, не обязательно один и тот же. Так что можно с уверенностью назвать сoляру полностью тредовой. В хайке велосипед пилят, короче.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	86. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+/–
	Сообщение от ананим on 26-Авг-14, 16:53
	Ну а в линухе любой процесс или поток реализован через вызов clone2, у которого очень приличный список параметров настройки контекста выполнения — от firk'a (который через него же реализован) до легковесных процессов и (легковесных же) потоков. Ну нет больше разницы между потоком и процессом как таковой. Есть только разница в объёме информации сохраняемого/восстанавливаемого контекста выполнения при переключении задач после появления коу и ммэп.
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	94. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+/–
	Сообщение от metallica (ok) on 26-Авг-14, 17:52
	> Ну а в линухе любой процесс или поток реализован через вызов clone2, > у которого очень приличный список параметров настройки контекста выполнения — от > firk'a (который через него же реализован) до легковесных процессов и (легковесных > же) потоков. > Ну нет больше разницы между потоком и процессом как таковой. > Есть только разница в объёме информации сохраняемого/восстанавливаемого контекста выполнения > при переключении задач после появления коу и ммэп. Ну а в линуксе, и clone, и fork вызывают do_fork, которая создаёт отдельную task_struct, и пихает её планировщику. Именно с ними планировщик и работает, это и есть единица планирования. Каждая такая таска содержит весь набор, куда входят контексты потока исполнения, то есть регистры, счётчик команд, содержит своё, отдельное от других тасков, виртуальное пространство памяти, содержит набор IO дескрипторов и пр. вещи первой необходимости. У разных тасков, относящихся к одному и тому же процессу исполнения пользовательской программы, или являющиеся кернель тредами, таски по содержанию идентичны, и отличаются только инфой, относящиейся к потоку исполнения, но IO дескрипторы, сруктуры виртуальной памяти и прочие вещи у них общие, но при этом, это всё таки разные таски и планировщик, переключаясь между ними, производит перезагрузку в соответствии с данными этой таски. Говорят что в линуксе поток и процесс одно и то же, это не верно, в линуксе всё есть процесс, то есть каждый таск имеет полное окружение процесса, но некоторые из них могут отличаться только регистрами контекста потока. Про такие говорят что это потоки одного процесса, но по мне так это некорректное сравнение.
	Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

	98. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+1 +/–
	Сообщение от ананим on 26-Авг-14, 19:31
	«Ядро LINUX», д. бовет м. чезати (например тут http://padabum.com/d.php?id=16335), Стр. 177 > Создание потока ядра > Функция kernel_thread() создаёт новый поток ядра. Она принимает в качестве параметров адрес функции ядра, подлежащей выполнению (fn), аргумент, передаваемый этой функции (arg), и набор флагов клона (flags). Фактически она вызывает функцию do_fork() со следующими аргументами: >   do_fork(flags|CLONE_VM|CLONE_UNTRACED, 0, pregs, 0, NULL, NULL); > Флаг CLONE_VM позволяет избежать копирования таблиц страниц… Стр. 169 > Функция do_fork(), обрабатывающая системные вызовы clone(), fork() и vfork()… http://lwn.net/Articles/354213/ > Implement clone2() system call зыж как отделите и сравните маркетинговый булшит из вашего предыдущего выступления с вышесказанным: > «Как в solaris. Там единицей планирования является сущность kernel thread…» тогда и можно будет поспорить. да и то, о деталях, не более (а то например тема COW - Copy On Write - при копировании… как вы там сказали? «которая создаёт отдельную task_struct, и пихает её планировщику»?…не раскрыта ☺)
	Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

	103. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+/–
	Сообщение от metallica (ok) on 26-Авг-14, 22:10
	> Флаг CLONE_VM позволяет избежать копирования таблиц страниц… > «которая создаёт отдельную task_struct, и пихает её планировщику»?…не > раскрыта ☺) Что сказать то хотели? Да не создаёт отдельную mm_struct, потому что в task_struct содержится только указатель не неё mm_struct* mm. Также указатель на массив указателей на структуры file наследуется, так как в task_struct только указатель на таковой files->fd_array, но отдельная task_struct создаётся и все поля заполняются, и то что значения тех или иных указателей могут совпадать у разных task_struct выше говорил. И раз отдельная task_struct создаётся и содержит информацию о всех всех составляющих, и что эта сущность описывает потоки пользовательского процесса, потоки ядра и каждая их которых содержит все хозяйство ассоциированное с понятием процесс, память, IO space,  и пр, и то что процессор, переключаясь между этими тасками, каждый раз загружает инфу из них в регистры заново даже если значения полей совпадают (load_cr3(next->pgd например),   то можно делать вывод, что в линуксе всё есть процесс. Что до соляриса с его тредами, то повторюсь, что структура, которой манипулирует планировщик и которая соответствует отдельному кернель треду, содержит только информацию о контексте потока исполнения: регистры, флаги, но нет ничего, что относится к пространствам памяти, IO, флаги уровня кольца защиты и прочей, характерной для сущности "процесс" информации. Вот те кернель треды, которые создаются для прокручивания задач пользовательского уровня, прокручивают процедуру, которая уже создаёт и манипулирует структурами с информацией о пространствах памяти, IO контексты потоков исполнения, и этот кернель тред поочерёдно переключает контексты, по информации из этих струткур, в пределах своих квантов времени исполняет код пользовательских процессов, в каждом их которых может быть несколько разных LWP. То  есть планировщик по тику таймера переключает только кернель потоки, а в них уже может осуществляться планирование исполнения задач пользовательского уровня и само исполнение. ЗЫ фразу комерческий булшит отсюда выкинуть подальше, она вообще не в тему, даже если больше сказать нечего.
	Ответить | Правка | ^ к родителю #98 | Наверх | Cообщить модератору

	109. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+/–
	Сообщение от ананим on 27-Авг-14, 01:15
	Сразу говорю, прочитал только первые пару предложение. Дальнейшее смысла читать (пока? х/з) не вижу. 1. kernel_thread есть не только в соляре (см. выше) 2. обслуживается тем же do_fork (см. выше) 3. сам fork — это только частный случай вызова на выволнение do_fork (см. выше) 4. системные вызовы для этих НЕ_частных случаев таки тоже есть (см. выше). Не fork'ом единым, как говориться. 5. всё это знает и умеет pthread (через который кстати прозрачно и реализованы стандарты С/С++11 и 14 и в гцц, и в шланге) 6. Вы слишком много трыдите не по-существу. Книжки по соляре (коих было прочитано не мало) — этого мало, чтобы гнуть пальцы. 7. роль COW и mmap всё ещё не раскрыта. При этом они фактически сводят к нулю разницу между потоками и процессами с точки зрения производительности.
	Ответить | Правка | ^ к родителю #103 | Наверх | Cообщить модератору

	111. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+/–
	Сообщение от ананим on 27-Авг-14, 01:50
	Зыж Прочитал ещё пару предложений — ну полный бред! >И раз отдельная task_struct создаётся и содержит информацию о всех всех составляющих, и что эта сущность описывает потоки пользовательского процесса, потоки ядра и каждая их которых содержит все хозяйство ассоциированное с понятием процесс, память, IO space, и пр, и то что процессор, переключаясь между этими тасками, каждый раз загружает инфу из них в регистры заново даже если значения полей совпадают То, что структуры созданы, совсем не значит, что они загружаются в регистры процессора каждый раз. Не? Не понятно? В регистры проца при переключении загружается только то, что в них было в предыдущий квант выполнения. И НЕ БОЛЕЕ. Это же очевидно. Иначе программа просто не сможет продолжить своё выполнение. Какой бред (и кто?) Вам в голову загрузили? Эти структуры (которые есть таки и в соляре. угу. иначе откуда бы она их например в 'ps -ef…' брала), даже будучи перезаполненными при создании контекста с нуля (а это не так!), они уже есть в памяти. Их банально нет нужды куда-то перезагружать вообще. Зачем это надо делать? (И зачем этот бред мне нужно комментировать?) И опять же напоминаю, есть COW, которая очень широко используется в linux'е в этих случаях. В общем этот бред опровергается манами: $ man 2 fork … > ЗАМЕЧАНИЯ >       В  Linux, fork() реализован с помощью «копирования страниц при записи» (copy-on-write, COW), поэтому расходы на вызов состоят из времени и памяти, требуемой на копирование страничных таблиц родителя и создания уникальной структуры, описывающей задачу. >       Начиная с версии 2.3.3, вместо того, чтобы вызывать системный вызов fork(), обёрточная функция fork() в glibc, как часть реализации нитей NPTL, вызывает  clone(2)  с  флагами,  которые  обеспечивают поведение  традиционного системного вызова (вызов fork() эквивалентен вызову clone(2), если значение равно flags SIGCHLD). Обёртка в glibc вызывает все обработчики при ветвлении (fork), которые были зарегистрированы с помощью pthread_atfork(3). в общем не читайте уставревших книжек по соляре. в них в лучшие то годы половина текста была на тему «какие мы лучшие», даже не утруждаясь на элементарное ознакомление с «оппонентами».
	Ответить | Правка | ^ к родителю #103 | Наверх | Cообщить модератору

	136. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	–1 +/–
	Сообщение от metallica (ok) on 27-Авг-14, 11:55
	> Не? Не понятно? > в памяти. Их банально нет нужды куда-то перезагружать вообще. Зачем это > надо делать? (И зачем этот бред мне нужно комментировать?) > И опять же напоминаю, есть COW, которая очень широко используется в linux'е > в этих случаях. В общем этот бред опровергается манами: > $ man 2 fork > … >> ЗАМЕЧАНИЯ >>       В  Linux, fork() реализован с помощью «копирования страниц при записи» (copy-on-write, COW), поэтому расходы на вызов состоят из времени и памяти, требуемой на копирование страничных таблиц родителя и создания уникальной структуры, описывающей задачу. >>       Начиная с версии 2.3.3, вместо того, чтобы вызывать системный вызов fork(), обёрточная функция fork() в glibc, как часть реализации нитей NPTL, вызывает  clone(2)  с  флагами,  которые  обеспечивают поведение  традиционного системного вызова (вызов fork() эквивалентен вызову clone(2), если значение равно flags SIGCHLD). Обёртка в glibc вызывает все обработчики при ветвлении (fork), которые были зарегистрированы с помощью pthread_atfork(3). Ваш ответ похож на изливания воды через край из наполнившегося таза. Хватит тут про мануалы, glibc, COW,  просто смотрите исходники: В линукс любое переключение таски вызывает __schedule, в которой обязательно на другую таск, если переключение одобрено (счётчик preempt), вызывается context_switch, что она делает смотрим тут http://lxr.free-electrons.com/source/kernel/sched/core.c#L2295 Для соляриса то же самое, смотрите в исходники, лучше всего начать отсюда http://fxr.watson.org/fxr/source/common/disp/disp.c?v=OPENSO...
	Ответить | Правка | ^ к родителю #111 | Наверх | Cообщить модератору

	140. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+/–
	Сообщение от ананим on 27-Авг-14, 13:25
	Да. В линуксе управлением переключения задач занимается шедулер. Вариантов которого может быть несколько. И? Что сказать то хотели? Как извернуться? У вас каша в голове.
	Ответить | Правка | ^ к родителю #136 | Наверх | Cообщить модератору

	149. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	–1 +/–
	Сообщение от metallica (ok) on 27-Авг-14, 15:17
	> Да. В линуксе управлением переключения задач занимается шедулер. > Вариантов которого может быть несколько. > И? > Что сказать то хотели? Как извернуться? > У вас каша в голове. А у Вас бульон в голове. Повторю ещё раз смысл своих окровений. Единицей планирования в солярисе является сущность, содержащая информацию с контекстом потока исполнения, и не более, работающего в окружении пространстве ядра. Единицей планирования в линуксе, независимо от типа планировщика, является сущность, содержащая все атрибуты процесса, набор данных, которые в совокупности называются окружением процесса. Поэтому шедулер в солярисе управляет потоками ядра, шедулер в линуксе процессами. Какие-то из них, как, например, так называемые кернель треды, или разные потоки одного процесса исполнения пользовательской задачи,  могут иметь общие данные окружения процесса, то есть поля из task_struct каждой из них указывают на одни те же общие массивы и структуры. Ферштейн? Для доказательства буду приводить ссылки в исходники, так что дерзайте.
	Ответить | Правка | ^ к родителю #140 | Наверх | Cообщить модератору

	150. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+/–
	Сообщение от ананим on 27-Авг-14, 16:33
	> А у Вас бульон в голове. Вы — идиoт. И вот почему: > Повторю ещё раз смысл своих окровений. Единицей планирования в солярисе является сущность, содержащая информацию с контекстом потока исполнения, и не более, работающего в окружении пространстве ядра. И что? ☺ Кто с этим спорил то? Вот только профита от этого на современном оборудовании нет. (Соляра на x86_64 тот ещё тормоз по сравнению с linux'ом — с этом то вы спорить не будете?) > Поэтому шедулер в солярисе управляет потоками ядра, шедулер в линуксе процессами. Брехня. Задачами. К коим относятся и kernel_thread, которые тоже есть в линуксе (уже и пруфы давал, бесполезно ☹) и создать такие вы вполне можете тем же clone(2). > содержащая все атрибуты процесса, набор данных, которые в совокупности называются окружением процесса. Полнейший бред. Вы путаете контекст выполнения с окружением процесса. Неужели вы думаете, что в соляре нет окружения процесса? Вау! Это что-то новенькое в никс-устройстве. зыж > Ферштейн? Для доказательства буду приводить ссылки в исходники, так что дерзайте. Ну конечно! Вместо обоснования проще извернуться и сказать что вот этот кусок кода лучше вот этого (не понятно чем), прикрывая своё полное невежество. Кстати (и я так могу ☺!) Вот kernel_thread — http://lxr.free-electrons.com/source/kernel/fork.c#L1648 Можете хоть обсоздаваться потоками ядра.
	Ответить | Правка | ^ к родителю #149 | Наверх | Cообщить модератору

	152. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	–1 +/–
	Сообщение от metallica (ok) on 28-Авг-14, 01:24
	> Можете хоть обсоздаваться потоками ядра. Повторю ещё раз, в линуксе и fork, и clone, и kernel_thread создают одну и ту же сущность планирования, которая содержит информацию, которая называется не иначе как окружение процесса исполнения задачи, и которой манипулирует планировщик. От поняти потока это отличается тем, что с потоком ассоциирована только информация, без объектов глобального характера вроде информации о пространстве памяти. В солярис, уже говорил чем манипулирует планировщик, и предлагаю пройтись по всей цепочке. thread_create-поток ядра, сущность планирования. При создании процесса происходит такая эстафета: cfork http://fxr.watson.org/fxr/source/common/os/fork.c?v=OPENSOLA... forklwp http://fxr.watson.org/fxr/source/common/os/lwp.c?v=OPENSOLAR... lwp_create http://fxr.watson.org/fxr/source/common/os/lwp.c?v=OPENSOLAR... thread_create http://fxr.watson.org/fxr/source/common/disp/thread.c?v=OPEN... квантами которого и исполняется пользовательский процесс, чтоб лучше понять эту сущность планирования, достаточно глянуть на её ключевую структуру http://fxr.watson.org/fxr/source/common/sys/thread.h?v=OPENS... не найдёте там инфу, связанную с пространством памяти, вроде mm_struct* mm в линуксовой task_struct, или инфу, связанную с пространством IO, вроде struct files_struct *files в линуксовой таске. Планировщик манипулирует именно кернель тредами, и, если посмотреть какие процедуры исполняют те кернель треды, что создаются в cfork, то можно понять что планирование исполнения пользовательских процессов происходит в соответствующем кернель треде манипуляциями с структурой proc_t, а не в планировщике по тикам таймера. Разницу между линуксовой схемой уловили?
	Ответить | Правка | ^ к родителю #150 | Наверх | Cообщить модератору

	158. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+/–
	Сообщение от ананим on 29-Авг-14, 00:39
	> Повторю ещё раз, в линуксе и fork, и clone, и kernel_thread создают одну и ту же сущность планирования........ Ты не исправимый дурак. См. выше пруфы. зыж Ну ладно бы переключение контекстов вспомнил. Нет жеж. Я искренне жалею о потерянном времени (дальше вообще чушь. Ты хоть понимаешь вообще о чём говоришь? Пичалька. Ещё один долбень.) Ззыж Сори за мой французкий. Но по другому никак. Враньё будет.
	Ответить | Правка | ^ к родителю #152 | Наверх | Cообщить модератору

	11. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+2 +/–
	Сообщение от Vkni (ok) on 25-Авг-14, 14:01
	> А что за чудо-технологии есть в Haiku? > Такие, что даже без родного ядра кому-то нужны? Очень хороший десктопный планировщик, своя файловая система.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	37. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	–1 +/–
	Сообщение от Xasd (ok) on 25-Авг-14, 19:23
	> Очень хороший десктопный планировщик, своя файловая система. лучше планировщик и fs -- чем на Linux ? а как проверить смогли это? :-) Linux он ведь на практике, а Haiku в теории только :)
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	61. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+/–
	Сообщение от Tav (ok) on 26-Авг-14, 03:05
	Десктопная ОС должна моментально реагировать на ввод пользователя независимо от того, чем и как она загружена. Линукс в этом отношении работает неудовлетворительно. Как с этим в Хайку не знаю, но пусть лучше делают свое ядро, так есть хоть какая-то надежда на что-то лучшее.
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	75. "Разработчики Haiku в штыки восприняли проект перехода на..."	–1 +/–
	Сообщение от arisu (ok) on 26-Авг-14, 08:49
	> Линукс в этом отношении работает неудовлетворительно. переключился в VT. нажал кнопку на клавиатуре — сразу появилась буква. «ещё лучше» — это уже телепатия.
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	88. "Разработчики Haiku в штыки восприняли проект перехода на..."	–1 +/–
	Сообщение от Vkni (ok) on 26-Авг-14, 17:06
	> переключился в VT. нажал кнопку на клавиатуре — сразу появилась буква. «ещё > лучше» — это уже телепатия. Да, но в Линуксе это только тогда, когда ресурсов компа почти "бесконечно много" - для отрисовки буквы в VT достаточно Пентиума, а у тебя машина на 3 порядка более быстрая. Если ресурсов будет относительно нехватать, тормоза появятся и в терминале (и я неоднократно такое видел). Гайка же значительно более "десктопная" система - она и на слабом компьютер с высокой нагрузкой не даёт лагов. Просто при нагрузке появляется ощущение, что система равномерно замедляется. Проблема Гайки в том, что в ней "нет Хов" - есть прибитый гвоздями интерфейс, который где-то удобен, но по большей части - нет. Под Хами есть быстрый красивый WindowMaker, есть требующий обучения удобнейший i3, есть Enlightenment для желающих крутого, есть KDE для непритязательных и GNOME для любителей странного. А тут, как и на Windows, как и на OSX - "слушайте ваши Валенки".
	Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

	92. "Разработчики Haiku в штыки восприняли проект перехода на..."	+1 +/–
	Сообщение от arisu (ok) on 26-Авг-14, 17:14
	>> переключился в VT. нажал кнопку на клавиатуре — сразу появилась буква. «ещё >> лучше» — это уже телепатия. > Да, но в Линуксе это только тогда, когда ресурсов компа почти "бесконечно > много" эвона как… видать, на 386-х по часу ждали, пока буква появится. > Если ресурсов будет относительно > нехватать, тормоза появятся и в терминале (и я неоднократно такое видел). никогда не видел. и это… я именно про VT речь веду. потому что изначально речь шла про линукс, а ядро ведь окромя VT ничего больше и не умеет. ну, serial там ещё, такое.
	Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

	95. "Разработчики Haiku в штыки восприняли проект перехода на..."	–1 +/–
	Сообщение от Vkni (ok) on 26-Авг-14, 18:42
	> эвона как… видать, на 386-х по часу ждали, пока буква появится. Во времена 386-х не было framebuffer'а. Поэтому буквы там именно этим способом не появлялись. А на Pentium'ах framebuffer ощутимо тормозил по сравнению с текстовым режимом, правда проявлялось это в распечатках на экран больших файлов. > никогда не видел. Поздравляю. У меня бывало, что диск и память заняты и консольная программа не может даже отрисоваться по какой-то причине. > и это… я именно про VT речь веду. потому что изначально речь > шла про линукс, а ядро ведь окромя VT ничего больше и > не умеет. ну, serial там ещё, такое. Тем не менее, планировщик сидит в ядре. И если он, когда тебе не хватает ресурсов машины, тормозит не, скажем Gimp, а, скажем, компилятор, ты видишь, что машина "отзывчива". Если же планировщик тормозит ту программу, с которой ты прямо сейчас работаешь, то ты видишь лаги. Т.о. от планировщиков ядра зависит очень многое в ощущении "тормознутости" компьютера.
	Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

	96. "Разработчики Haiku в штыки восприняли проект перехода на..."	+/–
	Сообщение от arisu (ok) on 26-Авг-14, 18:48
	>> эвона как… видать, на 386-х по часу ждали, пока буква появится. > Во времена 386-х не было framebuffer'а. у меня его тоже нет, например. >> никогда не видел. > Поздравляю. У меня бывало, что диск и память заняты и консольная программа > не может даже отрисоваться по какой-то причине. framebuffer? кажется, я нашёл, в чём проблема…
	Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

	126. "Разработчики Haiku в штыки восприняли проект перехода на..."	–1 +/–
	Сообщение от Аноним (??) on 27-Авг-14, 11:02
	> framebuffer? кажется, я нашёл, в чём проблема… Да, послать 1 байт для отрисовки 1 буквы проще и быстрее. Проблема только в том что 80х25 на моем мониторе выглядит как первая строчка на приеме у окулиста :). Под другие реалии делалось...
	Ответить | Правка | ^ к родителю #96 | Наверх | Cообщить модератору

	97. "Разработчики Haiku в штыки восприняли проект перехода на..."	–1 +/–
	Сообщение от Xasd (ok) on 26-Авг-14, 18:57
	> Если же планировщик тормозит ту программу, с которой ты прямо сейчас работаешь, то ты видишь лаги. что должен быть за такой "волшебный" планеровщик, который должен телепатической магией понимать какую программу нужно для пользователя "убыстрить" а какую программу "замедлить"? если система тормозит -- то значит она тормозит ВСЯ -- и планировщик это не исправит. ты открыл видеоролик на заднем фоне, архивируешь файлы, и одновременно что-то печатаешь в документе. откуда планировщик узнает какую из этих трёх программ нужно "замедлить"? всё что можно сделать -- это лишь небольшие оптимизации на уровне user_space. например файловый манагер (да, да, который работает в user_space) должен помечать свои служебные файловые процессы как низкоприоритетные (ionice). но даже и это является спорным решением (потому что сфигали копирование файлов это низкоприоритетный процесс -- именно в обязательно порядке? в каких-то случаях копирование файлов это весьма приоритетная задача).
	Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

	120. "Разработчики Haiku в штыки восприняли проект перехода на..."	+/–
	Сообщение от Алексей Морозов (ok) on 27-Авг-14, 08:53
	> ты открыл видеоролик на заднем фоне, архивируешь файлы, и одновременно что-то печатаешь > в документе. откуда планировщик узнает какую из этих трёх программ нужно > "замедлить"? Раньше это называлось Active Window Boost. Натурально, приложение, чьё окошко сейчас в фокусе, на некоторых [неназываемых] системах получало ощутимое увеличение приоритета. Впрочем, те системы давно сдохли в страшных муках и уже даже вонять перестали.
	Ответить | Правка | ^ к родителю #97 | Наверх | Cообщить модератору

	148. "Разработчики Haiku в штыки восприняли проект перехода на..."	+/–
	Сообщение от Vkni (ok) on 27-Авг-14, 14:30
	> Раньше это называлось Active Window Boost. Это лишь одна из эвристик.
	Ответить | Правка | ^ к родителю #120 | Наверх | Cообщить модератору

	161. "Разработчики Haiku в штыки восприняли проект перехода на..."	+/–
	Сообщение от Anonym1 on 01-Окт-14, 16:48
	>> ты открыл видеоролик на заднем фоне, архивируешь файлы, и одновременно что-то печатаешь >> в документе. откуда планировщик узнает какую из этих трёх программ нужно >> "замедлить"? > Раньше это называлось Active Window Boost. Натурально, приложение, чьё окошко сейчас в > фокусе, на некоторых [неназываемых] системах получало ощутимое увеличение приоритета. > Впрочем, те системы давно сдохли в страшных муках и уже даже > вонять перестали. MacOS/IOS уже сдохла? И даже вонять перестала?
	Ответить | Правка | ^ к родителю #120 | Наверх | Cообщить модератору

	100. "Разработчики Haiku в штыки восприняли проект перехода на..."	+2 +/–
	Сообщение от Аноном on 26-Авг-14, 20:45
	Когда я в Блендер ставлю что-то симулироваться или рендерю(на ЦПУ), то спокойно серфю нет без какого либо дискомфорта или смотрю фильмы в 1080р(на ЦПУ не ГПУ). Пару раз бывало что видео на долю секунды приторможивалось. Вы таки хотите сказать, что Гайка отиграет лучше в этой ситуации? Тут чудес не бывает, либо рендерить будет дольше либо идеальная картинка при просмотре фильма.
	Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

	106. "Разработчики Haiku в штыки восприняли проект перехода на..."	–1 +/–
	Сообщение от Vkni (ok) on 27-Авг-14, 01:05
	> Вы таки хотите сказать, что Гайка отиграет лучше в этой ситуации? Тут чудес не бывает, либо рендерить будет дольше либо идеальная картинка при просмотре фильма. Я на Блендере ничего никогда не делал, а вот в ситуации, когда что-то компилируется без (nice -n 19), Гайка у меня получалась значительно отзывчевее, чем Linux. Вообще, даже на древней машинке (P4), на которую я как-то ставил Гайку, никаких лагов не было. При нагрузке просто проседает общая производительность - как будто частота уменьшается в 1.5 раза или в 2. Но отклик на действия пользователя всегда быстр, как будто компьютер не загружен. А вот под Linux'ом или, ещё более выпукло, под Windows при запуске фоновых задач появляются небольшие лаги. ---------------------------- Разумеется, чудес не бывает - если одновременно запущено две задачи (фоновая и интерактивная), полностью сжирающие ресурс компьютера, чтобы дать быстрый отклик пользователю, нужно отдать на время этот ресурс целиком интерактивной задаче. Фоновая задача, разумеется, притормаживается. Но, как учат нас шутеры, интерактивная задача должна дать ответ за примерно 1/60 секунды, дальше идёт ожидание действий пользователя, и ресурс компа можно отдать целиком фоновой задаче. Конечно, фоновая притормозится на эту 1/60 секунды, но для неё это не важно - она в любом случае работает значительно дольше. Поэтому планировщик в идеале должен различать 2 класса задач: фоновые и интерактивные. Интерактивным нужно выдавать много ресурсов на короткое время, а фоновые в этот момент притормаживать. Тогда пользователь будет видеть, что компьютер как бы "не загружен". Это "десктопный" планировщик, для серверов он не подходит. Планировщик Гайки строился по образу и подобию планировщика BeOS, сделанного специально для десктопов, с учётом опыта UNIX. Поэтому разработчики BeOS сумели этот момент учесть.
	Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

	156. "Разработчики Haiku в штыки восприняли проект перехода на..."	+1 +/–
	Сообщение от Аноним (??) on 28-Авг-14, 16:52
	> что-то компилируется без (nice -n 19), Гайка у меня получалась значительно > отзывчевее, чем Linux. Если уж мы о компиляции, я как раз в xonotic иногда играю если вломак ждать большую пересборку, размером с линевое ядро. ЧСХ, я даже не замечаю что в фоне make с -j 8 вкалывает - отловить завершение компила можно разве что по прекращению миганию LEDа харда :). Наверное я что-то делаю не так...
	Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

	160. "Разработчики Haiku в штыки восприняли проект перехода на..."	+/–
	Сообщение от Vkni (ok) on 29-Авг-14, 16:57
	> Наверное я что-то делаю не так... Наверное, от машины что-то иногда зависит. :-)
	Ответить | Правка | ^ к родителю #156 | Наверх | Cообщить модератору

	87. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+/–
	Сообщение от ананим on 26-Авг-14, 17:02
	голословная брехня. как пример — мэнеджер задач в том же вантузе фиг вызовешь при достаточной нагрузка. или например блэндер (на добрую половину на питоне написан. может больше) и в вантузе, и в маке даже визуально гораздо менее отзывчевее (и тормознее), чем в линухе. Любой портированный софт имеет приоритетную платформу, где он работает отзывчевее. Всё определяется качеством оптимизации софта для на целевой платформе. Вот и всё.
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	91. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	–1 +/–
	Сообщение от Vkni (ok) on 26-Авг-14, 17:10
	> голословная брехня. > как пример — мэнеджер задач в том же вантузе фиг вызовешь при > достаточной нагрузка. Это потому, что планировщик ЦП и планировщик IO написаны без учёта десктопности. Иначе бы они отдали больше приоритета запуску этого менеджера.
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	99. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+/–
	Сообщение от ананим on 26-Авг-14, 19:40
	нет такого понятия «десктопность». и на таком уровне прохвисиананизма мне обсуждать что-либо не интересно. поэтому первое что я и написал — брехня.
	Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

	113. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+/–
	Сообщение от Аноним (??) on 27-Авг-14, 06:52
	> нет такого понятия «десктопность». > и на таком уровне прохвисиананизма мне обсуждать что-либо не интересно. > поэтому первое что я и написал — брехня. произведение не читал, но автора осуждаю...
	Ответить | Правка | ^ к родителю #99 | Наверх | Cообщить модератору

	142. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+/–
	Сообщение от ананим on 27-Авг-14, 13:26
	Вот именно. Я как раз об этом.
	Ответить | Правка | ^ к родителю #113 | Наверх | Cообщить модератору

	89. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	–1 +/–
	Сообщение от Vkni (ok) on 26-Авг-14, 17:07
	> Как с этим в Хайку не знаю, но пусть лучше делают свое > ядро, так есть хоть какая-то надежда на что-то лучшее. В Гайке с именно этим очень хорошо.
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	49. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+2 +/–
	Сообщение от Аноним (??) on 26-Авг-14, 00:40
	> Очень хороший десктопный планировщик, При том нормально инструментированных метрик мы видимо не дождемся, выслушивая рассказы о том как все звиздато, которые ничем не подкреплены. > своя файловая система. Своя файловая система нынче есть у каждой собаки. Проблема то не в том чтобы СВОЯ файловая система. А в том чтобы ХОРОШАЯ. При том не по меркам ДВАДЦАТИЛЕТНЕЙ давности а СЕЙЧАС. А желательно еще и "чем-то лучше чем у остальных". Иначе нафига на это прорву ресурсов сливать, кроме прокачки NIH синдрома?
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	90. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	–1 +/–
	Сообщение от Vkni (ok) on 26-Авг-14, 17:09
	> При том нормально инструментированных метрик мы видимо не дождемся, выслушивая рассказы > о том как все звиздато, которые ничем не подкреплены. Нормально инструментированных десктопных метрик я нигде не видел. > Своя файловая система нынче есть у каждой собаки. Проблема то не в > том чтобы СВОЯ файловая система. А в том чтобы ХОРОШАЯ. Она своя в том смысле, что не POSIX. Т.е. некоторая попытка выйти за идеологию UNIX.
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	127. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+1 +/–
	Сообщение от Аноним (??) on 27-Авг-14, 11:10
	> Нормально инструментированных десктопных метрик я нигде не видел. Я видел, вокруг и около пингвинов тулзы типа latencytop. Но вообще-то кому латенси не пофиг - на linuxcnc там вон рубка в микросекундных диапазонах. При том у них померяны времена отклика, с точностями в районе наносекунд, т.к. им оно надо - их некие гарантии насчет времени парят, знаете ли, при управлении промышленным барахлом. Так что пи...ж про отличную отзывчивость - это круто и все такое, но без инструментированных метрик - это именно пи...ж. И кстати обычно низкая латентность сажает производительность. Т.к. в целом долбить данные большими порциями и не переключать контексты - быстрее. > Она своя в том смысле, что не POSIX. Т.е. некоторая попытка выйти > за идеологию UNIX. Помнится первые версии таскали PE EXE и были похожи на эдакий виндус. А потом городили всякие костыли и подпорки. В результате по состоянию на сейчас это превратилось в развлекуху для каких-то некрофилов которые никак не могут выкинуть окаменевший gcc 2.95. На поддержку этого окаменелого шита явно уходит время и силы, которые можно было бы потратить более результативно. Просто операционку надизайнили другие, а этот сброд элементарно не смеет взять на себя ответствненость за систему и посметь что-то там переработать или улучшить. Или хотя-бы просто выбросить совсем уж окаменелые компоненты.
	Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

	137. "Разработчики Haiku в штыки восприняли проект перехода на..."	+/–
	Сообщение от arisu (ok) on 27-Авг-14, 12:17
	юзер, ты неправ.
	Ответить | Правка | ^ к родителю #127 | Наверх | Cообщить модератору

	141. "Разработчики Haiku в штыки восприняли проект перехода на..."	+/–
	Сообщение от Аноним (??) on 27-Авг-14, 13:25
	> юзер, ты неправ. А как насчет нормальных аргументов? :) А то в этих самых шутерах, про которые Vkni бла-бла развел, с практической точки зрения... ну вон в том же xonoitc например, я как-то без проблем попадаю из nex (мощная railgun-подобная пушка) через полкарты в вон те 20 пикселей которые еле видно, при том быстрее чем они подстрелят меня из такой же штуки. Это требует сделать быстрые и плавные движения, с идеальной точностью. И уж ясен фиг, любой лаг в момент такого движения все факапит: это сочетание скорости "грубого" наведения и ювелирной точности, чтобы быстро прицелиться, но - не промазать. До кучи это 2560х1400, на открытом драйвере, с настройками high. Как раз нежданно-негаданно натянул толпу народа в DM, на большой карте где спрятаться негде, в основном как раз nex-ом, по принципу "кто первый выстрелит и не промажет" :). Были бы у меня лаги - фиг с два я бы обставил толпу игроков, в т.ч. ряд опытных и опасных. Единственное что я использую low latency сборки ядер (за основу взят конфиг убунтуйского -low-latency ядра 3.16). Там что-то сделано на предмет прерывания работы в том числе и ядра, но если честно - я без вкуривания конфига черта с два их отличу. Вообще, основное время реакции привносит или сеть, или если там все хорошо - тогда сам человек. То-есть на свежую голову я могу всем всыпать :). А вот если я сонный - без ведра вазелина на сервера шутеров лучше вообще не соваться. Натянут. Так что наибольшее влияние на лаг я бы отдал ... уровню мозговой активности. Как минимум с моей конфигурацией железа и софта оно вот так: сильнее всего зависит от состояния игрока.
	Ответить | Правка | ^ к родителю #137 | Наверх | Cообщить модератору

	143. "Разработчики Haiku в штыки восприняли проект перехода на..."	+/–
	Сообщение от arisu (ok) on 27-Авг-14, 13:30
	>> юзер, ты неправ. > А как насчет нормальных аргументов? :) ты серьёзно ожидаешь, что я буду спорить с обзыванием «сбродом»? O_O
	Ответить | Правка | ^ к родителю #141 | Наверх | Cообщить модератору

	145. "Разработчики Haiku в штыки восприняли проект перехода на..."	+/–
	Сообщение от Аноним (??) on 27-Авг-14, 13:37
	> ты серьёзно ожидаешь, что я буду спорить с обзыванием «сбродом»? O_O С этим бесполезно спорить. Нормальное руководство проектом или уж есть и тогда смеет брать штурвал на себя, или нет - и тогда получаются реактосы и гайки, жалкие ripoff с того что разработано не ими. А они не смеют ничего покрутить и являются жалкими лакеями чужого дизайна. Ничего толком не решая. Апофеозом такого лакйства становится использование GCC 2.95 в 2014 году и прочие непотребства.
	Ответить | Правка | ^ к родителю #143 | Наверх | Cообщить модератору

	146. "Разработчики Haiku в штыки восприняли проект перехода на..."	+/–
	Сообщение от arisu (ok) on 27-Авг-14, 13:42
	вот ты опять пытаешься говорить о том, в чём не даёшь себе труда разобраться. ну, то есть, спорить в принципе бессмысленно, потому что ты опять выстроил у себя в голове какой-то образ и проецируешь его наружу.
	Ответить | Правка | ^ к родителю #145 | Наверх | Cообщить модератору

	155. "Разработчики Haiku в штыки восприняли проект перехода на..."	+1 +/–
	Сообщение от Аноним (??) on 28-Авг-14, 16:48
	> ты опять выстроил у себя в голове какой-то образ и проецируешь его наружу. Оно конечно да, но: если бы этот образ не соответствовал действительности - граждане бы давно забыли про gcc 2.95. Он апстримом не поддерживается много лет, так что труп стюардессы давно пора оставить в покое.
	Ответить | Правка | ^ к родителю #146 | Наверх | Cообщить модератору

	157. "Разработчики Haiku в штыки восприняли проект перехода на..."	–1 +/–
	Сообщение от arisu (ok) on 28-Авг-14, 17:06
	так не используй, никто же не заставляет. одна из целей хайки — поддерживать запуск старого биосного софта. ну, вот такая вот цель. для этого и держат. не хочешь — выкинь нафиг и пользуйся только тем, что уже напилили под новую.
	Ответить | Правка | ^ к родителю #155 | Наверх | Cообщить модератору

	30. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+1 +/–
	Сообщение от Аноним (??) on 25-Авг-14, 16:49
	Самобытность и независимость, которые дороже практической применимости в сто крат.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	35. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+1 +/–
	Сообщение от pavlinux (ok) on 25-Авг-14, 17:21
	> Самобытность и независимость, которые дороже практической применимости в сто крат. Это да, это важно - лучше быть чукчей с варганом, чем чукчей-диджеем.
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	50. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+3 +/–
	Сообщение от Аноним (??) on 26-Авг-14, 00:41
	> Самобытность и независимость, которые дороже практической применимости в сто крат. Ну тогда победителем объявляются те кто делает это в ластах и противогазе, стоя, в гамаке.
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	57. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+6 +/–
	Сообщение от Аноним (??) on 26-Авг-14, 01:34
	Цитата с ЛОРа   http://www.linux.org.ru/news/opensource/9152821/page13?lastm... Оценка крутости ядра Хайку Есть пять объектов ядра: виртуальные адрессные пространства (teams), потоки (threads), области виртуальной памяти (areas), IPC (ports), семафоры (semaphores). Причем по объему API не больше TRON, а это возводит Haiku в ембеддед класс, она может работать на 24МБ памяти. Все сервера которые обслуживают прикладные программы, статическая С++ линковка по ABI, выполнены с учетом SMP, по всему коду системных серверов расставлены семафоры в количестве завясящим от ядер, что называется файн-грейн локинг моделью. Именно поэтому ядро Haiku очень отзывчивое на современных многоядерных процессорах. Haiku OS запускается на Zotac Ion-A with Atom 330 dual core, и проигрывает 7 видеороликов MPEG-4 (704x396px) одновременно. Для сравнения на Linux это железо проигрывает только 3 таких ролика без падения произвлдительности. Это только, что бы было понятно почему некоторые считают целесообразность продолжение этого экспериментального опен-соурс проекта. Аналога такому проекту нет. Ближайших похожие проекты по fine-grained SMP kernel находятся на шаг позади проекта Haiku. На десерт. Система виртуальной памяти выполнена в академическо-педагогическом стиле, легко читается, легко портируема, как UVM, написана на С++ и работает, как было сказано уже на 24МБ. Распределяет области с использованием AVL деревьев, как Windows NT, и являет собой state-of the art системного программирования.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	74. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+/–
	Сообщение от Аноним (??) on 26-Авг-14, 06:03
	Помимо этого, слышал что качество кода в проекте очень высокое, можно читать на ночь.
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

	76. "Разработчики Haiku в штыки восприняли проект перехода на..."	+2 +/–
	Сообщение от arisu (ok) on 26-Авг-14, 08:57
	и всё это радостно перекрывается одним недостатком: C++. нет, не столько самим языком, сколько отсутствием для C++ стандартизованного ABI и стандарта на name mangling. в итоге библиотеки от разных плюсовых компиляторов друг с дружкой не дружат. и хайка вынуждена таскать с собой gcc2. и обновление компилятора до новой мажорной версии, например (положим, ребята таки забьют на старый закрытый софт) — это так любимый школогентоводами пересбор всего мира, только ещё геморройней. вот поэтому хайка — со всеми её хорошими идеями — так и будет маргинальщиной. вот так C++ загубил ещё один перспективный проект.
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

	107. "Разработчики Haiku в штыки восприняли проект перехода на..."	+/–
	Сообщение от Vkni (ok) on 27-Авг-14, 01:07
	> и всё это радостно перекрывается одним недостатком ДА. > вот поэтому хайка — со всеми её хорошими идеями — так и > будет маргинальщиной. Не только поэтому.
	Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

	121. "Разработчики Haiku в штыки восприняли проект перехода на..."	+1 +/–
	Сообщение от arisu (ok) on 27-Авг-14, 10:08
	> Не только поэтому. не будем заниматься казуистикой. причин, конечно, много, не все из них инженерные и всё такое. но C++ — один из оооочень весомых жерновов.
	Ответить | Правка | ^ к родителю #107 | Наверх | Cообщить модератору

	147. "Разработчики Haiku в штыки восприняли проект перехода на..."	+/–
	Сообщение от Vkni (ok) on 27-Авг-14, 14:26
	> не будем заниматься казуистикой. причин, конечно, много, не все из них инженерные > и всё такое. но C++ — один из оооочень весомых жерновов. Ещё и устарело всё, в том числе и граф. оболочка. Поэтому есть смысл рассматривать Haiku как музей идей BeOS. ;-) Отсюда, кстати, следует, что самобытность - это самое главное в Haiku.
	Ответить | Правка | ^ к родителю #121 | Наверх | Cообщить модератору

	58. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+1 +/–
	Сообщение от kim (??) on 26-Авг-14, 01:36
	Цитата с ЛОРа   http://www.linux.org.ru/news/opensource/9152821/page13?lastm... Оценка крутости ядра Хайку Есть пять объектов ядра: виртуальные адрессные пространства (teams), потоки (threads), области виртуальной памяти (areas), IPC (ports), семафоры (semaphores). Причем по объему API не больше TRON, а это возводит Haiku в ембеддед класс, она может работать на 24МБ памяти. Все сервера которые обслуживают прикладные программы, статическая С++ линковка по ABI, выполнены с учетом SMP, по всему коду системных серверов расставлены семафоры в количестве завясящим от ядер, что называется файн-грейн локинг моделью. Именно поэтому ядро Haiku очень отзывчивое на современных многоядерных процессорах. Haiku OS запускается на Zotac Ion-A with Atom 330 dual core, и проигрывает 7 видеороликов MPEG-4 (704x396px) одновременно. Для сравнения на Linux это железо проигрывает только 3 таких ролика без падения произвлдительности. Это только, что бы было понятно почему некоторые считают целесообразность продолжение этого экспериментального опен-соурс проекта. Аналога такому проекту нет. Ближайших похожие проекты по fine-grained SMP kernel находятся на шаг позади проекта Haiku. На десерт. Система виртуальной памяти выполнена в академическо-педагогическом стиле, легко читается, легко портируема, как UVM, написана на С++ и работает, как было сказано уже на 24МБ. Распределяет области с использованием AVL деревьев, как Windows NT, и являет собой state-of the art системного программирования.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	62. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+/–
	Сообщение от Аноним (??) on 26-Авг-14, 03:06
	> API не больше TRON, а это возводит Haiku в ембеддед класс, > она может работать на 24МБ памяти. Пингвина 2.4 запускали с 2 Мб флехи и 8Мб оперативы. А в 4Мб флеша и 16Мб оперативы живет даже ядро 3.х. При том оно еще и что-то полезное при этом делать может и поддерживает MIPS на платке размерами с пачку сигарет. А гайка эмбеддед только в теории - на практике в эмбедовке чаще всего некому ффтыкать на десктоп, зато перспектива пойти накодить всю поддержку железа в дровах самолично обычно никому не доставляет. > статическая С++ линковка по ABI, Настолько статическая, что GCC 2.95 до сих пор таскают. > поэтому ядро Haiku очень отзывчивое на современных многоядерных процессорах. Слушай, чувак, линуха тем кому надо отзывчивость нынче рискуют здоровьем в hard realtime системах использовать. Ну вон кексы из linux CNC например в реальном времени знают толк. Когда вы сможете CNC станок в реальном времени контролировать - приходите, поговорим за отзывчивость. > Haiku OS запускается на Zotac Ion-A with Atom 330 dual core, Кажется, гуглтранслейт лоханулся. > проигрывает 7 видеороликов MPEG-4 (704x396px) А как насчет одного, зато 20Мбит и full HD? Через аппаратный аксель пожалуй прокатит, у интела на  не сильно древних чипах через VA-API вывешено :) > экспериментального опен-соурс проекта. Аналога такому проекту нет. > деревьев, как ... > state-of the art системного программирования. Ну в общем зае...сь экспонатец для музейной полочки. Летать не будет. Копаться с GCC 2.95 в 2014 году - это state of art. Некрофилии и х-вого управления проектом.
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	71. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	–1 +/–
	Сообщение от beos (ok) on 26-Авг-14, 04:10
	Копаться с GCC 2.95 в 2014 году - это state of art. Некрофилии и х-вого управления проектом. Эт временное помутнение рассудка у разрабов - дань уважения BeOS :-))  http://www.haiku-os.org/guides/daily-tasks/updating-system Base operating system builds These are the nightly operating system builds containing the base OS package x86 (gcc2): http://download.haiku-os.org/haiku-repositories/master/x86_g.../ x86 (gcc4): http://download.haiku-os.org/haiku-repositories/master/x86/c.../ x86_64 (gcc4): http://download.haiku-os.org/haiku-repositories/master/x86_6.../ ARM (gcc4): http://download.haiku-os.org/haiku-repositories/master/arm/c.../ PowerPC (gcc4): http://download.haiku-os.org/haiku-repositories/master/ppc/c.../ Haikuports packages These are the latest compiled haikuports packages providing ported and native software x86 (gcc2): http://packages.haiku-os.org/haikuports/master/repo/x86_gcc2.../ x86 (gcc4): http://packages.haiku-os.org/haikuports/master/repo/x86/current/ x86_64 (gcc4): http://packages.haiku-os.org/haikuports/master/repo/x86_64/c.../ ARM (gcc4): http://packages.haiku-os.org/haikuports/master/repo/arm/current/ PowerPC (gcc4): http://packages.haiku-os.org/haikuports/master/repo/ppc/current/
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

	77. "Разработчики Haiku в штыки восприняли проект перехода на..."	+1 +/–
	Сообщение от arisu (ok) on 26-Авг-14, 09:00
	> Эт временное помутнение рассудка у разрабов - дань уважения BeOS :-))   да без разницы, C++ всё равно тупик. собрать сишные библиотеки при помощи gcc2, использовать в проектах с gcc4? да запросто. собрать плюсовые библиотеки при помощи gcc2, использовать в проектах с gcc4? а фиг вам.
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	82. "Разработчики Haiku в штыки восприняли проект перехода на..."	+/–
	Сообщение от beos (ok) on 26-Авг-14, 10:14
	Кстати, насчет gcc2  - так обозначена гибридная версия ОС, в которой работают бинарники, скомпилированные как 2 , так и 4 gcc http://www.haiku-os.org/guides/daily-tasks/updating-system PS чистой gcc2 гайки нету уже... http://s018.radikal.ru/i522/1408/75/2339fb4e9054.png
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	144. "Разработчики Haiku в штыки восприняли проект перехода на..."	+1 +/–
	Сообщение от Аноним (??) on 27-Авг-14, 13:34
	> Кстати, насчет gcc2  - так обозначена гибридная версия ОС, в которой > работают бинарники, скомпилированные как 2 , так и 4 gcc А похрен. С точки зрения разработчика - это означает что придется иметь себе мозг проблемами gcc 2.95. Караван идет со скоростью самого медленного верблюда, а в данном случае верблюд походу совсем увяз.
	Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

	128. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+/–
	Сообщение от Аноним (??) on 27-Авг-14, 11:18
	> Эт временное помутнение рассудка у разрабов Нет ничего более постоянного чем временное. >  - дань уважения BeOS :-))   Больше похоже на тотальную неспособность взять управление проектом в свои руки и посметь наконец что-нибудь поменять. Например, выбросив окаменелый и неподдерживаемый шит. GCC 2.95 уже не поддерживают даже те кто его писал. С какого рожна все должны фачить себе мозг проблемами древней версии компилера - не очень понятно.
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

4. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+14 +/–
Сообщение от Аноним (??) on 25-Авг-14, 12:34
Видимо, всё что запускается больше чем на 1% железа - недостаточно элитарно.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	114. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+/–
	Сообщение от Аноним (??) on 27-Авг-14, 06:57
	> Видимо, всё что запускается больше чем на 1% железа - недостаточно элитарно. к чему этот посыл?
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	122. "Разработчики Haiku в штыки восприняли проект перехода на..."	+/–
	Сообщение от arisu (ok) on 27-Авг-14, 10:10
	>> Видимо, всё что запускается больше чем на 1% железа - недостаточно элитарно. > к чему этот посыл? вышел дурачок на опеннет комментарии пописать, себя показать.
	Ответить | Правка | ^ к родителю #114 | Наверх | Cообщить модератору

8. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+/–
Сообщение от Аноним (??) on 25-Авг-14, 13:01
как-то так на Гайке живем и линухов не маем... http://youtu.be/g7_cmk5xHOo
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	36. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+/–
	Сообщение от pavlinux (ok) on 25-Авг-14, 17:36
	> как-то так на Гайке живем и линухов не маем... Сделайте, пжалста к среде чертёж понижающего, до 0.25, редуктора, за доп. плату расчёт усилий на выходной шестерне. Для шестёрн используйте латунь ЛК80-3. Входная мощность 3кВт, на приводной шестерне 18 зубьев. 10000$ за видео с демонстрацией работы под ОСь Хyйкy Впирёд!
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	39. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+/–
	Сообщение от Аноним (??) on 25-Авг-14, 19:32
	Если хочешь быть честным, то спросил бы то же самое на счёт линукса. И не сейчас, а как и на счёт Haiku - через ..нцать лет после создания - в году так 2002-м.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	45. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+/–
	Сообщение от pavlinux (ok) on 25-Авг-14, 22:51
	> Если хочешь быть честным, то спросил бы то же самое на счёт линукса. Дикий баян, в линухе все есть. В основном платное, задорого. Из халявы http://www.cad-schroer.com/products/medusa4-personal/free-pr... http://www.3ds.com/products-services/draftsight/overview/ > И не сейчас, а как и на счёт Haiku - через ..нцать лет после создания - в году так 2002-м. Для поколения пепси 2014-2002 это давно. В реальности - прогресс пока встал, когда выпустили первый двух-ядерный проц. Дальше галимый маркетинг и развод на бабки. В Linux тоже запор, ноухаву кончились году так в 2004/2005.   А хайку в такой жопе, .... думается на уровне 1980 года, только гуй разукрасили.
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	51. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+/–
	Сообщение от Аноним (??) on 26-Авг-14, 00:46
	> когда выпустили первый двух-ядерный проц. Дальше галимый маркетинг и развод на бабки. Только 8-ядерник кернель пересобирает как-то пошустрее 2-ядерника. И чего бы это он? :) > В Linux тоже запор, ноухаву кончились году так в 2004/2005. А какие убер-мега-прорывы ожидаются в general-purpose операционке? Вон у автомобилистов так уже наверное столетие. Ну то-есть народ уже более чем полвека предсказывал всякие там реактивные двигатели и прочее. А они оказались неэкономичными, шумными, с поганым КПД. Электродвигатели пытались прикрутить наверное уже полтора века. И все время упирались в вопрос чем их кормить. А ты говоришь - операционки... > А хайку в такой жопе, .... думается на уровне 1980 года, Не, ну GCC 2.95 все-таки не НАСТОЛЬКО ископаемый. Хотя я уже даже и не помню в каком году он был, может у тебя память хорошая?
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	56. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	–1 +/–
	Сообщение от pavlinux (ok) on 26-Авг-14, 01:22
	>[оверквотинг удален] Не, я не в обиду фанатам. Ну чессово, вот сижу, думаю, куда и зачем можно  пристроить этот хайку. Десктоп - труп. Ембеддед - ну да, и то, только с идейной точки, с экономической вообще не оправданно. Google/MS/HP/IBM/Oracle/Intel/AMD/Nvidia/..., да им бабла хватить чтоб раскрутить, но там экономисты посильнее нас будут, и на воздух бабла не бросят. Сервер - если только под управлением какого-то гипервизора, как атомарная ось с нулевым требованием к железу, потому как поддерживать RAID61 на SAS over 40Gb FC оно научится, лет через 200.
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	64. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+1 +/–
	Сообщение от Аноним (??) on 26-Авг-14, 03:16
	> куда и зачем можно  пристроить этот хайку. Ну как куда? Чесалка ЧСВ для тех кто хочет быть голубых кровей. Даже если это и подразумевает некромансию с gcc 2.95 и заботу о совместимости с окаменелым проприетарным шитом который даже в музее политехники не найдешь. > Десктоп - труп. Да не труп он, просто им будут пользоваться те кому он реально нужен. Ну там тем кто создает модели в кадах, занимается фотографией, 3D, кодит что-то и т.п. - в общем те кто использует компьютеры для созидания а не только потребццтва. Ты же не будешь кодить на планшете, правда? Да и какие-нибудь фотографии обрабатывать или в каде чертить там геморройно из-за поганых средств ввода. А птиц метать и фотки котиков вконтакте постить можно и с планшета какого-нибудь. > Ембеддед - ну да, и то, только с идейной точки, с экономической > вообще не оправданно. В эмбедед линь всех замял хотя-бы нормальной поддержкой железа. Никто не будет два года выписывать все драйвера под вон тот SoC когда есть уже готовые, с исходниками, под открытую систему. Вот все BSP с линухом. Ну еще ведроид на выбор на мощных камнях. > Google/MS/HP/IBM/Oracle/Intel/AMD/Nvidia/..., да им бабла хватить чтоб раскрутить, > но там экономисты посильнее нас будут, и на воздух бабла не бросят. Ну так если бы бросали на поддержку всякой муиты - этот список был бы другим. > оно научится, лет через 200. Вот такой вот нынче фантомас в очках на аэроплане. А для десктопа - там и просто драйвера GPU нормальные будут лет через 100. Как ты понимаешь, амд и нвидия не будут ради полутора кексов на всю планету в блобе прослойку кодить. А открытые дрова... см. другое сообщение, там похоже бсдшно солярные ретарды которые вообще не видели как открытый графический стек сделан, но рассказывают про то что в *nix графическая система лучше. П...ц как улучшено. В амдшном открытом драйвере фрибздюки содрали DRM+KMS из ядра 3.8 примерно. Как оно там работает и с каким ассортиментом железа - ну в общем понятно. А эти еще 5 лет будут допирать передрать драйвер у фрибздюков. Еще пять лет roundtrip time в внедрении фич.
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	101. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+1 +/–
	Сообщение от Аноном on 26-Авг-14, 20:53
	>> Десктоп - труп. > Да не труп он, просто им будут пользоваться те кому он реально > нужен. Ну там тем кто создает модели в кадах, занимается фотографией, > 3D, кодит что-то и т.п. - в общем те кто использует > компьютеры для созидания а не только потребццтва. Ты же не будешь > кодить на планшете, правда? Да и какие-нибудь фотографии обрабатывать или в > каде чертить там геморройно из-за поганых средств ввода. Он явно писал о том, что Хайку на десктопе не жилец. Just sayin'
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	129. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+/–
	Сообщение от Аноним (??) on 27-Авг-14, 11:20
	> Он явно писал о том, что Хайку на десктопе не жилец. Just sayin' В этом плане не соврал.
	Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

	138. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	–1 +/–
	Сообщение от rico (ok) on 27-Авг-14, 12:37
	Объясните, пожалуйства, почему он не жилец? Вот я сужу только по картинкам и здешним отзывам и что  же я вижу: - народ говорит, что отзывчиво; - народ говорит, что быстро и эффективно работает; - что-то про 80% ноутбуков; - на ютубах вижу менюшки с 100500 ассортиментом софта гнушного; Значит, оно не только взлетает, но и работает! Говорите, что нету софта? Так нету и под линух жеж. А вообще, мне нравится каноникал, именно они двигают линукс в широкие массы, попутно не забывая энтерпрайз. Выходит и этим хайкописателям не хватает своего Марка?..
	Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

	139. "Разработчики Haiku в штыки восприняли проект перехода на..."	+/–
	Сообщение от arisu (ok) on 27-Авг-14, 12:46
	> А вообще, мне нравится каноникал вот на этом мог и остановиться, остальной твой текст лишний.
	Ответить | Правка | ^ к родителю #138 | Наверх | Cообщить модератору

	154. "Разработчики Haiku в штыки восприняли проект перехода на..."	–1 +/–
	Сообщение от Аноним (??) on 28-Авг-14, 16:37
	> вот на этом мог и остановиться, остальной твой текст лишний. Сапопикал, кстати, попробовал привнести свою лепту в десктопы. Ну там их индикаторы (которые как бы не трэй) с менюхами программ. Замашки вазрослых энтерпрайзятников на кастомный десктоп, сделанный с исправлением ряда бестолковостей/так как хотелось корпорасам - у них имеются. Баг это или фича - второй вопрос, далеко не однозначный.
	Ответить | Правка | ^ к родителю #139 | Наверх | Cообщить модератору

	41. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+1 +/–
	Сообщение от Аноном on 25-Авг-14, 21:06
	Вопрос. А что особенного-то? Ну вырвиглазненько это да, ну шустро(у меня на ноуте с кедами линукс тоже шустрый, при том что проц по хуже и тама эффекты есть), ну ссд ускоряет запуск программ, плюс Гайки-то в чем? У них конечно интересная позиция, мол мы только на дескотпы ориентируемся(хомячковые надо полагать). CLI привествуют только разработчики и в финалке, как сказали, развивать не будут. Софта для создания/редактирования 3Д,2Д,звука,веба,бд нема и врядли кто-то портанет. Прикопаться к отсутствию софта практически нельзя ибо ориентация у них на других пользователей(только кроме гиков-то никто не юзает их ось), считай ось для браузера, видео/аудио проигрывания, аська, торрент, офис(хз какой чего может), архиваторы имеются и больше для счастья ничего не надо.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	68. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	–1 +/–
	Сообщение от Аноним (??) on 26-Авг-14, 04:02
	Сейчас кути портировали, а они то популярность набирают в среде разработки ПО..., вот и будет вас все что нужно..., вообще гайку было бы неплохо в производственных и медийных целях использовать, на то она и была на те времена нацелена на потребл..ство, всего и вся, между прочим первые планшеты были на BeOS!!!
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	108. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+/–
	Сообщение от Vkni (ok) on 27-Авг-14, 01:13
	> У них конечно интересная позиция, мол мы только на дескотпы ориентируемся(хомячковые надо > полагать). Да, хомячковые. Haiku - это призрак BeOS, которую разрабатывали на замену MacOS Classic. ;-) Т.е. на роль Mac OSX.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	130. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+/–
	Сообщение от Аноним (??) on 27-Авг-14, 11:22
	> Да, хомячковые. Haiku - это призрак BeOS, которую разрабатывали на замену MacOS > Classic. ;-) Т.е. на роль Mac OSX. А если посмотреть - как-то так вышло что рулят универсальные и масштабируемые системы. Которые от часов/мобилки до сервера. Несомненно, ASIC считающий SHA256 считает его лучше чем CPU и GPU. Но ни для каких иных целей его не примениишь. Поэтому ASICов продается во, а х86 процессоров - во. Хоть ASIC и долбит SHA256 лучше системного проца...
	Ответить | Правка | ^ к родителю #108 | Наверх | Cообщить модератору

9. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+1 +/–
Сообщение от burjui (ok) on 25-Авг-14, 13:12
Создаётся такое впечатление, будто разработка Haiku ведётся именно ради самой разработки. Как ей почти никто не пользуется сейчас, так это и будет продолжаться, пока не поменяются цели проекта. Быть не таким, как все - хорошо только в том случае, если ты чем-то лучше. Разработчики, на мой взгляд, признали, что без своего ядра Haiku не имеет смысла. То есть, вся эта "ориентированность на десктоп" - просто буллшит, раз их гуйня кому-то нужна только со специальным ядром. Впрочем, их дело. Хотят быть самобытными ради самобытности - пожалуйста. Главное, чтобы понимали, что без солидной поддержки оборудования у Haiku всегда будет более чем скромная аудитория, и желающих писать софт под такую ОС тоже найдётся немного.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	10. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	–3 +/–
	Сообщение от Аноним (??) on 25-Авг-14, 13:23
	> Разработчики, на мой взгляд, признали, что без своего ядра Haiku не имеет смысла. А по-моему, они наоборот — боятся, что если хайку-подобный интерфейс будет доступен на других ядрах, из их проекта убегут разработчики, потому как раз интерфейс в Haiku и есть самое главное.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	23. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	–1 +/–
	Сообщение от Аноном on 25-Авг-14, 15:31
	>> Разработчики, на мой взгляд, признали, что без своего ядра Haiku не имеет смысла. > А по-моему, они наоборот — боятся, что если хайку-подобный интерфейс будет доступен > на других ядрах, из их проекта убегут разработчики, потому как раз > интерфейс в Haiku и есть самое главное. Хайку подобный? В чем отличие от КДЕ или Е17 где точно также нажатием на мышку получаем иерархический список для выбора запускаемых программ, а в Е17 и лазанье по папкам(что дико удобно, да?)?
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	29. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+1 +/–
	Сообщение от sorrymak (ok) on 25-Авг-14, 16:36
	Хайку-подобный (т.е беосо-подобный) интерфейс уже давно есть. См. ZevenOS.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	38. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+1 +/–
	Сообщение от Аноним (??) on 25-Авг-14, 19:30
	А по моему, чтобы их понять, нужно быть в команде, сообществе, жить образом жизни #HaikuOS( #BeOS / #Zeta ) пользователя. И вообще, ИМХО больше движет этими людьми та искра и тот энтузиазм, что зажгла потрясающая производительность, гибкость и удобство, отзывчивость интерфейса BeOS... Плюс, более продвинутых задело, это размеры нативного софта, -что подчеркивает малую ресурсоёмкость, а так же файловая система, и размещение системных каталогов, - что почти ничего не стоило освоить обычному неандертальцу не тратя большое количество времени...
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	46. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+1 +/–
	Сообщение от Teocally on 26-Авг-14, 00:25
	> ...а так же файловая система, и размещение системных каталогов, - > что почти ничего не стоило освоить обычному неандертальцу не тратя большое > количество времени... Интересное у вас однако сообщество... )))
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	52. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+1 +/–
	Сообщение от Аноним (??) on 26-Авг-14, 00:52
	> образом жизни #HaikuOS( #BeOS / #Zeta ) пользователя. Лепить везде хэштеги - это нынче в основном образ жизни твиттерового хомячка. Хотя может быть вы про IRC в лучшем случае? > потрясающая производительность, гибкость и удобство, отзывчивость интерфейса BeOS... Странно что втирая про гибкость хотят положить на командлайн. > Плюс, более продвинутых задело, это размеры нативного софта, -что подчеркивает малую > ресурсоёмкость, И где этот нативный софт? > а так же файловая система, Ну, попробуйте ее плюсы vs существующих сегодня? :) > и размещение системных каталогов, - ...интересное полутора програмерам на планете... > что почти ничего не стоило освоить обычному неандертальцу не тратя большое > количество времени... Обычному неандертальцу вообще нефиг нос совать в системные каталоги - система целее будет.
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	60. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	–2 +/–
	Сообщение от pavlinux (ok) on 26-Авг-14, 02:19
	> этими людьми та искра и тот энтузиазм, что зажгла потрясающая производительность, гибкость и удобство, отзывчивость интерфейса ... Хочется тёплого лампового ассемблера - KolibriOS!!! Или её папа - МинетОС http://www.menuetos.net/download.htm Кстати, можно в новости 25.08.2014  0.99.71  Updates and improvements                      (httpc,ehci,picview,memcheck,menu,wallpaper,ohci,                       uhci,maps/streetview,icons,dhcp,freeform window,                       smp threads,smp init,onscreen keyboard,utf8 support                       tcp/ip,keyboard layouts:western,cyrillic,hebrew,greek)
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	69. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+/–
	Сообщение от Аноним (??) on 26-Авг-14, 04:05
	Когда я юзал менует то были времена флоповодов и дохлых веников), и то она умудрялась фризить!!! ... - даёшь менует разрабов агитировать на гайко девелопмент!!!)
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	131. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+/–
	Сообщение от Аноним (??) on 27-Авг-14, 11:25
	> то она умудрялась фризить!!! ... Так это нормально: I/O встало колом (а на флопповоде или дохлом венике это норма) -> простой и очевидный код будет до упора ожидать окончания I/O. А всякая асинхронщина, продвинутые планировщики и прочее - уже нифига не просто, и вообще.
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	110. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+/–
	Сообщение от Vkni (ok) on 27-Авг-14, 01:18
	> А по-моему, они наоборот — боятся, что если хайку-подобный интерфейс будет доступен > на других ядрах, из их проекта убегут разработчики, потому как раз > интерфейс в Haiku и есть самое главное. В "клятых X-ах" для создания хайку-подобного интерфейса нужно лишь написать оконный менеджер, да файловый менеджер. :-) А как написано в аннотации к Zeven OS, даже и писать ничего не надо, достаточно просто выбрать подходящую тему в одном из WM'ов Ubuntu. :-)
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	16. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	–1 +/–
	Сообщение от Аноном on 25-Авг-14, 14:37
	Так и есть "It's nice to see that the Linux kernel is flexible enough to find uses in so many cases, but I think there is some use in writing and finetuning our own kernel and building our own APIs on top of it. Where would be the fun otherwise?"
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	17. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+/–
	Сообщение от Аноним (??) on 25-Авг-14, 15:13
	Да наоборот же! "I've been through this before. So...when's the last time you heard of Syllable? Why do you think it's basically dead? One person wanted to sit the Syllable userland on top of the Linux kernel -Syllable Server. Almost every single developer left Syllable. But, I'll leave you to it. I'm done with this topic."
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	22. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+/–
	Сообщение от Аноном on 25-Авг-14, 15:26
	"BTW, there're far more impressive Unix hardware accelerated graphics stacks than what Linux is offering, so don't act as if this project would be receiving the Crown Jewels. I'm not ignorant of the Unix world. My background is Solaris & FreeBSD. I see this for what it really is -the Linux mindset that the Linux kernel should replace every other kernel on the planet because it's just that good. Well, it's ok, but it doesn't fit every case & you Linux guys need to get that through your heads. Until you show actual results, this is nothing more than an embrace & extend strategy -copied from Microsoft & implemented poorly." Вообще, если почитать переписку мнения там разделились, но для части народа Гайка просто для фана. Одна бинарная совместимость с Пчелой чего стоит, кому дался тот древний софт?
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	53. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+/–
	Сообщение от Аноним (??) on 26-Авг-14, 01:00
	> "BTW, there're far more impressive Unix hardware accelerated graphics stacks Бздюки и солярщики все-таки феерически упертые ДЛБ. Кто-нибудь, ткните этого ламака в тот факт что та же фряха перешла на *линевый* DRM+KMS, туда же и опенок идет. А солярис нынче вообще почти сдох стараниями оракла. > than an embrace & extend strategy -copied from Microsoft & implemented poorly." Этот лох не понял что Столлман крутой мужик и вообще-то сделал самораспостраняющуюся заразу, которая автоматически изводит паразитов и халявщиков, зачастую конвертируя их в симбионтов :). > Вообще, если почитать переписку мнения там разделились, но для части народа Гайка > просто для фана. Одна бинарная совместимость с Пчелой чего стоит, кому > дался тот древний софт? Да, вы правы: красивая работа на мусорный бак. Правда, видимо не все испытывают энтузиазм от участи кодить в /dev/null.
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	63. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	–1 +/–
	Сообщение от Аноним (??) on 26-Авг-14, 03:12
	> Этот лох не понял что Столлман крутой мужик и вообще-то сделал самораспостраняющуюся > заразу, которая автоматически изводит паразитов и халявщиков, зачастую конвертируя их > в симбионтов :). > > Да, вы правы: красивая работа на мусорный бак. Правда, видимо не все > испытывают энтузиазм от участи кодить в /dev/null. 294-й, вот без твоего авторитетного вонизма тут никак было не обойтись. Никто, кроме тебя, не укажет людям, что их жизнь и их любимое дело не стоят выеденного яйца. Не то что ты, повелитель N900, умеющий компилировать под ARM и даже раз в год соизволяющий отправить жалобу в чей-нибудь багтрекер. Куда до тебя ламерам, которые из-за своего любимого проекта становятся специалистами по USB, файловым системам, работе с кешами современных CPU и GPU... Все должны тут же послушать тебя, забиться по офисным каморкам и не отсвечивать. А, и ещё славить Столмана за воздух, которым он им позволяет дышать. Тьфу.
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

	65. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+2 +/–
	Сообщение от Аноним (??) on 26-Авг-14, 03:29
	> 294-й, вот без твоего авторитетного вонизма тут никак было не обойтись. Да я просто худею с такого игнорирования ФАКТОВ особо упертыми бздевыми сектантами. Рассказывать про супер-дупер графическую систему, при том что несколько лет просто клали на графику вообще, а когда UMS вынесли из драйверов, объяснив что разработчики намерены пользоваться DRM+KMS как подложкой, а возиться с окаменелым кодом UMS, который никто не поддерживает не собираются - тут в заду вспыхнул огонь и они пошли кой-как портировать KMS и DRM наконец. Отставая на несколько лет на ровном месте. То что мне показывали для радеонов - было на уровне ядра 3.8. А это значит что хардварного декодирования видео (UVD) нету, нормального управления питанием (DPM) нету, сколь-нибудь новые GCNы скорее всего работают как VGA адаптеры, etc. > любимого проекта становятся специалистами по USB, ...в рамках системы, работа над которой интересует только этих специалистов. А так стать специалистом в USB можно на порядок проще. Идешь на USB-IF и качаешь спеки. И изучай наздоровье. Таким макаром эффект от "изучения USB" будет намного лучше - концентрированные знания по теме вместо выколупывания из какой-то побочной вермишели. > файловым системам, И в чем это выражается? > работе с кешами современных CPU Это круто и все такое. > и GPU... И где у них нормальные драйвера этих самых GPU? Ну хоть сырые... > по офисным каморкам и не отсвечивать. С упомянутыми знаниями они и будут по офисным каморкам сидеть, эникеями. Потому что денег за все эти знания никто не готов дать и никакой ценности для окружающих такой спец не представляет, по большому счету. > А, и ещё славить Столмана за воздух, которым он им позволяет дышать. А без него - даже у юзеров гайки не было бы GCC. Даже окаменелого 2.95, прикиньте? Так что без Столлмана даже компилерная некромансия не получилась бы. > Тьфу. Да вообще, пришел, понимаешь, и всю малину романтикам работающим на мусорницу обоcpaл.
	Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

	31. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	–2 +/–
	Сообщение от Аноним (??) on 25-Авг-14, 16:50
	сейчас оно ничего бы не выйграло и с ядром линукс. Либо оно бы всталов огромный
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	115. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	+/–
	Сообщение от Аноним (??) on 27-Авг-14, 07:03
	ты просто не понял, без их ядра никакой ориентированности не получится, получится просто еще один линукс
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

33. "Разработчики Haiku в штыки восприняли проект перехода на ядр..."	–3 +/–
Сообщение от Resonance (ok) on 25-Авг-14, 17:14
Я за то, чтоб было доступно 2 ядра для выбора. Пользователям Linux - и больше пользователей и популяризация проекта, и программистов больше станет, а предприятиям (для интеграции во всякие телевизоры, чайники, роутеры...) ядро Haiku, лизензия MIT все таки
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

42. "Разработчики Haiku не приняли проект перехода на ядро Linux"	+1 +/–
Сообщение от fidaj (ok) on 25-Авг-14, 21:18
пусть ReactOS предложат перейти на ядро Linux... что уж там мелочиться...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	54. "Разработчики Haiku не приняли проект перехода на ядро Linux"	–3 +/–
	Сообщение от Аноним (??) on 26-Авг-14, 01:02
	> пусть ReactOS предложат перейти на ядро Linux... что уж там мелочиться... Не, для полного стеба надо чтобы гайка перешла на ядро реактоса. Тогда они смогут подать заявку в книгу рекордов Гинесса. Как проект находящийся в максимально возможной на этой планете ж...е - такое суперкомбо по безблагодатности никто не переплюнет, по любому :).
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	78. "Разработчики Haiku не приняли проект перехода на ядро Linux"	+2 +/–
	Сообщение от arisu (ok) on 26-Авг-14, 09:02
	> Не, для полного стеба надо чтобы гайка перешла на ядро реактоса. нельзя: тогда реакторовцам неоткуда будет брать код для работы с периферией. ну, типа USB, например.
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	132. "Разработчики Haiku не приняли проект перехода на ядро Linux"	+1 +/–
	Сообщение от Аноним (??) on 27-Авг-14, 11:29
	> пусть ReactOS предложат перейти на ядро Linux... что уж там мелочиться... Не в обиду реактосу, wine можно на практике пользоваться, а в Linux работает железо и прочее. Поэтому если надо ехать, а не шашечки - нарулить в пингвине вайн на порядок результативнее долботни с реактосом.
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

43. "Разработчики Haiku не приняли проект перехода на ядро Linux"	–1 +/–
Сообщение от paulus (ok) on 25-Авг-14, 21:52
А эта Haiku хоть чуток развивается, а то Version: R1/Alpha 4.1 Release date: November 14th, 2012
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	59. "Разработчики Haiku не приняли проект перехода на ядро Linux"	+/–
	Сообщение от kim (??) on 26-Авг-14, 01:40
	Еще как развивается - http://cgit.haiku-os.org/haiku/log/ http://www.haiku-os.org/guides/daily-tasks/updating-system http://www.linux.org.ru/tag/haiku
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	66. "Разработчики Haiku не приняли проект перехода на ядро Linux"	+/–
	Сообщение от Аноним (??) on 26-Авг-14, 03:33
	> Еще как развивается - Реактос тоже таким макаром 15 лет развивался. Правда, виндузоиды более тормозные - у них SVN в 2014 году.
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	67. "Разработчики Haiku не приняли проект перехода на ядро Linux"	+/–
	Сообщение от beos (ok) on 26-Авг-14, 03:59
	http://youtu.be/QEnMlnk4Ixc http://youtu.be/g7_cmk5xHOo http://haiku.uwolke.ru/repo/#Ru http://youtu.be/h3rg1RLAxGU http://youtu.be/MQqFO4OkPO0
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	93. "Разработчики Haiku не приняли проект перехода на ядро Linux"	+/–
	Сообщение от Xasd (ok) on 26-Авг-14, 17:49
	все эти программульки (и даже больше их) есть и на GNU/Linux .. ..вопрос в том -- наколько лучше (или хуже?) эти программульки работают в Haiku по сравнению с Linux-kernel? неужели в Haiku всё это более отзывчивее чем в Linux-kernel? неужели аппаратное 2D-видеоускорение (видеоэффекты оконного композитора, и проигрывание видеофайлов) в Haiku работает быстрее и менее ресурсоёмко чем в Linux-kernel? например, если сравнить Linux-kernel и Windows -- то тут всё ясно -- половина Linux-программ которые компилируются под Windows в итоге теряют часть своей функциональности. (Windows остаётся в проигрыше, относительно этих программ) какие есть перспективы у Haiku, относительно сокращения разрыва между Haiku и Linux-kernel? например Linux-системы в будущем перейдут: на btrfs, на Wayland, на systemd (имеется ввиду что systemd более углубится в свою роль, которую он выполняет работая поверх Linux-kernel) --- и разрыв между Haiku и Linux-kernel ещё больше увеличится! (а сейчас у Haiku есть покачто-ещё небольшое приемущество над Linux-kernel в том факте, что Haiku НЕ использует говнопротокол X11)
	Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

	116. "Разработчики Haiku не приняли проект перехода на ядро Linux"	+/–
	Сообщение от Аноним (??) on 27-Авг-14, 07:09
	может стоит сначала ознакомиться с предметом разговора и хотя бы один раз его запустить прежде чем писать всякий бред?
	Ответить | Правка | ^ к родителю #93 | Наверх | Cообщить модератору

	123. "Разработчики Haiku не приняли проект перехода на ядро Linux"	+/–
	Сообщение от arisu (ok) on 27-Авг-14, 10:11
	> может стоит сначала ознакомиться с предметом разговора и хотя бы один раз > его запустить прежде чем писать всякий бред? зачем? это у нас Иксперд. а настоящему индейцу^w Иксперду совершенно не обязательно разбираться в теме. даже, скорее, вредно.
	Ответить | Правка | ^ к родителю #116 | Наверх | Cообщить модератору

	70. "Разработчики Haiku не приняли проект перехода на ядро Linux"	+/–
	Сообщение от Аноним (??) on 26-Авг-14, 04:06
	а смысл от этой оси, если она может наступить на грабли - тролеводов?
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	84. "Разработчики Haiku не приняли проект перехода на ядро Linux"	+/–
	Сообщение от Нанобот (ok) on 26-Авг-14, 10:44
	волков бояться - в лес не ходить
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	80. "Разработчики Haiku не приняли проект перехода на ядро Linux"	+1 +/–
	Сообщение от arisu (ok) on 26-Авг-14, 09:05
	>> Еще как развивается - > Реактос тоже таким макаром 15 лет развивался. не таким. хайка вполне себе разрабатывается под хайкой, а реактору до этого как телеге до альфы центавра.
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	133. "Разработчики Haiku не приняли проект перехода на ядро Linux"	+1 +/–
	Сообщение от Аноним (??) on 27-Авг-14, 11:33
	> не таким. хайка вполне себе разрабатывается под хайкой, а реактору до этого > как телеге до альфы центавра. Валидный пойнт, однако. Тем не менее, почитав сообщение разработчика про юниксы и графические системы у меня возникло сомнение во вменяемости этого индивида, т.к. то что он вещает - не стыкуется с фактами чуть более чем никак...
	Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

	79. "Разработчики Haiku не приняли проект перехода на ядро Linux"	+/–
	Сообщение от arisu (ok) on 26-Авг-14, 09:02
	> А эта Haiku хоть чуток развивается развивается.
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

72. "Разработчики Haiku не приняли проект перехода на ядро Linux"	+/–
Сообщение от beos (ok) on 26-Авг-14, 04:21
Кстати, насчет gcc2  - так обозначена гибридная версия ОС, в которой работают бинарники, скомпилированные как 2 , так и 4 gcc http://www.haiku-os.org/guides/daily-tasks/updating-system PS чистой gcc2 гайки нету уже...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	81. "Разработчики Haiku не приняли проект перехода на ядро Linux"	–1 +/–
	Сообщение от Аноним (??) on 26-Авг-14, 09:39
	gcc2 - для запуска тех самых тёплых ламповых программ, которых теперь не пишут. Эх, времена былые, кодеры удалые..
	Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

83. "Разработчики Haiku не приняли проект перехода на ядро Linux"	+/–
Сообщение от Нанобот (ok) on 26-Авг-14, 10:43
вот что важнее: сохранение самобытности или поддержка оборудования?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	85. "Разработчики Haiku не приняли проект перехода на ядро Linux"	+/–
	Сообщение от arisu (ok) on 26-Авг-14, 10:57
	> вот что важнее: сохранение самобытности или поддержка оборудования? в данном случае — сохранение самобытности.
	Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

	134. "Разработчики Haiku не приняли проект перехода на ядро Linux"	+1 +/–
	Сообщение от Аноним (??) on 27-Авг-14, 11:35
	> в данном случае — сохранение самобытности. Реактос тоже сохраняет вон. В результате проще запустить wine в линуксе, если на шашечки пофиг, а вот ехать приспичило и как-то так вышло что одной из точек маршрута оказалась маздайная программа без аналогов...
	Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

	151. "Разработчики Haiku не приняли проект перехода на ядро Linux"	+/–
	Сообщение от Vkni (ok) on 27-Авг-14, 17:06
	> Реактос тоже сохраняет вон. Только зачем? Прообраз Реактоса живее всех живых, а прообраз Haiku - BeOS давно в могиле. Поэтому самобытность, которую хранит Реактос, и без него никуда не пропадёт, а вот с Гайкой всё совсем не так.
	Ответить | Правка | ^ к родителю #134 | Наверх | Cообщить модератору

	153. "Разработчики Haiku не приняли проект перехода на ядро Linux"	+/–
	Сообщение от Аноним (??) on 28-Авг-14, 16:29
	> Только зачем? Прообраз Реактоса живее всех живых, Только бинарный - без исходников. И документация на кернелмод - такая, чтобы конкуренты не догадались. Так что толку то с прообраза. А прообраз гайки - дохлая лошадь, однако. По каким причинам она издохла - второй вопрос. > никуда не пропадёт, а вот с Гайкой всё совсем не так. Ну вон CP/M что-то тоже не развивается. Желающим поработать на мусорницу есть над чем подумать.
	Ответить | Правка | ^ к родителю #151 | Наверх | Cообщить модератору

	159. "Разработчики Haiku не приняли проект перехода на ядро Linux"	+/–
	Сообщение от Vkni (ok) on 29-Авг-14, 16:56
	> Только бинарный - без исходников. И документация на кернелмод - такая, чтобы > конкуренты не догадались. Так что толку то с прообраза. Для пользователей пробраза и, главное, перспективных пользователей(!) Реактоса исходники не важны. Т.е. ребята строят открытую ОС для тех, кто открытость и свободность в грош не ставит - типичные "свинья в апельсинах". > А прообраз гайки - дохлая лошадь, однако. По каким причинам она издохла > - второй вопрос. Да, именно поэтому есть музейный смысл делать копию, раз дохлая. Вот Windows сдохнет, будет музейный смысл делать копию. > Ну вон CP/M что-то тоже не развивается. Желающим поработать на мусорницу есть > над чем подумать. FreeDOS же.
	Ответить | Правка | ^ к родителю #153 | Наверх | Cообщить модератору

104. "Разработчики Haiku не приняли проект перехода на ядро Linux"	+/–
Сообщение от dRiZd on 27-Авг-14, 00:37
Мда, BeOS в свое время была замечательная система. Но политика Be Incorporated довела ее "до ручки". Даже сейчас смотрю на своего старичка BeBox (4x Power PC 604) с ностальгией. Даже Dano с его "кривым" Bone был просто блеск! Кстати, BeBox у меня работал в качестве почтового и web-сервера (естественно домашнего) до 2008 года, пока не заменил его на Mac mini (как более компактное и бесшумное решение), а потом и Mac mini Server. Пожелаем ребятам из Haiku удачи! Пусть будет больше ОС, всяких - по крайней мере у нас будет выбор!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	105. "Разработчики Haiku не приняли проект перехода на ядро Linux"	+1 +/–
	Сообщение от fidaj (ok) on 27-Авг-14, 00:49
	> Мда, BeOS в свое время была замечательная система. > Но политика Be Incorporated довела ее "до ручки". ничего не напутано случайно? потому что я читал - что это Intel & MS довели до ручки Be
	Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

	117. "Разработчики Haiku не приняли проект перехода на ядро Linux"	+/–
	Сообщение от Аноним (??) on 27-Авг-14, 07:12
	>> Мда, BeOS в свое время была замечательная система. >> Но политика Be Incorporated довела ее "до ручки". > ничего не напутано случайно? потому что я читал - что это Intel > & MS довели до ручки Be именно так, корпорация зла сделала свое дело
	Ответить | Правка | ^ к родителю #105 | Наверх | Cообщить модератору

	135. "Разработчики Haiku не приняли проект перехода на ядро Linux"	+/–
	Сообщение от Аноним (??) on 27-Авг-14, 11:37
	> именно так, корпорация зла сделала свое дело Если проект легко доводится до ручки - ему это не в плюс.
	Ответить | Правка | ^ к родителю #117 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема