Большинство разработчиков свободной операционной системы 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.me/opennews/art.shtml?num=40449
Хм, и где же там "в штыки"? Адекватыне ответы в приветливой манере, с уважением.
Адекватными ответами в приветливой манере, с уважением
дали понять, что им не нужно.
А что вы ожидали от горстки психопатов, которые в 2014 году с gcc 2.95 возятся? Приступов здраворо смысла чтоли? Они с самого начала нацелились ударно повкалывать на мусорный бак.
ну да, запишем также к психопатам и разработчиков dosbox, freedos и множество других
У dosbox'а & Co возможно некоторое количество "real world" заказчиков, т.к. 286 для имбеда в "странах третьего мира" вполне годится (и у многих есть технологии производства). Куда девать beos в нашем непростом мире...
> есть технологии производства). Куда девать beos в нашем непростом мире...Скорее, применяется для всяких там древних касс и прочего, которые выбросить жалко, т.к. работает вроде и дело делает. И для всяких там прошивалок BIOS/прошивок, etc.
А смысла производить 80286 на данный момент просто нет. Кому надо мелкое, маложручее и простое - могут ARM взять, так что даже нонеймовые китайцы его шлепают по цене песка под ногами. А если жаба давит лицензировать - ну ок, взять OpenRISC какой-нибудь...
У досбокса и фридоса есть некие реально практикующиеся применения. А сабж просто онaнизм в чистейшем, эталонном виде. Потому что в реальном мире найти хоть что-то завязанное на окаменелую проприетарь из не взлетевшей операционки - невозможно даже под микроскопом.
А что за чудо-технологии есть в Haiku?
Такие, что даже без родного ядра кому-то нужны?
Программы выполняются не как отдельные процессы, а как потоки. Многопоточная обработка всего и вся.
это уникальная фича?
> Программы выполняются не как отдельные процессы, а как потоки.Господи, что бы это могло значить?
>> Программы выполняются не как отдельные процессы, а как потоки.
> Господи, что бы это могло значить?Я думаю, кооперативная многозадачность :) Здравствуй, обязательный Thread.yield()! :)
> Программы выполняются не как отдельные процессы, а как потоки. Многопоточная обработка всего и вся.а чем Потоки (Нити, Threads) отличаются от Процессов --- с точки зрения ядра?
а-то ведь так можно и про Linux-kernel сказать что с точки зрения ядра там все программы выполняются как Нити :-)
ядро Linux-kernel ведь не отличает Нити от Процессов.
Нету нитей, нету процессов, есть таски :)
Нет. Есть контекст выполнения! :D
Всё бренно, кроме потока электронов в проводниках.
> Нету нитей, нету процессов, есть таски :)Нету нитей, нету процессов. Все суть LWP, просто у некоторых LWP один, а у некоторых - несколько :).
Не отличало. С некоторых пор разница есть. Единицей планирования является поток, есть различия при порождении процесса/потока.
> Программы выполняются не как отдельные процессы, а как потоки. Многопоточная обработка
> всего и вся.Как в solaris. Там единицей планирования является сущность kernel thread, некоторые
из которых предназначены, выставляя регистры в значения, соответствующее определённым контекстам,
тратить свои кванты времени на исполнение кода из memory image загруженных программ
ползовательского уровня. Причём код определённого иммаджа, могут в разное время исполнять
разные kernel threads, не обязательно один и тот же. Так что можно с уверенностью назвать
сoляру полностью тредовой. В хайке велосипед пилят, короче.
Ну а в линухе любой процесс или поток реализован через вызов clone2, у которого очень приличный список параметров настройки контекста выполнения — от firk'a (который через него же реализован) до легковесных процессов и (легковесных же) потоков.Ну нет больше разницы между потоком и процессом как таковой.
Есть только разница в объёме информации сохраняемого/восстанавливаемого контекста выполнения при переключении задач после появления коу и ммэп.
> Ну а в линухе любой процесс или поток реализован через вызов clone2,
> у которого очень приличный список параметров настройки контекста выполнения — от
> firk'a (который через него же реализован) до легковесных процессов и (легковесных
> же) потоков.
> Ну нет больше разницы между потоком и процессом как таковой.
> Есть только разница в объёме информации сохраняемого/восстанавливаемого контекста выполнения
> при переключении задач после появления коу и ммэп.Ну а в линуксе, и clone, и fork вызывают do_fork, которая создаёт отдельную
task_struct, и пихает её планировщику. Именно с ними планировщик и работает,
это и есть единица планирования. Каждая такая таска содержит весь набор, куда входят
контексты потока исполнения, то есть регистры, счётчик команд, содержит своё, отдельное
от других тасков, виртуальное пространство памяти, содержит набор IO дескрипторов и пр.
вещи первой необходимости. У разных тасков, относящихся к одному и тому же процессу исполнения
пользовательской программы, или являющиеся кернель тредами, таски по содержанию идентичны,
и отличаются только инфой, относящиейся
к потоку исполнения, но IO дескрипторы, сруктуры виртуальной памяти и прочие вещи у них общие, но
при этом, это всё таки разные таски и планировщик, переключаясь между ними, производит
перезагрузку в соответствии с данными этой таски. Говорят что в линуксе поток и процесс одно
и то же, это не верно, в линуксе всё есть процесс, то есть каждый таск имеет полное окружение процесса,
но некоторые из них могут отличаться только регистрами контекста потока. Про такие говорят что это потоки одного процесса, но по мне так это некорректное сравнение.
«Ядро 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, и пихает её планировщику»?…не раскрыта ☺)
> Флаг 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. То есть планировщик по тику таймера
переключает только кернель потоки, а в них уже может осуществляться планирование исполнения задач пользовательского уровня и само исполнение.ЗЫ фразу комерческий булшит отсюда выкинуть подальше, она вообще не в тему, даже если больше сказать нечего.
Сразу говорю, прочитал только первые пару предложение. Дальнейшее смысла читать (пока? х/з) не вижу.
1. kernel_thread есть не только в соляре (см. выше)
2. обслуживается тем же do_fork (см. выше)
3. сам fork — это только частный случай вызова на выволнение do_fork (см. выше)
4. системные вызовы для этих НЕ_частных случаев таки тоже есть (см. выше). Не fork'ом единым, как говориться.
5. всё это знает и умеет pthread (через который кстати прозрачно и реализованы стандарты С/С++11 и 14 и в гцц, и в шланге)
6. Вы слишком много трыдите не по-существу. Книжки по соляре (коих было прочитано не мало) — этого мало, чтобы гнуть пальцы.
7. роль COW и mmap всё ещё не раскрыта. При этом они фактически сводят к нулю разницу между потоками и процессами с точки зрения производительности.
Зыж
Прочитал ещё пару предложений — ну полный бред!
>И раз отдельная 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).в общем не читайте уставревших книжек по соляре. в них в лучшие то годы половина текста была на тему «какие мы лучшие», даже не утруждаясь на элементарное ознакомление с «оппонентами».
> Не? Не понятно?
> в памяти. Их банально нет нужды куда-то перезагружать вообще. Зачем это
> надо делать? (И зачем этот бред мне нужно комментировать?)
> И опять же напоминаю, есть 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...
Да. В линуксе управлением переключения задач занимается шедулер.
Вариантов которого может быть несколько.
И?
Что сказать то хотели? Как извернуться?
У вас каша в голове.
> Да. В линуксе управлением переключения задач занимается шедулер.
> Вариантов которого может быть несколько.
> И?
> Что сказать то хотели? Как извернуться?
> У вас каша в голове.А у Вас бульон в голове. Повторю ещё раз смысл своих окровений. Единицей планирования
в солярисе является сущность, содержащая информацию с контекстом потока исполнения, и не более, работающего в окружении пространстве ядра.
Единицей планирования в линуксе, независимо от типа планировщика, является сущность, содержащая все атрибуты процесса,
набор данных, которые в совокупности называются окружением процесса. Поэтому шедулер в солярисе управляет потоками ядра,
шедулер в линуксе процессами. Какие-то из них, как, например, так называемые кернель треды, или разные потоки
одного процесса исполнения пользовательской задачи, могут иметь общие данные окружения процесса,
то есть поля из task_struct каждой из них указывают на одни те же общие массивы и структуры.
Ферштейн?
Для доказательства буду приводить ссылки в исходники, так что дерзайте.
> А у Вас бульон в голове.Вы — идиoт. И вот почему:
> Повторю ещё раз смысл своих окровений. Единицей планированияв солярисе является сущность, содержащая информацию с контекстом потока исполнения, и не более, работающего в окружении пространстве ядра.
И что? ☺
Кто с этим спорил то? Вот только профита от этого на современном оборудовании нет. (Соляра на x86_64 тот ещё тормоз по сравнению с linux'ом — с этом то вы спорить не будете?)
> Поэтому шедулер в солярисе управляет потоками ядра, шедулер в линуксе процессами.Брехня. Задачами.
К коим относятся и kernel_thread, которые тоже есть в линуксе (уже и пруфы давал, бесполезно ☹) и создать такие вы вполне можете тем же clone(2).
> содержащая все атрибуты процесса, набор данных, которые в совокупности называются окружением процесса.Полнейший бред. Вы путаете контекст выполнения с окружением процесса.
Неужели вы думаете, что в соляре нет окружения процесса? Вау! Это что-то новенькое в никс-устройстве.зыж
> Ферштейн? Для доказательства буду приводить ссылки в исходники, так что дерзайте.Ну конечно! Вместо обоснования проще извернуться и сказать что вот этот кусок кода лучше вот этого (не понятно чем), прикрывая своё полное невежество.
Кстати (и я так могу ☺!) Вот kernel_thread — http://lxr.free-electrons.com/source/kernel/fork.c#L1648
Можете хоть обсоздаваться потоками ядра.
> Можете хоть обсоздаваться потоками ядра.Повторю ещё раз, в линуксе и 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, а не в планировщике по тикам таймера.
Разницу между линуксовой схемой уловили?
> Повторю ещё раз, в линуксе и fork, и clone, и kernel_threadсоздают одну и ту же сущность планирования........
Ты не исправимый дурак.
См. выше пруфы.зыж
Ну ладно бы переключение контекстов вспомнил.
Нет жеж.
Я искренне жалею о потерянном времени (дальше вообще чушь. Ты хоть понимаешь вообще о чём говоришь? Пичалька. Ещё один долбень.)Ззыж
Сори за мой французкий. Но по другому никак. Враньё будет.
> А что за чудо-технологии есть в Haiku?
> Такие, что даже без родного ядра кому-то нужны?Очень хороший десктопный планировщик, своя файловая система.
> Очень хороший десктопный планировщик, своя файловая система.лучше планировщик и fs -- чем на Linux ?
а как проверить смогли это? :-)
Linux он ведь на практике, а Haiku в теории только :)
Десктопная ОС должна моментально реагировать на ввод пользователя независимо от того, чем и как она загружена. Линукс в этом отношении работает неудовлетворительно. Как с этим в Хайку не знаю, но пусть лучше делают свое ядро, так есть хоть какая-то надежда на что-то лучшее.
> Линукс в этом отношении работает неудовлетворительно.переключился в VT. нажал кнопку на клавиатуре — сразу появилась буква. «ещё лучше» — это уже телепатия.
> переключился в VT. нажал кнопку на клавиатуре — сразу появилась буква. «ещё
> лучше» — это уже телепатия.Да, но в Линуксе это только тогда, когда ресурсов компа почти "бесконечно много" - для отрисовки буквы в VT достаточно Пентиума, а у тебя машина на 3 порядка более быстрая. Если ресурсов будет относительно нехватать, тормоза появятся и в терминале (и я неоднократно такое видел).
Гайка же значительно более "десктопная" система - она и на слабом компьютер с высокой нагрузкой не даёт лагов. Просто при нагрузке появляется ощущение, что система равномерно замедляется.
Проблема Гайки в том, что в ней "нет Хов" - есть прибитый гвоздями интерфейс, который где-то удобен, но по большей части - нет. Под Хами есть быстрый красивый WindowMaker, есть требующий обучения удобнейший i3, есть Enlightenment для желающих крутого, есть KDE для непритязательных и GNOME для любителей странного. А тут, как и на Windows, как и на OSX - "слушайте ваши Валенки".
>> переключился в VT. нажал кнопку на клавиатуре — сразу появилась буква. «ещё
>> лучше» — это уже телепатия.
> Да, но в Линуксе это только тогда, когда ресурсов компа почти "бесконечно
> много"эвона как… видать, на 386-х по часу ждали, пока буква появится.
> Если ресурсов будет относительно
> нехватать, тормоза появятся и в терминале (и я неоднократно такое видел).никогда не видел.
и это… я именно про VT речь веду. потому что изначально речь шла про линукс, а ядро ведь окромя VT ничего больше и не умеет. ну, serial там ещё, такое.
> эвона как… видать, на 386-х по часу ждали, пока буква появится.Во времена 386-х не было framebuffer'а. Поэтому буквы там именно этим способом не появлялись. А на Pentium'ах framebuffer ощутимо тормозил по сравнению с текстовым режимом, правда проявлялось это в распечатках на экран больших файлов.
> никогда не видел.
Поздравляю. У меня бывало, что диск и память заняты и консольная программа не может даже отрисоваться по какой-то причине.
> и это… я именно про VT речь веду. потому что изначально речь
> шла про линукс, а ядро ведь окромя VT ничего больше и
> не умеет. ну, serial там ещё, такое.Тем не менее, планировщик сидит в ядре. И если он, когда тебе не хватает ресурсов машины, тормозит не, скажем Gimp, а, скажем, компилятор, ты видишь, что машина "отзывчива". Если же планировщик тормозит ту программу, с которой ты прямо сейчас работаешь, то ты видишь лаги.
Т.о. от планировщиков ядра зависит очень многое в ощущении "тормознутости" компьютера.
>> эвона как… видать, на 386-х по часу ждали, пока буква появится.
> Во времена 386-х не было framebuffer'а.у меня его тоже нет, например.
>> никогда не видел.
> Поздравляю. У меня бывало, что диск и память заняты и консольная программа
> не может даже отрисоваться по какой-то причине.framebuffer? кажется, я нашёл, в чём проблема…
> framebuffer? кажется, я нашёл, в чём проблема…Да, послать 1 байт для отрисовки 1 буквы проще и быстрее.
Проблема только в том что 80х25 на моем мониторе выглядит как первая строчка на приеме у окулиста :). Под другие реалии делалось...
> Если же планировщик тормозит ту программу, с которой ты прямо сейчас работаешь, то ты видишь лаги.что должен быть за такой "волшебный" планеровщик, который должен телепатической магией понимать какую программу нужно для пользователя "убыстрить" а какую программу "замедлить"?
если система тормозит -- то значит она тормозит ВСЯ -- и планировщик это не исправит.
ты открыл видеоролик на заднем фоне, архивируешь файлы, и одновременно что-то печатаешь в документе. откуда планировщик узнает какую из этих трёх программ нужно "замедлить"?
всё что можно сделать -- это лишь небольшие оптимизации на уровне user_space. например файловый манагер (да, да, который работает в user_space) должен помечать свои служебные файловые процессы как низкоприоритетные (ionice).
но даже и это является спорным решением (потому что сфигали копирование файлов это низкоприоритетный процесс -- именно в обязательно порядке? в каких-то случаях копирование файлов это весьма приоритетная задача).
> ты открыл видеоролик на заднем фоне, архивируешь файлы, и одновременно что-то печатаешь
> в документе. откуда планировщик узнает какую из этих трёх программ нужно
> "замедлить"?Раньше это называлось Active Window Boost. Натурально, приложение, чьё окошко сейчас в фокусе, на некоторых [неназываемых] системах получало ощутимое увеличение приоритета. Впрочем, те системы давно сдохли в страшных муках и уже даже вонять перестали.
> Раньше это называлось Active Window Boost.Это лишь одна из эвристик.
>> ты открыл видеоролик на заднем фоне, архивируешь файлы, и одновременно что-то печатаешь
>> в документе. откуда планировщик узнает какую из этих трёх программ нужно
>> "замедлить"?
> Раньше это называлось Active Window Boost. Натурально, приложение, чьё окошко сейчас в
> фокусе, на некоторых [неназываемых] системах получало ощутимое увеличение приоритета.
> Впрочем, те системы давно сдохли в страшных муках и уже даже
> вонять перестали.MacOS/IOS уже сдохла? И даже вонять перестала?
Когда я в Блендер ставлю что-то симулироваться или рендерю(на ЦПУ), то спокойно серфю нет без какого либо дискомфорта или смотрю фильмы в 1080р(на ЦПУ не ГПУ). Пару раз бывало что видео на долю секунды приторможивалось. Вы таки хотите сказать, что Гайка отиграет лучше в этой ситуации? Тут чудес не бывает, либо рендерить будет дольше либо идеальная картинка при просмотре фильма.
> Вы таки хотите сказать, что Гайка отиграет лучше в этой ситуации? Тут чудес не бывает, либо рендерить будет дольше либо идеальная картинка при просмотре фильма.Я на Блендере ничего никогда не делал, а вот в ситуации, когда что-то компилируется без (nice -n 19), Гайка у меня получалась значительно отзывчевее, чем Linux. Вообще, даже на древней машинке (P4), на которую я как-то ставил Гайку, никаких лагов не было. При нагрузке просто проседает общая производительность - как будто частота уменьшается в 1.5 раза или в 2. Но отклик на действия пользователя всегда быстр, как будто компьютер не загружен.
А вот под Linux'ом или, ещё более выпукло, под Windows при запуске фоновых задач появляются небольшие лаги.
----------------------------
Разумеется, чудес не бывает - если одновременно запущено две задачи (фоновая и интерактивная), полностью сжирающие ресурс компьютера, чтобы дать быстрый отклик пользователю, нужно отдать на время этот ресурс целиком интерактивной задаче. Фоновая задача, разумеется, притормаживается.Но, как учат нас шутеры, интерактивная задача должна дать ответ за примерно 1/60 секунды, дальше идёт ожидание действий пользователя, и ресурс компа можно отдать целиком фоновой задаче. Конечно, фоновая притормозится на эту 1/60 секунды, но для неё это не важно - она в любом случае работает значительно дольше.
Поэтому планировщик в идеале должен различать 2 класса задач: фоновые и интерактивные. Интерактивным нужно выдавать много ресурсов на короткое время, а фоновые в этот момент притормаживать. Тогда пользователь будет видеть, что компьютер как бы "не загружен". Это "десктопный" планировщик, для серверов он не подходит.
Планировщик Гайки строился по образу и подобию планировщика BeOS, сделанного специально для десктопов, с учётом опыта UNIX. Поэтому разработчики BeOS сумели этот момент учесть.
> что-то компилируется без (nice -n 19), Гайка у меня получалась значительно
> отзывчевее, чем Linux.Если уж мы о компиляции, я как раз в xonotic иногда играю если вломак ждать большую пересборку, размером с линевое ядро. ЧСХ, я даже не замечаю что в фоне make с -j 8 вкалывает - отловить завершение компила можно разве что по прекращению миганию LEDа харда :). Наверное я что-то делаю не так...
> Наверное я что-то делаю не так...Наверное, от машины что-то иногда зависит. :-)
голословная брехня.
как пример — мэнеджер задач в том же вантузе фиг вызовешь при достаточной нагрузка.
или например блэндер (на добрую половину на питоне написан. может больше) и в вантузе, и в маке даже визуально гораздо менее отзывчевее (и тормознее), чем в линухе.Любой портированный софт имеет приоритетную платформу, где он работает отзывчевее.
Всё определяется качеством оптимизации софта для на целевой платформе. Вот и всё.
> голословная брехня.
> как пример — мэнеджер задач в том же вантузе фиг вызовешь при
> достаточной нагрузка.Это потому, что планировщик ЦП и планировщик IO написаны без учёта десктопности. Иначе бы они отдали больше приоритета запуску этого менеджера.
нет такого понятия «десктопность».
и на таком уровне прохвисиананизма мне обсуждать что-либо не интересно.поэтому первое что я и написал — брехня.
> нет такого понятия «десктопность».
> и на таком уровне прохвисиананизма мне обсуждать что-либо не интересно.
> поэтому первое что я и написал — брехня.произведение не читал, но автора осуждаю...
Вот именно. Я как раз об этом.
> Как с этим в Хайку не знаю, но пусть лучше делают свое
> ядро, так есть хоть какая-то надежда на что-то лучшее.В Гайке с именно этим очень хорошо.
> Очень хороший десктопный планировщик,При том нормально инструментированных метрик мы видимо не дождемся, выслушивая рассказы о том как все звиздато, которые ничем не подкреплены.
> своя файловая система.
Своя файловая система нынче есть у каждой собаки. Проблема то не в том чтобы СВОЯ файловая система. А в том чтобы ХОРОШАЯ. При том не по меркам ДВАДЦАТИЛЕТНЕЙ давности а СЕЙЧАС. А желательно еще и "чем-то лучше чем у остальных". Иначе нафига на это прорву ресурсов сливать, кроме прокачки NIH синдрома?
> При том нормально инструментированных метрик мы видимо не дождемся, выслушивая рассказы
> о том как все звиздато, которые ничем не подкреплены.Нормально инструментированных десктопных метрик я нигде не видел.
> Своя файловая система нынче есть у каждой собаки. Проблема то не в
> том чтобы СВОЯ файловая система. А в том чтобы ХОРОШАЯ.Она своя в том смысле, что не POSIX. Т.е. некоторая попытка выйти за идеологию UNIX.
> Нормально инструментированных десктопных метрик я нигде не видел.Я видел, вокруг и около пингвинов тулзы типа latencytop.
Но вообще-то кому латенси не пофиг - на linuxcnc там вон рубка в микросекундных диапазонах. При том у них померяны времена отклика, с точностями в районе наносекунд, т.к. им оно надо - их некие гарантии насчет времени парят, знаете ли, при управлении промышленным барахлом. Так что пи...ж про отличную отзывчивость - это круто и все такое, но без инструментированных метрик - это именно пи...ж. И кстати обычно низкая латентность сажает производительность. Т.к. в целом долбить данные большими порциями и не переключать контексты - быстрее.
> Она своя в том смысле, что не POSIX. Т.е. некоторая попытка выйти
> за идеологию UNIX.Помнится первые версии таскали PE EXE и были похожи на эдакий виндус. А потом городили всякие костыли и подпорки.
В результате по состоянию на сейчас это превратилось в развлекуху для каких-то некрофилов которые никак не могут выкинуть окаменевший gcc 2.95. На поддержку этого окаменелого шита явно уходит время и силы, которые можно было бы потратить более результативно. Просто операционку надизайнили другие, а этот сброд элементарно не смеет взять на себя ответствненость за систему и посметь что-то там переработать или улучшить. Или хотя-бы просто выбросить совсем уж окаменелые компоненты.
юзер, ты неправ.
> юзер, ты неправ.А как насчет нормальных аргументов? :)
А то в этих самых шутерах, про которые Vkni бла-бла развел, с практической точки зрения... ну вон в том же xonoitc например, я как-то без проблем попадаю из nex (мощная railgun-подобная пушка) через полкарты в вон те 20 пикселей которые еле видно, при том быстрее чем они подстрелят меня из такой же штуки. Это требует сделать быстрые и плавные движения, с идеальной точностью. И уж ясен фиг, любой лаг в момент такого движения все факапит: это сочетание скорости "грубого" наведения и ювелирной точности, чтобы быстро прицелиться, но - не промазать. До кучи это 2560х1400, на открытом драйвере, с настройками high.
Как раз нежданно-негаданно натянул толпу народа в DM, на большой карте где спрятаться негде, в основном как раз nex-ом, по принципу "кто первый выстрелит и не промажет" :). Были бы у меня лаги - фиг с два я бы обставил толпу игроков, в т.ч. ряд опытных и опасных.
Единственное что я использую low latency сборки ядер (за основу взят конфиг убунтуйского -low-latency ядра 3.16). Там что-то сделано на предмет прерывания работы в том числе и ядра, но если честно - я без вкуривания конфига черта с два их отличу. Вообще, основное время реакции привносит или сеть, или если там все хорошо - тогда сам человек. То-есть на свежую голову я могу всем всыпать :). А вот если я сонный - без ведра вазелина на сервера шутеров лучше вообще не соваться. Натянут. Так что наибольшее влияние на лаг я бы отдал ... уровню мозговой активности. Как минимум с моей конфигурацией железа и софта оно вот так: сильнее всего зависит от состояния игрока.
>> юзер, ты неправ.
> А как насчет нормальных аргументов? :)ты серьёзно ожидаешь, что я буду спорить с обзыванием «сбродом»? O_O
> ты серьёзно ожидаешь, что я буду спорить с обзыванием «сбродом»? O_OС этим бесполезно спорить. Нормальное руководство проектом или уж есть и тогда смеет брать штурвал на себя, или нет - и тогда получаются реактосы и гайки, жалкие ripoff с того что разработано не ими. А они не смеют ничего покрутить и являются жалкими лакеями чужого дизайна. Ничего толком не решая. Апофеозом такого лакйства становится использование GCC 2.95 в 2014 году и прочие непотребства.
вот ты опять пытаешься говорить о том, в чём не даёшь себе труда разобраться. ну, то есть, спорить в принципе бессмысленно, потому что ты опять выстроил у себя в голове какой-то образ и проецируешь его наружу.
> ты опять выстроил у себя в голове какой-то образ и проецируешь его наружу.Оно конечно да, но: если бы этот образ не соответствовал действительности - граждане бы давно забыли про gcc 2.95. Он апстримом не поддерживается много лет, так что труп стюардессы давно пора оставить в покое.
так не используй, никто же не заставляет. одна из целей хайки — поддерживать запуск старого биосного софта. ну, вот такая вот цель. для этого и держат. не хочешь — выкинь нафиг и пользуйся только тем, что уже напилили под новую.
Самобытность и независимость, которые дороже практической применимости в сто крат.
> Самобытность и независимость, которые дороже практической применимости в сто крат.Это да, это важно - лучше быть чукчей с варганом, чем чукчей-диджеем.
> Самобытность и независимость, которые дороже практической применимости в сто крат.Ну тогда победителем объявляются те кто делает это в ластах и противогазе, стоя, в гамаке.
Цитата с ЛОРа
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 системного программирования.
Помимо этого, слышал что качество кода в проекте очень высокое, можно читать на ночь.
и всё это радостно перекрывается одним недостатком: C++. нет, не столько самим языком, сколько отсутствием для C++ стандартизованного ABI и стандарта на name mangling. в итоге библиотеки от разных плюсовых компиляторов друг с дружкой не дружат. и хайка вынуждена таскать с собой gcc2. и обновление компилятора до новой мажорной версии, например (положим, ребята таки забьют на старый закрытый софт) — это так любимый школогентоводами пересбор всего мира, только ещё геморройней.вот поэтому хайка — со всеми её хорошими идеями — так и будет маргинальщиной.
вот так C++ загубил ещё один перспективный проект.
> и всё это радостно перекрывается одним недостаткомДА.
> вот поэтому хайка — со всеми её хорошими идеями — так и
> будет маргинальщиной.Не только поэтому.
> Не только поэтому.не будем заниматься казуистикой. причин, конечно, много, не все из них инженерные и всё такое. но C++ — один из оооочень весомых жерновов.
> не будем заниматься казуистикой. причин, конечно, много, не все из них инженерные
> и всё такое. но C++ — один из оооочень весомых жерновов.Ещё и устарело всё, в том числе и граф. оболочка. Поэтому есть смысл рассматривать Haiku как музей идей BeOS. ;-) Отсюда, кстати, следует, что самобытность - это самое главное в Haiku.
Цитата с ЛОРа
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 системного программирования.
> 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. Некрофилии и х-вого управления проектом.
Копаться с 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/
> Эт временное помутнение рассудка у разрабов - дань уважения BeOS :-))да без разницы, C++ всё равно тупик.
собрать сишные библиотеки при помощи gcc2, использовать в проектах с gcc4? да запросто.
собрать плюсовые библиотеки при помощи gcc2, использовать в проектах с gcc4? а фиг вам.
Кстати, насчет gcc2 - так обозначена гибридная версия ОС, в которой работают бинарники, скомпилированные как 2 , так и 4 gcc
http://www.haiku-os.org/guides/daily-tasks/updating-systemPS чистой gcc2 гайки нету уже...
> Кстати, насчет gcc2 - так обозначена гибридная версия ОС, в которой
> работают бинарники, скомпилированные как 2 , так и 4 gccА похрен. С точки зрения разработчика - это означает что придется иметь себе мозг проблемами gcc 2.95. Караван идет со скоростью самого медленного верблюда, а в данном случае верблюд походу совсем увяз.
> Эт временное помутнение рассудка у разрабовНет ничего более постоянного чем временное.
> - дань уважения BeOS :-))
Больше похоже на тотальную неспособность взять управление проектом в свои руки и посметь наконец что-нибудь поменять. Например, выбросив окаменелый и неподдерживаемый шит. GCC 2.95 уже не поддерживают даже те кто его писал. С какого рожна все должны фачить себе мозг проблемами древней версии компилера - не очень понятно.
Видимо, всё что запускается больше чем на 1% железа - недостаточно элитарно.
> Видимо, всё что запускается больше чем на 1% железа - недостаточно элитарно.к чему этот посыл?
>> Видимо, всё что запускается больше чем на 1% железа - недостаточно элитарно.
> к чему этот посыл?вышел дурачок на опеннет комментарии пописать, себя показать.
как-то так на Гайке живем и линухов не маем...
http://youtu.be/g7_cmk5xHOo
> как-то так на Гайке живем и линухов не маем...Сделайте, пжалста к среде чертёж понижающего, до 0.25, редуктора,
за доп. плату расчёт усилий на выходной шестерне.
Для шестёрн используйте латунь ЛК80-3.
Входная мощность 3кВт, на приводной шестерне 18 зубьев.10000$ за видео с демонстрацией работы под ОСь Хyйкy
Впирёд!
Если хочешь быть честным, то спросил бы то же самое на счёт линукса.
И не сейчас, а как и на счёт Haiku - через ..нцать лет после создания - в году так 2002-м.
> Если хочешь быть честным, то спросил бы то же самое на счёт линукса.Дикий баян, в линухе все есть. В основном платное, задорого.
Из халявы
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 года, только гуй разукрасили.
> когда выпустили первый двух-ядерный проц. Дальше галимый маркетинг и развод на бабки.Только 8-ядерник кернель пересобирает как-то пошустрее 2-ядерника. И чего бы это он? :)
> В Linux тоже запор, ноухаву кончились году так в 2004/2005.А какие убер-мега-прорывы ожидаются в general-purpose операционке? Вон у автомобилистов так уже наверное столетие. Ну то-есть народ уже более чем полвека предсказывал всякие там реактивные двигатели и прочее. А они оказались неэкономичными, шумными, с поганым КПД. Электродвигатели пытались прикрутить наверное уже полтора века. И все время упирались в вопрос чем их кормить. А ты говоришь - операционки...
> А хайку в такой жопе, .... думается на уровне 1980 года,
Не, ну GCC 2.95 все-таки не НАСТОЛЬКО ископаемый. Хотя я уже даже и не помню в каком году он был, может у тебя память хорошая?
>[оверквотинг удален]Не, я не в обиду фанатам. Ну чессово, вот сижу, думаю,
куда и зачем можно пристроить этот хайку.Десктоп - труп.
Ембеддед - ну да, и то, только с идейной точки, с экономической вообще не оправданно.
Google/MS/HP/IBM/Oracle/Intel/AMD/Nvidia/..., да им бабла хватить чтоб раскрутить, но
там экономисты посильнее нас будут, и на воздух бабла не бросят.Сервер - если только под управлением какого-то гипервизора, как атомарная ось с нулевым
требованием к железу, потому как поддерживать RAID61 на SAS over 40Gb FC оно научится,
лет через 200.
> куда и зачем можно пристроить этот хайку.Ну как куда? Чесалка ЧСВ для тех кто хочет быть голубых кровей. Даже если это и подразумевает некромансию с 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 в внедрении фич.
>> Десктоп - труп.
> Да не труп он, просто им будут пользоваться те кому он реально
> нужен. Ну там тем кто создает модели в кадах, занимается фотографией,
> 3D, кодит что-то и т.п. - в общем те кто использует
> компьютеры для созидания а не только потребццтва. Ты же не будешь
> кодить на планшете, правда? Да и какие-нибудь фотографии обрабатывать или в
> каде чертить там геморройно из-за поганых средств ввода.Он явно писал о том, что Хайку на десктопе не жилец. Just sayin'
> Он явно писал о том, что Хайку на десктопе не жилец. Just sayin'В этом плане не соврал.
Объясните, пожалуйства, почему он не жилец?
Вот я сужу только по картинкам и здешним отзывам и что же я вижу:
- народ говорит, что отзывчиво;
- народ говорит, что быстро и эффективно работает;
- что-то про 80% ноутбуков;
- на ютубах вижу менюшки с 100500 ассортиментом софта гнушного;Значит, оно не только взлетает, но и работает! Говорите, что нету софта? Так нету и под линух жеж.
А вообще, мне нравится каноникал, именно они двигают линукс в широкие массы, попутно не забывая энтерпрайз. Выходит и этим хайкописателям не хватает своего Марка?..
> А вообще, мне нравится каноникалвот на этом мог и остановиться, остальной твой текст лишний.
> вот на этом мог и остановиться, остальной твой текст лишний.Сапопикал, кстати, попробовал привнести свою лепту в десктопы. Ну там их индикаторы (которые как бы не трэй) с менюхами программ. Замашки вазрослых энтерпрайзятников на кастомный десктоп, сделанный с исправлением ряда бестолковостей/так как хотелось корпорасам - у них имеются. Баг это или фича - второй вопрос, далеко не однозначный.
Вопрос. А что особенного-то? Ну вырвиглазненько это да, ну шустро(у меня на ноуте с кедами линукс тоже шустрый, при том что проц по хуже и тама эффекты есть), ну ссд ускоряет запуск программ, плюс Гайки-то в чем?У них конечно интересная позиция, мол мы только на дескотпы ориентируемся(хомячковые надо полагать). CLI привествуют только разработчики и в финалке, как сказали, развивать не будут. Софта для создания/редактирования 3Д,2Д,звука,веба,бд нема и врядли кто-то портанет.
Прикопаться к отсутствию софта практически нельзя ибо ориентация у них на других пользователей(только кроме гиков-то никто не юзает их ось), считай ось для браузера, видео/аудио проигрывания, аська, торрент, офис(хз какой чего может), архиваторы имеются и больше для счастья ничего не надо.
Сейчас кути портировали, а они то популярность набирают в среде разработки ПО..., вот и будет вас все что нужно..., вообще гайку было бы неплохо в производственных и медийных целях использовать, на то она и была на те времена нацелена на потребл..ство, всего и вся, между прочим первые планшеты были на BeOS!!!
> У них конечно интересная позиция, мол мы только на дескотпы ориентируемся(хомячковые надо
> полагать).Да, хомячковые. Haiku - это призрак BeOS, которую разрабатывали на замену MacOS Classic. ;-) Т.е. на роль Mac OSX.
> Да, хомячковые. Haiku - это призрак BeOS, которую разрабатывали на замену MacOS
> Classic. ;-) Т.е. на роль Mac OSX.А если посмотреть - как-то так вышло что рулят универсальные и масштабируемые системы. Которые от часов/мобилки до сервера.
Несомненно, ASIC считающий SHA256 считает его лучше чем CPU и GPU. Но ни для каких иных целей его не примениишь. Поэтому ASICов продается во, а х86 процессоров - во. Хоть ASIC и долбит SHA256 лучше системного проца...
Создаётся такое впечатление, будто разработка Haiku ведётся именно ради самой разработки. Как ей почти никто не пользуется сейчас, так это и будет продолжаться, пока не поменяются цели проекта. Быть не таким, как все - хорошо только в том случае, если ты чем-то лучше. Разработчики, на мой взгляд, признали, что без своего ядра Haiku не имеет смысла. То есть, вся эта "ориентированность на десктоп" - просто буллшит, раз их гуйня кому-то нужна только со специальным ядром.Впрочем, их дело. Хотят быть самобытными ради самобытности - пожалуйста. Главное, чтобы понимали, что без солидной поддержки оборудования у Haiku всегда будет более чем скромная аудитория, и желающих писать софт под такую ОС тоже найдётся немного.
> Разработчики, на мой взгляд, признали, что без своего ядра Haiku не имеет смысла.А по-моему, они наоборот — боятся, что если хайку-подобный интерфейс будет доступен на других ядрах, из их проекта убегут разработчики, потому как раз интерфейс в Haiku и есть самое главное.
>> Разработчики, на мой взгляд, признали, что без своего ядра Haiku не имеет смысла.
> А по-моему, они наоборот — боятся, что если хайку-подобный интерфейс будет доступен
> на других ядрах, из их проекта убегут разработчики, потому как раз
> интерфейс в Haiku и есть самое главное.Хайку подобный? В чем отличие от КДЕ или Е17 где точно также нажатием на мышку получаем иерархический список для выбора запускаемых программ, а в Е17 и лазанье по папкам(что дико удобно, да?)?
Хайку-подобный (т.е беосо-подобный) интерфейс уже давно есть. См. ZevenOS.
А по моему, чтобы их понять, нужно быть в команде, сообществе, жить образом жизни #HaikuOS( #BeOS / #Zeta ) пользователя. И вообще, ИМХО больше движет этими людьми та искра и тот энтузиазм, что зажгла потрясающая производительность, гибкость и удобство, отзывчивость интерфейса BeOS... Плюс, более продвинутых задело, это размеры нативного софта, -что подчеркивает малую ресурсоёмкость, а так же файловая система, и размещение системных каталогов, - что почти ничего не стоило освоить обычному неандертальцу не тратя большое количество времени...
> ...а так же файловая система, и размещение системных каталогов, -
> что почти ничего не стоило освоить обычному неандертальцу не тратя большое
> количество времени...Интересное у вас однако сообщество... )))
> образом жизни #HaikuOS( #BeOS / #Zeta ) пользователя.Лепить везде хэштеги - это нынче в основном образ жизни твиттерового хомячка. Хотя может быть вы про IRC в лучшем случае?
> потрясающая производительность, гибкость и удобство, отзывчивость интерфейса BeOS...
Странно что втирая про гибкость хотят положить на командлайн.
> Плюс, более продвинутых задело, это размеры нативного софта, -что подчеркивает малую
> ресурсоёмкость,И где этот нативный софт?
> а так же файловая система,
Ну, попробуйте ее плюсы vs существующих сегодня? :)
> и размещение системных каталогов, -
...интересное полутора програмерам на планете...
> что почти ничего не стоило освоить обычному неандертальцу не тратя большое
> количество времени...Обычному неандертальцу вообще нефиг нос совать в системные каталоги - система целее будет.
> этими людьми та искра и тот энтузиазм, что зажгла потрясающая производительность, гибкость и удобство, отзывчивость интерфейса ...Хочется тёплого лампового ассемблера - 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)
Когда я юзал менует то были времена флоповодов и дохлых веников), и то она умудрялась фризить!!! ... - даёшь менует разрабов агитировать на гайко девелопмент!!!)
> то она умудрялась фризить!!! ...Так это нормально: I/O встало колом (а на флопповоде или дохлом венике это норма) -> простой и очевидный код будет до упора ожидать окончания I/O. А всякая асинхронщина, продвинутые планировщики и прочее - уже нифига не просто, и вообще.
> А по-моему, они наоборот — боятся, что если хайку-подобный интерфейс будет доступен
> на других ядрах, из их проекта убегут разработчики, потому как раз
> интерфейс в Haiku и есть самое главное.В "клятых X-ах" для создания хайку-подобного интерфейса нужно лишь написать оконный менеджер, да файловый менеджер. :-) А как написано в аннотации к Zeven OS, даже и писать ничего не надо, достаточно просто выбрать подходящую тему в одном из WM'ов Ubuntu. :-)
Так и есть"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?"
Да наоборот же!"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."
"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."Вообще, если почитать переписку мнения там разделились, но для части народа Гайка просто для фана. Одна бинарная совместимость с Пчелой чего стоит, кому дался тот древний софт?
> "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.
> Этот лох не понял что Столлман крутой мужик и вообще-то сделал самораспостраняющуюся
> заразу, которая автоматически изводит паразитов и халявщиков, зачастую конвертируя их
> в симбионтов :).
>
> Да, вы правы: красивая работа на мусорный бак. Правда, видимо не все
> испытывают энтузиазм от участи кодить в /dev/null.294-й, вот без твоего авторитетного вонизма тут никак было не обойтись. Никто, кроме тебя, не укажет людям, что их жизнь и их любимое дело не стоят выеденного яйца. Не то что ты, повелитель N900, умеющий компилировать под ARM и даже раз в год соизволяющий отправить жалобу в чей-нибудь багтрекер. Куда до тебя ламерам, которые из-за своего любимого проекта становятся специалистами по USB, файловым системам, работе с кешами современных CPU и GPU... Все должны тут же послушать тебя, забиться по офисным каморкам и не отсвечивать. А, и ещё славить Столмана за воздух, которым он им позволяет дышать.
Тьфу.
> 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л.
сейчас оно ничего бы не выйграло и с ядром линукс. Либо оно бы всталов огромный
ты просто не понял, без их ядра никакой ориентированности не получится, получится просто еще один линукс
Я за то, чтоб было доступно 2 ядра для выбора. Пользователям Linux - и больше пользователей и популяризация проекта, и программистов больше станет, а предприятиям (для интеграции во всякие телевизоры, чайники, роутеры...) ядро Haiku, лизензия MIT все таки
пусть ReactOS предложат перейти на ядро Linux... что уж там мелочиться...
> пусть ReactOS предложат перейти на ядро Linux... что уж там мелочиться...Не, для полного стеба надо чтобы гайка перешла на ядро реактоса. Тогда они смогут подать заявку в книгу рекордов Гинесса. Как проект находящийся в максимально возможной на этой планете ж...е - такое суперкомбо по безблагодатности никто не переплюнет, по любому :).
> Не, для полного стеба надо чтобы гайка перешла на ядро реактоса.нельзя: тогда реакторовцам неоткуда будет брать код для работы с периферией. ну, типа USB, например.
> пусть ReactOS предложат перейти на ядро Linux... что уж там мелочиться...Не в обиду реактосу, wine можно на практике пользоваться, а в Linux работает железо и прочее. Поэтому если надо ехать, а не шашечки - нарулить в пингвине вайн на порядок результативнее долботни с реактосом.
А эта Haiku хоть чуток развивается, а то
Version: R1/Alpha 4.1
Release date: November 14th, 2012
Еще как развивается -http://cgit.haiku-os.org/haiku/log/
> Еще как развивается -Реактос тоже таким макаром 15 лет развивался. Правда, виндузоиды более тормозные - у них SVN в 2014 году.
http://youtu.be/QEnMlnk4Ixc
все эти программульки (и даже больше их) есть и на 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)
может стоит сначала ознакомиться с предметом разговора и хотя бы один раз его запустить прежде чем писать всякий бред?
> может стоит сначала ознакомиться с предметом разговора и хотя бы один раз
> его запустить прежде чем писать всякий бред?зачем? это у нас Иксперд. а настоящему индейцу^w Иксперду совершенно не обязательно разбираться в теме. даже, скорее, вредно.
а смысл от этой оси, если она может наступить на грабли - тролеводов?
волков бояться - в лес не ходить
>> Еще как развивается -
> Реактос тоже таким макаром 15 лет развивался.не таким. хайка вполне себе разрабатывается под хайкой, а реактору до этого как телеге до альфы центавра.
> не таким. хайка вполне себе разрабатывается под хайкой, а реактору до этого
> как телеге до альфы центавра.Валидный пойнт, однако. Тем не менее, почитав сообщение разработчика про юниксы и графические системы у меня возникло сомнение во вменяемости этого индивида, т.к. то что он вещает - не стыкуется с фактами чуть более чем никак...
> А эта Haiku хоть чуток развиваетсяразвивается.
Кстати, насчет gcc2 - так обозначена гибридная версия ОС, в которой работают бинарники, скомпилированные как 2 , так и 4 gcchttp://www.haiku-os.org/guides/daily-tasks/updating-system
PS чистой gcc2 гайки нету уже...
gcc2 - для запуска тех самых тёплых ламповых программ, которых теперь не пишут. Эх, времена былые, кодеры удалые..
вот что важнее: сохранение самобытности или поддержка оборудования?
> вот что важнее: сохранение самобытности или поддержка оборудования?в данном случае — сохранение самобытности.
> в данном случае — сохранение самобытности.Реактос тоже сохраняет вон. В результате проще запустить wine в линуксе, если на шашечки пофиг, а вот ехать приспичило и как-то так вышло что одной из точек маршрута оказалась маздайная программа без аналогов...
> Реактос тоже сохраняет вон.Только зачем? Прообраз Реактоса живее всех живых, а прообраз Haiku - BeOS давно в могиле. Поэтому самобытность, которую хранит Реактос, и без него никуда не пропадёт, а вот с Гайкой всё совсем не так.
> Только зачем? Прообраз Реактоса живее всех живых,Только бинарный - без исходников. И документация на кернелмод - такая, чтобы конкуренты не догадались. Так что толку то с прообраза.
А прообраз гайки - дохлая лошадь, однако. По каким причинам она издохла - второй вопрос.
> никуда не пропадёт, а вот с Гайкой всё совсем не так.
Ну вон CP/M что-то тоже не развивается. Желающим поработать на мусорницу есть над чем подумать.
> Только бинарный - без исходников. И документация на кернелмод - такая, чтобы
> конкуренты не догадались. Так что толку то с прообраза.Для пользователей пробраза и, главное, перспективных пользователей(!) Реактоса исходники не важны. Т.е. ребята строят открытую ОС для тех, кто открытость и свободность в грош не ставит - типичные "свинья в апельсинах".
> А прообраз гайки - дохлая лошадь, однако. По каким причинам она издохла
> - второй вопрос.Да, именно поэтому есть музейный смысл делать копию, раз дохлая. Вот Windows сдохнет, будет музейный смысл делать копию.
> Ну вон CP/M что-то тоже не развивается. Желающим поработать на мусорницу есть
> над чем подумать.FreeDOS же.
Мда, BeOS в свое время была замечательная система.
Но политика Be Incorporated довела ее "до ручки".
Даже сейчас смотрю на своего старичка BeBox (4x Power PC 604) с ностальгией.
Даже Dano с его "кривым" Bone был просто блеск!Кстати, BeBox у меня работал в качестве почтового и web-сервера (естественно домашнего) до 2008 года, пока не заменил его на Mac mini (как более компактное и бесшумное решение), а потом и Mac mini Server.
Пожелаем ребятам из Haiku удачи! Пусть будет больше ОС, всяких - по крайней мере у нас будет выбор!
> Мда, BeOS в свое время была замечательная система.
> Но политика Be Incorporated довела ее "до ручки".ничего не напутано случайно? потому что я читал - что это Intel & MS довели до ручки Be
>> Мда, BeOS в свое время была замечательная система.
>> Но политика Be Incorporated довела ее "до ручки".
> ничего не напутано случайно? потому что я читал - что это Intel
> & MS довели до ручки Beименно так, корпорация зла сделала свое дело
> именно так, корпорация зла сделала свое делоЕсли проект легко доводится до ручки - ему это не в плюс.
