🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

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
#340
Author: Artur Hefczyc
Date: Wed, 05 Nov 2003 07:26
22 lines
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
#341
Author: m.mazurek
Date: Wed, 05 Nov 2003 08:25
18 lines
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
#342
Author: Grzegorz Bajson
Date: Wed, 05 Nov 2003 19:02
14 lines
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
#343
Author: Krzysztof Krzyżaniak
Date: Wed, 05 Nov 2003 20:16
28 lines
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
#351
Author: m.mazurek
Date: Wed, 05 Nov 2003 20:18
22 lines
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
#344
Author: Grzegorz Bajson
Date: Thu, 06 Nov 2003 07:44
48 lines
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
#345
Author: Grzegorz Bajson
Date: Thu, 06 Nov 2003 09:55
70 lines
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
#350
Author: Krzysztof Krzyżaniak
Date: Thu, 06 Nov 2003 10:30
77 lines
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
#346
Author: Krzysztof Krzyżaniak
Date: Thu, 06 Nov 2003 11:50
93 lines
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)
#347
Author: Grzegorz Bajson
Date: Thu, 06 Nov 2003 12:01
24 lines
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)
#348
Author: Miros/law L. Baran
Date: Thu, 06 Nov 2003 13:54
14 lines
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)
#349
Author: Krzysztof Krzyżaniak
Date: Thu, 06 Nov 2003 13:54
44 lines
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