Linux за българи: Форуми

изтрито

Здравейте,

Последна е - 2.6.23.8, тя трябва да включва всички предишни поправки.
Щом има официално излязла версия 2.6.23.{2,3,4,5,6,7,8} то последната е актуална (може някои поправки да са изтеглени, други да са влезли и т.н.).
PS: дори май скоро ще има и 2.6.24 (2.6.24-rc3)
Успех. Румен

А какъв е смисъла да си слагаш точно последната версия?

Гледах наскоро по LWN последните пачове, нямаше нищо кой-знае какво, тук там някой fix, щото те към .20 почнаха да merge-ват много неща и сега се сетиха, че нещата няма как да цъфнат и вържат без да се оправят бъгове.

Между другото, 2.6.18 е едно хубаво ядро Не мисля да минавам на друго. Вкъщи даже съм на 2.6.15 на десктоп-а.

Здравейте,

@tarator:

Доколкото следя ядрата, мога да кажа, че няма точен график за излизане на ново ядро, това си го решават разработчиците.
Само за пример скоро имаше ядра с доста нови неща, след това имаше едно главно за поправка на новите (и стари) бъгове :-)
Очаквам че ще излизе скоро, поради сигнатурата му: rc3
PS: при мен (Gentoo) сравнително често обновявам ядрото, не ми пречи особено ;-) - 2.6.22-suspend2-r2
Поздрави. Румен

ray,

Зависи какво разбираш под скоро. Обикновено времето от версия до версия отнема около 3 месеца, така че е твърде вероятно 2.6.24 да излезе по Коледа. Но може да отнеме и доста повече защото имаще много промени между .23 и .24.

В 2.6.23 са фикснати невероятно мн бъгове от към usb периферията и някои проблеми които имах доскоро вече ги нямам. Странното е че тези проблеми които аз съм имал в 2.6.18 и 2.6.19 ги нямаше. Появиха се след 2.6.20.

The latest prepatch for the stable Linux kernel tree is:   2.6.24-rc3  2007-11-17 05:35 UTC -9Мбайта.

Мисля, че сега работят предимно върху USB, suspend/power management-a, както и върху едни глупотевини, свързани с виртуализацията. Явно имат лоши отзиви свързани с хора, ползващи лаптопи, не знам

изтрито

2.6.23 е едно лудо ядро... а  2.6.24 май ще бъде адско
хахах

ray,

-rc3 не е близо до финалния 2.6.24. Вероятно ще има още поне още 4-5 rc-та и Линус ще пусне 2.6.24 малко преди Коледа.

4-5...не вярвам, макар че знам ли ги..

Сега не ми се търси в кое " Changelog"  (rc1? ) се променаваше че имало  21Мбайта пачове ...
Друго ,попаднах и на две български имена  , и то на главно място:
http://www.eu.kernel.org/pub.....24-rc2

gateway,

Последния rc на 2.6.23 е rc9. На 2.6.22, 21 и 20 са rc7.

Има, има...един пич дето живее в Англия и разработва подръжката за NTFS...и един дето се занимава с подръжката на файловата система на plan9 (tarator-e, случайно да знаеш нещо по въпроса?  )

изтрито

Не знам , понякога си мисля ,че толкова много промени не са много хубаво нещо.
Не само за ядрото , например  и за КДЕ , и др . Ето ,сега таман КДЕ-то се позаглади , и ще почнат мъките с КДЕ 4.,,

изтрито

Ъъъъм, виж кво, много грубо е да кажеш, че е почти неизползваемо. Принципно, потребителите слабо ги вълнува бъркотията, свързана с кърнъл АПИ-то. Дори ако девелоп-ваш някакъв userspace софтуер по принцип малко ти се налага да знаеш какво се било променило там: има си съответни библиотеки, те си викат разните там syscalls и се занимават с разликите в параметрите им, те си комуникират с ядрото и т.н.

От друга страна, откъм документация нещата са наистина зле. Но пък си съществуват разните там ЛКМЛ, чат-пат статии по въпроса се пишат, така че не е толкова загубена кауза.

Между другото има що-годе удобни web-based интерфейси, през които можеш да видиш кой експортнат symbol къде е деклариран, къде се използва и донякъде какво прави. Аз лично поне през гугъл съм попадал на такива неща. Друг е въпроса че ако си имаш kernel source-а, винаги можеш да ползваш grep

Бих казал, че писането дори на дребни кърнълспейс неща е доста забавна работа. И да, изисква се четене и ровене.

Не знам коя компания има проблем с писането на драйвери, ако има такива, вероятно са свързани със спазването на GPL лиценза и прочее политически проблеми. Ако си имаш спецификациите на хардуера, не вярвам да ти е зор да си направиш драйвер за джаджата. Има си определени нива на абстракция (layers) - например block, vfs, etc. Там нещата са си дефинирани ясно и не ти се налага да се занимаваш с прекалено много неща, просто дефинираш определени callback функции, които се викат, когато се върши някаква работа.

P.S обаче е проблем, при видеодрайвери и някои драйвери за 802.11 джаджи. Но пак главно поради политически въпроси. Твоята карта, с драйвера дето зарежда firmware е пример за това. Сходни неща доколкото знам се случват и с някакви карти на Нвидия ако не се лъжа. Но това са частни случаи, в които инатът прецаква нещата. Това е малко дълга тема за размисъл, защото ако се замислиш примерно boot процеса при itanium2 например пак е свързан с зареждане на интелски фърмуер от файловата система...и в този ред на мисли една линукс инсталация на такава машина не е чак толкова свободна и отворена

изтрито

изтрито

ivo1204,

Основната причина да няма разни удобства за програмистите на ядрото е, че те не се нуждаят от такива. Като подпричина може да се приеме, че разработчиците _не искат_ да окуражават хора, които не могат да се оправят да правят промени. Освен това има поне две добри книги, описващи ядрото: Linux Kernel Development  на  Robert Love  и  Linux Device Drivers  на Corbet, Rubini и gregkh.

А фирмите обикновено имат проблеми с писането на драйвери не защото това е толкова трудно, а защото а) не правят усилия кодът им да спазва стила на ядрото, б) пишат грозен код (повечето производители на хардуер пишат такъв , и в) откриват топлата вода вместо да използват вече съществуващите механизми в ядрото.

Аз лично нямам никакви проблеми да се ориентирам в кода  на ядрото. Разглеждал съм ядрата и на други операционни системи, не са по-четливи, нито пък има повече документация.

изтрито

ivo1204,

В кода има достатъчно коментари.

> И се очаква ,да се зарови в кода на ядрото. Ама това е пари ,много
> пари.Тоя човек трябва да се обучи , и то не за друго , а само да се рови
> в 150 Мбайта сорс.

Да, ядрото има достатъчно контрибутори, нямат нужда от аматьори, които си мислят, че с едно IDE и два дни ровене по API-то могат да напишат модул. Който не иска да се обучи, да пише на QT

Писането на kernelspace код НЕ е нещо сложно.

До колкото мога да съдя по моите експерименти в тази област, бих казал че е и забавно при това.

Мене ООП никога не ме е влечало като идея, защото съм си свикнал на С, преди това съм се занимавал предимно с Паскал и Бейсик, га бех млад.

Никой не ти забранява да пишеш такъв софтуер, стига да е за твоя лична употреба. Ако имаш огромният мерак да ставаш известен и да ти го merge-ват, тогава вече трябва предполагам стават други работи.

И не мога да разбера какво му е по-лесното на qt програмирането. Правил съм си опити да вникна в нещата, но винаги ми е идвало в повече и съм се отказвал. Занимавал съм се с delphi и visual C, там беше къде по-нормално и логично.

Разбира се, аз съм далеч от програмист и се занимавам с такива неща за собствен кеф. Ако това ми беше работата, сигурно щях да се чувствам гадно, не знам..

А и не мисля, че кърнъл девелоперите са такива зли същества, които нарочно ти правят живота черен. Просто не им се занимава с глупости.

изтрито

ivo1204,

> Та клиента е този който плаща , и така поставени нещата , едва ли ще
> наклонят везната за Линукс.

Нали не си мислиш, че на някой от разработчиците на ядрото му пука дали "клиента" ще използва Линукс?

изтрито

> A не нислиш ли , как ще се почуства клиента ,като му кажат ,как да
> приложи пач_номер_1212 за АБС системата ?

Защо трябва да му казват такива неща? Ще му кажат да използва repository-то, в което го има този patch и което е сертифицирано, че работи с устройството.

> Дори ако клиента е Mercedes ,BMW ,Toyota?

Да, независимо които са клиентите.

Разработчиците на ядрото се интересуват от качеството на кода в ядрото. Защото Мунчо от BMW може да му отнеме 2 месеца да го напише, но разработчиците след това трябва да го поддържат завинаги. И ако кода не работи, Пенчо няма да каже "Мунчо от BMW пише лош код", а ще каже "Линукс е боклук".

Никой не кара производителите да се съобразяват с изискванията на разработчиците на ядрото. Те трябва да го правят само ако искат да си включат кода в стандартното ядро. Например разработчиците на Sharp не са правили никакъв опит да вкарат промените за Zaurus-а в ядрото.

Разбира се, поддръжката на код извън стандартното ядро е голямо главоболие и струва много повече отколкото да се инвестира в програмист, който да напише кода както трябва. Например на работа имаме пач от 5 хиляди реда, който не може да бъде включен в ядрото (променя важни части по начин, който го прави неизползваем в общия случай) и вече повече от 5 години лабораторията плаща на kernel hacker (за щастие не съм аз), който да модифицира patch-a когато излезе нова версия на ядрото. За тези 5 години лаба е изхарчил милиони долари за тази цел.

изтрито

> Ако обаче в действителност си собственик на малка фирмичка , тогава и
> мисленото ще е друго: Мога ли да го сложа тоя Линукс и да правя пари с
> него ?Колко ще ми струва , и дали ако продам  1000 парчета от това ,
> ще спечеля ?

Е, ако иска, може да си напише собствена операционна система. Сигурен съм, че ще му излезе по-евтино :Р

изтрито

На бизнес основа е най-лесно да вземеш Линукс, да го модифицираш и да не вкараш промените обратно в ядрото. Дори ако нямаш много клиенти, няма нужда да разпространяваш променения код в Интернет. Например Cray не възнамеряват да пускат кода на Линукс версията, заменяща Catamount на клъстърите им да е достъпен за друг освен клиентите им.

изтрито

> Хмм малко не схващам, ако разработчиците ги "помолят" тия от Cray
> няма ли да върнат кода? Та според моите знания това противоречи с GPL
> тотално

Според GPL не са длъжни, стига да дадат разпространят изходния код заедно с компилирания. Т.е. да го дадат на хората, които са купили клъстър от тях.

изтрито