Thread View: pl.comp.os.linux.debian
12 messages
12 total messages
Started by Artur Hefczyc
Wed, 05 Nov 2003 07:26
Dziesiatki procesow: /USR/SBIN/CRON
Author: Artur Hefczyc
Date: Wed, 05 Nov 2003 07:26
Date: Wed, 05 Nov 2003 07:26
22 lines
1368 bytes
1368 bytes
Czesc, Spotkal sie ktos moze z problemem pojawiajacych sie w duzych ilosciach procesow: /USR/SBIN/CRON Tak wlasnie pisanych duzymi literami. Dzieje sie to po kilku godzinach od uruchomienia systemu. Jadro 2.4.22. Debian unstable Jakie jadro jest zalecane obecnie? Czy 2.4.22 jest uwazane za stabilne? Jesli nie to ktore z linii 2.4.x? Artur -- Artur Hefczyc Open Source Developer http://generguide.sourceforge.net/ http://www.geotools.org/ http://wttools.sourceforge.net/ http://maven-plugins.sourceforge.net/
Re: Dziesiatki procesow: /USR/SBIN/CRON
Author: m.mazurek
Date: Wed, 05 Nov 2003 08:25
Date: Wed, 05 Nov 2003 08:25
18 lines
1226 bytes
1226 bytes
Artur Hefczyc <wislaj23@wp.pl> wrote: > Spotkal sie ktos moze z problemem pojawiajacych > sie w duzych ilosciach procesow: > /USR/SBIN/CRON cron jak to cron pracuje sobie w tle, to co robi możesz sprawdzić w /etc/cron.* > Jakie jadro jest zalecane obecnie? > Czy 2.4.22 jest uwazane za stabilne? Jesli nie to ktore z linii 2.4.x? ano stabilne. pz mazek -- http://www.netsync.pl/~mazek/ : nic-hdl: MM3380-RIPE GnuPG 6687 E661 98B0 AEE6 DA8B 7F48 AEE4 776F 5688 DC89
Re: Dziesiatki procesow: /USR/SBIN/CRON
Author: Grzegorz Bajson
Date: Wed, 05 Nov 2003 19:02
Date: Wed, 05 Nov 2003 19:02
14 lines
1239 bytes
1239 bytes
> Jakie jadro jest zalecane obecnie? > Czy 2.4.22 jest uwazane za stabilne? Jesli nie to ktore z linii 2.4.x? W linuksie generalnie widze wielki bajzel. Trudno mi zrozumieć dlaczego w jądrze podobno (np paniki przy acpi, często) stabilnym pojawia się coś takiego: [*] Prompt for development and/or incomplete code/drivers No właśnie, potrafi to ktoś rozjaśnić ? -- Grzegorz Bajson
Re: Dziesiatki procesow: /USR/SBIN/CRON
Author: Krzysztof Krzyżaniak
Date: Wed, 05 Nov 2003 20:16
Date: Wed, 05 Nov 2003 20:16
28 lines
2081 bytes
2081 bytes
Pewnego dnia, a było to Wed, 5 Nov 2003 19:02:43 +0000 (UTC), przyszła do mnie
wiadomość z adresu <gbajson@elka.pw.edu.pl> i powiedziała:
>> Jakie jadro jest zalecane obecnie?
>> Czy 2.4.22 jest uwazane za stabilne? Jesli nie to ktore z linii 2.4.x?
>
> W linuksie generalnie widze wielki bajzel. Trudno mi zrozumieć dlaczego w
> jądrze podobno (np paniki przy acpi, często) stabilnym pojawia się coś
> takiego:
>
> [*] Prompt for development and/or incomplete code/drivers
>
> No właśnie, potrafi to ktoś rozjaśnić ?
[*] Pytaj o rozwojowe i/lub niekompletne kody/sterowniki
No dobrze. Jest tak, że gdy kernel ma określoną funkcjonalość jest
uważany za stabilny. Ale stabilny oznacza też najczęściej
przestarzały. Dlatego też możesz sobie włączyć kod/sterowniki które
pewnie będą pełnić przypisaną im funkcję ale robisz to na własne
ryzyko (de facto i tak cały kernel używasz na własne ryzyko ale to już
inna inszość).
eloy
--
-------e-l-o-y-----------e-l-o-y-@-t-r-a-n-s-i-l-v-a-n-i-a-.-e-u-.-o-r-g------
jeżeli nam zabraknie sił zostaną jeszcze morze i wiatr
Re: Dziesiatki procesow: /USR/SBIN/CRON
Author: m.mazurek
Date: Wed, 05 Nov 2003 20:18
Date: Wed, 05 Nov 2003 20:18
22 lines
1524 bytes
1524 bytes
Grzegorz Bajson <gbajson@elka.pw.edu.pl> wrote: > W linuksie generalnie widze wielki bajzel. Trudno mi zrozumieć dlaczego w > jądrze podobno (np paniki przy acpi, często) stabilnym pojawia się coś > takiego: > [*] Prompt for development and/or incomplete code/drivers > No właśnie, potrafi to ktoś rozjaśnić ? Bo zaklada sie, ze czlowiek rozumna istota jest i potrafi czytac. Dla mnie to wielka wygoda, ze w kernelach stabilnych w swych podstawach dodawane sa rzeczy, ktore pozwalaja mi korzystac z pewnych rozszerzen/nowinek. pz mazek -- http://www.netsync.pl/~mazek/ : nic-hdl: MM3380-RIPE GnuPG 6687 E661 98B0 AEE6 DA8B 7F48 AEE4 776F 5688 DC89
Re: Dziesiatki procesow: /USR/SBIN/CRON
Author: Grzegorz Bajson
Date: Thu, 06 Nov 2003 07:44
Date: Thu, 06 Nov 2003 07:44
48 lines
3037 bytes
3037 bytes
Nie wyraziłem się dosyć jasno. Akurat z przetłumaczeniem sobie poradziłem ;), chodziło mi raczej o filozofię takiego postępowania. Szczegóły poniżej. > [*] Pytaj o rozwojowe i/lub niekompletne kody/sterowniki IMO moglo by to się nazywać: [*] Unstabling kernel, using untested and/or uncompleted features > No dobrze. Jest tak, że gdy kernel ma określoną funkcjonalość jest > uważany za stabilny. Ale stabilny oznacza też najczęściej > przestarzały. Do tego zmierzam. Jaki procent użytkowników nie zaznacza omawianej opcji przy konfiguracji jądra ? Innymi słowy, wielu użytkowników w zasadzie używają stabilnej wersji jądra (a jakże 2.4.x), ale równocześnie używają wynalazków nie-do-końca wytestowanych, czy nawet nie-do-końca napisanych. Uważam że dobrym pomysłem byłoby pozostawnienie tej całej funkcjonalności w gałęzi 2.3.x (2.1.x; 2.5.x; itd.) i usunięcie jej ze ,,stabilnych'' wersji. > Dlatego też możesz sobie włączyć kod/sterowniki które > pewnie będą pełnić przypisaną im funkcję ale robisz to na własne ~~~~~~~~ > ryzyko (de facto i tak cały kernel używasz na własne ryzyko ale to już > inna inszość). Pewnie tak. I wogóle całego linuksa używam na własne ryzyko (a jakiego systemu nie?). Bo pewnie będzie działał, ale czy będzie działał pewnie? Piszę to wszystko dlatego, że co jakiś czas spotykam się z reakcjami różnych użytkowników, którzy włączają na masę różnych dodatków, 4 patchów, i 10 patchów na patche, żeby to wszystko dało się skompilować. Później im się to wysypuje; dzowonią, piszą, spać nie dają, krzyczą jaki ten Linux jest do dupy, bo ,,nie działa'' mimo że używają stabilnej wersji -- i weź im za każdym razem tłumacz. Uważam, że podczas zaznaczania jakiejś niewytestowanej funkcjonalności, zakładania patchy, etc, powinno być jasno i wyraźnie napisane, że możemy się liczć z jakąś niestablilnością. A najlepiej żeby po jakimś patchowaniu uname -r pokazywał jakieś 2.4.22-UNSTABLE. -- Pozdrawiam Grzegorz Bajson
Re: Dziesiatki procesow: /USR/SBIN/CRON
Author: Grzegorz Bajson
Date: Thu, 06 Nov 2003 09:55
Date: Thu, 06 Nov 2003 09:55
70 lines
3689 bytes
3689 bytes
Krzysztof Krzyżaniak <eloy@pawnhearts.eu.org> wrote: >> Do tego zmierzam. Jaki procent użytkowników nie zaznacza omawianej opcji >> przy konfiguracji jądra ? > > Jaki procent użytkowników kompiluje kernele? Z mojego otoczenia i chyba reprezentatywnej próbki (znajdzie się ze 100 osób), to jakieś 99% ;). >> Uważam że dobrym pomysłem byłoby pozostawnienie tej całej funkcjonalności >> w gałęzi 2.3.x (2.1.x; 2.5.x; itd.) i usunięcie jej ze ,,stabilnych'' >> wersji. > > A ja uważam, że to byłby kiepski pomysł hamujący rozwój. W jaki sposób hamowałoby to rozwój ? Podaj przykład. >>> Dlatego też możesz sobie włączyć kod/sterowniki które >>> pewnie będą pełnić przypisaną im funkcję ale robisz to na własne >> ~~~~~~~~ >> >> Pewnie tak. I wogóle całego linuksa używam na własne ryzyko (a jakiego >> systemu nie?). Bo pewnie będzie działał, ale czy będzie działał pewnie? > > Mniej więcej na tyle ile reszta. Nie zgodzę się z tym. Akurat z funkcjami z ,,unstable'' miewam często problemy, działają (nie działają?) o wiele gorzej od części ,,stable''. Przykłady? Nieszczęsne ACPI. Nie wiem czy wina leży w kiepsko napisanych modułach, czy w źle implementowanym sprzęcie, ale na niektórych płytach po prostu lecą paniki. Inna sprawa trochę ze sterownikami odstarczanymi od producentów, zazwyczaj są źle popisane (np karta ISDN przestaje działać, kiedy działa karta dzwiękowa, i inne tego typu historie; panicujące winmodemy, urządzenia nie działające przy włączonym seti@home...). Chciałbym żeby w trybie STABLE kernel zabraniał ładowania tego szajsu. > To jest napisane, w helpie do tej opcji. Fakt jest, i nawet czytałem, ale praktyka wskazuje że niewielki % bierze to sobie do serca. A mi spać nie dają ! >> A najlepiej żeby po jakimś patchowaniu uname -r pokazywał jakieś >> 2.4.22-UNSTABLE. > > Ale co to zmieni? To tylko nazwa. To po co jest ta nazwa, jeśli to tylko nazwa ? Myślę że nazwa o czymś mówi, pełni rolę np informacyjną, a czasem (a fu!) marketingową, kiedy to rozwój dokonuje się przez zmianę numerka. Przykład: często podchodzę do kompa którego nie znam, ktoś zgłasza mi, że ,,komputer nie działa''. lsmod pokazuje całą masę modułów, tak się składa że nie znam nazw wszystkich poprawnie działających. Podchodząc do kompa chiałbym wiedzieć, czy jest to pure-linux, czy jakaś kaszanka zmielona z patchów i binarek niewiadomego pochodzenia. Chciałbym zobaczyć czy po wgraniu jakiegoś modułu nazwa nie zmienia się ze STABLE na UNSTABLE, ot taka potrzeba. -- Grzegorz Bajson
Re: Dziesiatki procesow: /USR/SBIN/CRON
Author: Krzysztof Krzyżaniak
Date: Thu, 06 Nov 2003 10:30
Date: Thu, 06 Nov 2003 10:30
77 lines
4096 bytes
4096 bytes
Pewnego dnia, a było to Thu, 6 Nov 2003 07:44:36 +0000 (UTC), przyszła do mnie
wiadomość z adresu <gbajson@elka.pw.edu.pl> i powiedziała:
> Nie wyraziłem się dosyć jasno.
> Akurat z przetłumaczeniem sobie poradziłem ;), chodziło mi raczej o
> filozofię takiego postępowania. Szczegóły poniżej.
>
>> [*] Pytaj o rozwojowe i/lub niekompletne kody/sterowniki
>
> IMO moglo by to się nazywać:
> [*] Unstabling kernel, using untested and/or uncompleted features
To tylko nazwa. Niezależnie jak się to będzie nazywać będzie działać
tak samo.
W 2.6 masz do wyboru
[*] Prompt for development and/or incomplete code/drivers
[*] Select only drivers expected to compile cleanly
[*] Select only drivers that don't need compile-time external firmware
>> No dobrze. Jest tak, że gdy kernel ma określoną funkcjonalość jest
>> uważany za stabilny. Ale stabilny oznacza też najczęściej
>> przestarzały.
>
> Do tego zmierzam. Jaki procent użytkowników nie zaznacza omawianej opcji
> przy konfiguracji jądra ?
Jaki procent użytkowników kompiluje kernele?
> Innymi słowy, wielu użytkowników w zasadzie używają stabilnej wersji jądra
> (a jakże 2.4.x), ale równocześnie używają wynalazków nie-do-końca
> wytestowanych, czy nawet nie-do-końca napisanych.
Taka karma.
> Uważam że dobrym pomysłem byłoby pozostawnienie tej całej funkcjonalności
> w gałęzi 2.3.x (2.1.x; 2.5.x; itd.) i usunięcie jej ze ,,stabilnych''
> wersji.
A ja uważam, że to byłby kiepski pomysł hamujący rozwój.
>> Dlatego też możesz sobie włączyć kod/sterowniki które
>> pewnie będą pełnić przypisaną im funkcję ale robisz to na własne
> ~~~~~~~~
>> ryzyko (de facto i tak cały kernel używasz na własne ryzyko ale to już
>> inna inszość).
>
> Pewnie tak. I wogóle całego linuksa używam na własne ryzyko (a jakiego
> systemu nie?). Bo pewnie będzie działał, ale czy będzie działał pewnie?
Mniej więcej na tyle ile reszta.
> Piszę to wszystko dlatego, że co jakiś czas spotykam się z reakcjami
> różnych użytkowników, którzy włączają na masę różnych dodatków, 4
> patchów, i 10 patchów na patche, żeby to wszystko dało się skompilować.
> Później im się to wysypuje; dzowonią, piszą, spać nie dają, krzyczą
> jaki ten Linux jest do dupy, bo ,,nie działa'' mimo że używają stabilnej
> wersji -- i weź im za każdym razem tłumacz.
Wystarczy raz: "Grzebiesz na własne ryzyko".
> Uważam, że podczas zaznaczania jakiejś niewytestowanej funkcjonalności,
> zakładania patchy, etc, powinno być jasno i wyraźnie napisane, że możemy
> się liczć z jakąś niestablilnością.
To jest napisane, w helpie do tej opcji.
> A najlepiej żeby po jakimś patchowaniu uname -r pokazywał jakieś
> 2.4.22-UNSTABLE.
Ale co to zmieni? To tylko nazwa.
eloy
--
-------e-l-o-y-----------e-l-o-y-@-t-r-a-n-s-i-l-v-a-n-i-a-.-e-u-.-o-r-g------
jeżeli nam zabraknie sił zostaną jeszcze morze i wiatr
Re: Dziesiatki procesow: /USR/SBIN/CRON
Author: Krzysztof Krzyżaniak
Date: Thu, 06 Nov 2003 11:50
Date: Thu, 06 Nov 2003 11:50
93 lines
4837 bytes
4837 bytes
Pewnego dnia, a było to Thu, 6 Nov 2003 09:55:13 +0000 (UTC), przyszła do mnie
wiadomość z adresu <gbajson@elka.pw.edu.pl> i powiedziała:
[..]
>>> Do tego zmierzam. Jaki procent użytkowników nie zaznacza omawianej opcji
>>> przy konfiguracji jądra ?
>>
>> Jaki procent użytkowników kompiluje kernele?
>
> Z mojego otoczenia i chyba reprezentatywnej próbki (znajdzie się ze 100
> osób), to jakieś 99% ;).
Rzekłbym, że bardzo niereprezentatywna :-> Ja na większości maszyn
używan standardowy kernel z paczki. Tylko na jednym sobie kompiluje 2.6.
>>> Uważam że dobrym pomysłem byłoby pozostawnienie tej całej funkcjonalności
>>> w gałęzi 2.3.x (2.1.x; 2.5.x; itd.) i usunięcie jej ze ,,stabilnych''
>>> wersji.
>>
>> A ja uważam, że to byłby kiepski pomysł hamujący rozwój.
>
> W jaki sposób hamowałoby to rozwój ? Podaj przykład.
Rozwój kernela odbywa się też przez testowanie i zgłaszanie błędów.
Jeśli nie będzie tych opcji w "głównym" kernelu to ludzie nie będą ich
testować i nie będą zgłaszać błędów.
>>>> Dlatego też możesz sobie włączyć kod/sterowniki które
>>>> pewnie będą pełnić przypisaną im funkcję ale robisz to na własne
>>> ~~~~~~~~
>>>
>>> Pewnie tak. I wogóle całego linuksa używam na własne ryzyko (a jakiego
>>> systemu nie?). Bo pewnie będzie działał, ale czy będzie działał pewnie?
>>
>> Mniej więcej na tyle ile reszta.
>
> Nie zgodzę się z tym.
> Akurat z funkcjami z ,,unstable'' miewam często problemy, działają (nie
> działają?) o wiele gorzej od części ,,stable''.
> Przykłady? Nieszczęsne ACPI. Nie wiem czy wina leży w kiepsko napisanych
> modułach, czy w źle implementowanym sprzęcie, ale na niektórych płytach
> po prostu lecą paniki.
Raczej w specyfice ACPI.
> Inna sprawa trochę ze sterownikami odstarczanymi od producentów, zazwyczaj
> są źle popisane (np karta ISDN przestaje działać, kiedy działa karta
> dzwiękowa, i inne tego typu historie; panicujące winmodemy, urządzenia nie
> działające przy włączonym seti@home...). Chciałbym żeby w trybie STABLE
> kernel zabraniał ładowania tego szajsu.
To byś miał telefony "dlaczego się mi to nie chce załadować".
>
>> To jest napisane, w helpie do tej opcji.
>
> Fakt jest, i nawet czytałem, ale praktyka wskazuje że niewielki % bierze to
> sobie do serca. A mi spać nie dają !
Bierz pieniądze za porady :-> Przestaną dzwonić.
>>> A najlepiej żeby po jakimś patchowaniu uname -r pokazywał jakieś
>>> 2.4.22-UNSTABLE.
>>
>> Ale co to zmieni? To tylko nazwa.
> To po co jest ta nazwa, jeśli to tylko nazwa ?
Żeby ładnie po zalogowaniu pokazywało, czego używasz :->
> Myślę że nazwa o czymś mówi, pełni rolę np informacyjną, a czasem (a fu!)
> marketingową, kiedy to rozwój dokonuje się przez zmianę numerka.
>
> Przykład: często podchodzę do kompa którego nie znam, ktoś zgłasza mi, że
> ,,komputer nie działa''.
> lsmod pokazuje całą masę modułów, tak się składa że nie znam nazw
> wszystkich poprawnie działających. Podchodząc do kompa chiałbym wiedzieć,
> czy jest to pure-linux, czy jakaś kaszanka zmielona z patchów i binarek
> niewiadomego pochodzenia.
Zgoda, 2.6 daje takie mechanizmy (między innymi zapisywanie .config w
/proc/)
> Chciałbym zobaczyć czy po wgraniu jakiegoś modułu nazwa nie zmienia się ze
> STABLE na UNSTABLE, ot taka potrzeba.
Zgłoś pomysł na lkml (najlepiej od razu z odpowiednią łatą :->). Tak to mniej
więcej działa.
eloy
--
-------e-l-o-y-----------e-l-o-y-@-t-r-a-n-s-i-l-v-a-n-i-a-.-e-u-.-o-r-g------
jeżeli nam zabraknie sił zostaną jeszcze morze i wiatr
Usunięcie Experimental ze stabilnej gałęzi jądra (było o CRONie)
Author: Grzegorz Bajson
Date: Thu, 06 Nov 2003 12:01
Date: Thu, 06 Nov 2003 12:01
24 lines
2306 bytes
2306 bytes
>> W jaki sposób hamowałoby to rozwój ? Podaj przykład. > > Rozwój kernela odbywa się też przez testowanie i zgłaszanie błędów. > Jeśli nie będzie tych opcji w "głównym" kernelu to ludzie nie będą ich > testować i nie będą zgłaszać błędów. A ileż to błędów jądra ci szarzy użytkownicy Linuksa zgłaszają !?? Wydaje mi się że ci którzy zgłaszają, to akurat skompilowaliby sobie własne własne jądra testowe z tym czego potrzebują, czym się zajmują, i na czym się znają. Ponadto żeby porządnie zgłosić problem to i tak najlepiej byłoby mieć skompilowane jądro z jakimś -DDEBUG. Inna sprawa, że nagle okazałoby się że w stabilnej wersji systemu ukierunkowanego na zadania sieciowe zabrakłoby obsługi np IPv6. Pewnie istnieje powód dla którego ten i inne ficzery są experimental. Może by się ktoś wreszcie nimi zajął żeby porządnie je napisać/wytestować i przenieść do gałęzi STABLE ? Obawiam się że w tym świecie dużych pieniędzy i napiętych terminów po prostu przeniesionoby to do stabilnej gałęzi bez dodatkowych ceregieli. No ale to pesymistyczne spojrzenie ;) Grzegorz Bajson
Re: Usunięcie Experimental ze stabilnej gałęzi jądra (było o CRONie)
Author: Miros/law L. Baran
Date: Thu, 06 Nov 2003 13:54
Date: Thu, 06 Nov 2003 13:54
14 lines
1488 bytes
1488 bytes
PT Grzegorz Bajson pisze:
[rzeczy nieistotne, ciach]
NTG
Jubal
--
[ Miros/law L Baran, baran-at-knm-org-pl, neg IQ, cert AI ] [ 0101010 is ]
[ BOF2510053411, makabra.knm.org.pl/~baran/, alchemy pany ] [ The Answer ]
Death is life's way of telling you you've been fired.
-- R. Geis
Re: Usunięcie Experimental ze stabilnej gałęzi jądra (było o CRONie)
Author: Krzysztof Krzyżaniak
Date: Thu, 06 Nov 2003 13:54
Date: Thu, 06 Nov 2003 13:54
44 lines
3094 bytes
3094 bytes
Pewnego dnia, a było to Thu, 6 Nov 2003 12:01:12 +0000 (UTC), przyszła do mnie
wiadomość z adresu <gbajson@elka.pw.edu.pl> i powiedziała:
>>> W jaki sposób hamowałoby to rozwój ? Podaj przykład.
>>
>> Rozwój kernela odbywa się też przez testowanie i zgłaszanie błędów.
>> Jeśli nie będzie tych opcji w "głównym" kernelu to ludzie nie będą ich
>> testować i nie będą zgłaszać błędów.
>
> A ileż to błędów jądra ci szarzy użytkownicy Linuksa zgłaszają !??
Sporo, przejrzyj sobie archiwa lkml.
> Wydaje mi się że ci którzy zgłaszają, to akurat skompilowaliby sobie własne
> własne jądra testowe z tym czego potrzebują, czym się zajmują, i na czym się
> znają. Ponadto żeby porządnie zgłosić problem to i tak najlepiej byłoby
> mieć skompilowane jądro z jakimś -DDEBUG.
Nie. Zwykle wystarczy wysłanie oopsa i odpowiedzene na kilka pytań.
> Inna sprawa, że nagle okazałoby się że w stabilnej wersji systemu
> ukierunkowanego na zadania sieciowe zabrakłoby obsługi np IPv6.
Na przykład.
> Pewnie istnieje powód dla którego ten i inne ficzery są experimental.
> Może by się ktoś wreszcie nimi zajął żeby porządnie je napisać/wytestować i
> przenieść do gałęzi STABLE ?
Weźmy się i zróbcie? :-) to nie działa niestety. Tu obowiązuje zasada
'Nam działa'.
> Obawiam się że w tym świecie dużych pieniędzy i napiętych terminów po
> prostu przeniesionoby to do stabilnej gałęzi bez dodatkowych ceregieli.
> No ale to pesymistyczne spojrzenie ;)
W świecie dużych pieniędzy i terminów producent sam Ci przygotowuje
kernel i umowę z tysiącem paragrafów zabraniających dotykania ustawień.
eloy
--
-------e-l-o-y-----------e-l-o-y-@-t-r-a-n-s-i-l-v-a-n-i-a-.-e-u-.-o-r-g------
jeżeli nam zabraknie sił zostaną jeszcze morze i wiatr
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads