Linux 2.2.26

Пойду поставлю взамен 2.2.18...

Или рисковано... Никто же не тестит...

>Или рисковано... Никто же не тестит...

угу,Linux вообще ставить рисковано, баги в нём находят с завидной регулярностью. Лучше попробуй BSD.

Вот у ляпиха ядро развивается темпами....вчера 2.2.25 вышло, сегодня без пре и рц вышел сразу 2.2.26...подожду завтра-выйдет 2.2.50. ;)))

Завтра будет 2.50.2

Ой. ссори...я думал 2.4... :))

Замечательный совет...

Встречный вопрос: А как вместо linux-kernel 2.2.26 поставить BSD?

Естествонно все остальное (в том числе /bin/ls и т.п.) осталось старое...

Если бы я собитался апгрейдить свою слакварь (раньше это был самый удобный _для_меня_ дистр) Можно было посоветовать поставить FreeBSD например.

А вот совет вместо _Linux_kernel_ _попробовать_ _BSD_!

_BSD_ какая? Или благородному дону известен только одна?

За _попробовать_ начальство голову снимать должно, если взялся менять платформу то не пробуй, а сделай что б работало не хуже чем раньше...

Ну про сравнение kernel vs дистрибутив уже написал...

так а где эксплоит-то на mremap? болтают только

гы, таким маинтейнером и я могу быть -> прикладывать патчи
от Solar'a и Алана и бэкпортить че-нить простое из 2.4 ;)
и еще получать за это бабки от Yoyodine GMBH

Возможно я неточно выразился, не ядро Linux на BSD а дистр на дистр.

На полке запросто... Хоть дистр Slacware 3.2 на Windows 3.1 on Dos 3.3 :-)

А на работающей системе...

А обосновать? Выкладки пожалста, в том числе финансовые. Меня эта система уже два года не трогает, с момента завершения ее написания. При этом линукс в качестве системной подкладки вполне устраивает.

>Пойду поставлю взамен 2.2.18... >Или рисковано... Никто же не тестит...

У меня 2.2.25 нормально работает, к тому же ошибка с "kernel: VM: do_try_to_free_pages failed" была пофиксена только в 2.2.19, так что ИМХО переходить на 2.2.25 с 2.2.18 надо.

http://www.debian.org/ports/netbsd/ и http://www.debian.org/ports/freebsd/

бздюки, как всегда, бздят в лужу :)))

Причем тут?!

>На полке запросто... Хоть дистр Slacware 3.2 на Windows 3.1 on Dos 3.3 :-)

а где ее скачать можно?

могу поделиться...

> гы, таким маинтейнером и я могу быть
Докажи что можешь, выпусти *официальную* 2.2.27. А? Слабо? :)
Вообще AFAIK, MCP был маинтаинером ядра WOLK многие годы, так что
наверное кое-какой опыт у него всё же есть:)
Но я тоже немного удивлён что именно он теперь 2.2 ведёт.
Ведь WOLK и -stable -- прямо противоположные вещи всё же.

>Докажи что можешь, выпусти *официальную* 2.2.27. А? Слабо? :)
>ообще AFAIK, MCP был маинтаинером ядра WOLK многие годы, так что
>наверное кое-какой опыт у него всё же есть:)
>Но я тоже немного удивлён что именно он теперь 2.2 ведёт.
>Ведь WOLK и -stable -- прямо противоположные вещи всё же.

Да, мне слабо. Я не очень заинтересован ядром (прикинь!?), есть
и в userspace вещи очень и очень интересные и непростые, не всякий
программист ядра потянет.

Начнем с того что 2.2 и 2.4 это уже из разряда historic,
и линусу и всем кардиналам насрать что там за подковровые война
в этом мирке. MCP imho не очень владеет кодингом, если устроить
быстрый брэйн-тест по ядру (типа найти глюк в куске кода, или
предложить переписать функцию или оптимизировать ее) то кодер
он херовенький. Так что если кто-то очень хотел выпускать 2.2
он получил возможность. Я помню как lkml ему протекцию делали -
в том треде было пару человек, это никому не интересно.
Потом наверное алану написали а он был непротив, хотел 2.6 заведовать,
но не дали.

Многие годы это сколько? 2 года? да, есть опыт наложения конфликтующих
патчей. вообще у меня сложилось из наблюдений и размышлений такое видение картины - они не очень понимают внутренней структуры ядра,
а стараются впихнуть туда всю попсу что гуляет в сети.
волк был и есть полный сакс. помню они в него grsec и preemtion
включали, я тогда читал грсековский лист, так отцы сека
говорили что нельзя миксить preemtion и сек, почему уже
не помню - им какой-то чел возразил что типа в волке такое есть,
его громко обсмеяли (не отцы - троли).
2.2 и 2.4 занимается солар(для тебя он тоже не авторитет),
но на публику он не работает, как те кто хотят маинтейнить
популярные проекты ...

Такие вот размышления.

Подскажите пожалуйста, есть ли в Линуксе поддержка таблицы строк на уровне ядра?

Я имею в виду аналог виндовой таблицы атомов. То есть в таблицу добавляется строка, и взамен возвращается некий уникальный идентификатор. Если же такая строка есть, то возвращается идентификатор этой уже зарегестрированной строки.

>Подскажите пожалуйста, есть ли в Линуксе поддержка таблицы строк на
>уровне ядра?

>Я имею в виду аналог виндовой таблицы атомов. То есть в таблицу
>добавляется строка, и взамен возвращается некий уникальный
>идентификатор. Если же такая строка есть, то возвращается
>идентификатор этой уже зарегестрированной строки.

не дай бог эта шняга из WinAPI припрется сюда....

чур меня, чур!

>могу поделиться...

чиркани если не затруднит на reflex123@bk.ru

Почему это? Что у вас есть против? толькол то, что в виндах это есть?

Дело в том, что сейчас при создания семафоров, мьютексов для их межпроцессной идентификации используются числа. Это довольно-таки ограничительно, потому что их идентификаторы могут совпасть у разных программ.
Таблица атомов позволит получать идентификаторы более уникальные - ведь строки содержат больше символов, чем одно число.

>в сети. > волк был и есть полный сакс. помню они в него grsec и preemtion > включали, я тогда читал грсековский лист, так отцы сека > говорили что нельзя миксить preemtion и сек, почему уже > не помню - им какой-то чел возразил что типа в волке такое есть, > его громко обсмеяли (не отцы - троли).

В wolk есть предупреждение, какие разделы нельзя выбирать одновременно для компиляции (они конфликтуют друг с другом). Тебе дан выбор - использовать одно или другое, а если ты выбрал в (menu,x)config два взаимоисключающих раздела - так тебя предупреждали!

Просто в оригинальном ядре нет взаимоисключающих разделов, чтобы юзеров не путать и многие не понимают, что в wolk для гибкости выбора это есть. И тупят после этого. А так, вполне грамотное и стабильное было ядро, просто не расчитанное, что юзер в здравом уме выберет для компиляции все сразу

>Дело в том, что сейчас при создания семафоров, мьютексов для их межпроцессной идентификации используются числа. Это довольно-таки ограничительно, потому что их идентификаторы могут совпасть у разных программ. Таблица атомов позволит получать идентификаторы более уникальные - ведь строки содержат больше символов, чем одно число.

man ftok курить не пробовали ? ;)

ftok возвращает несложный хеш от строки без гарантии неповторения

> ftok возвращает несложный хеш от строки без гарантии неповторения

Ну вероятность такого события достаточно невелика и связяна в основном с совпадением i-node для файлов с различных устройств на основе которых данный хеш генерится

Кроме того это решение генерации уникальных ключей является фактическим стандартом то есть сделать то kernel генерилку уникальных ключей несложно но это уход от существующего стандарта

И ещё - строка должна быть путём к существующему файлу.
Было бы неплохо возвращать число для произвольной строки.
Скажем, ограничив эту строку хотя бы в 255 символов (уместится практически любое имя собственное).

>>Дело в том, что сейчас при создания семафоров, мьютексов для их >>межпроцессной идентификации используются числа. Это довольно-таки >>ограничительно, потому что их идентификаторы могут совпасть у разных >>программ.
Ты про ft_ok() ? Напиши библу которая будет это разруливать.
На входе строка, которая кладется в массив индекс из которого подается на ft_ok().

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