Call for hardware (pld3.0 Wc)

Andrzej Krzysztofowicz ankry w green.mif.pg.gda.pl
Wto, 15 Cze 2004, 17:21:54 CEST


Andrzej Zawadzki wrote:
> Andrzej Krzysztofowicz wrote:
> > Andrzej Zawadzki wrote:
> > 
> >>Andrzej Krzysztofowicz wrote:
> >>
> >>>Mylisz kolejnosc. Najpierw okreslmy _co_ chcemy osiagnac 
> >>
> >>Kompromis?
> > 
> > 
> > Kompromis musi miec najpierw swoja materie.
> > Dyskusja o wywalaniu bez okreslenia celu tegoz jest absurdalna.
> 
> Zgadza się, tylko, że od dawna czyta się na listach o problemach 
> sprzętowych...

Zgadza sie. Ale akurat najczesciej dotycza egzotycznego sprzetu lub dyskow.
Maszyn ix86 ZTCP nigdy nie brakowalo.

Przestrzen dyskowa tez jest, tylko nie zawsze tam, gdzie potrzebna i nie
zawsze na takim sprzecie, jaki jest mozliwy do obsluzenia.

> > IMO nie ma przeciwskazan, zeby pakiety pentium4.rpm sie pojawily, jesli
> > bedzie na to zapotrzebowanie.
> 
> Jest, tylko czy będą zasoby...

No wlasnie nie do konca zalapalem: czy maja byc osobne pentium4.rpm, czy
i686.rpm optymalizowane pod p4, czy jedno i drugie?

> > Nie widze tez przeciwskazan wobec optymalizacji i686 na p4, jesli zwiazana z
> > tym strata wydajnosci na PPro nie bedzie powazna.
> 
> Kto ma PPro - może przetestować. Poza tym: jeśli nawet spadnie o 2% na 
> 50 maszynach to ja i tak wolę 8% na 500 maszynach...

Kto ma _produkcyjne_ PPro nie zawsze ma "mozliwosci techniczne" wykonania
testu.

> Ale pewnie, że najlepiej mieć osobne arch...
> 
> >>>Ja akurat na przenosnym dysku mam system i386. I mam tam GNOME.
> >>>Bo uzywam go i na starej 486 i na Celeronach...
> >>
> >>Tylko, że ktoś pisał o problemach z kompilacją na i386.
> > 
> > To tego, co sie nie skompiluje - po prostu nie bedzie. Jakis duzy problem ?
> 
> Nieprawda! Zawsze jest dociekanie i burzenie, że czegoś tam nie ma...

To bedzie i sie wyjasni.
Tu RM podejmuje decyzje.

> Ale jeżeli będą zasoby to czemu nie - o ile ktoś będzie robił...
> 
> Dużo zależy od zasobów...
> 
> >>A w Twoim przypadku i486 jest optymalne - co właśnie Mariusz i Marcin 
> >>proponują.
> >>
> >>Czy naprawdę ktoś ma X na 386? Chyba tylko dla zabawy...
> > 
> > 
> > /me uzywa X z i386.rpm Dla wygody.
> > Jak wsadze do maszyny 386 to mi system wstanie - proste.
> > 
> > Jak bede do systemu i386.rpm musial dosnstalowac Xserwer i486/i586/i686.rpm,
> > to sie z tym pogodze. Acz bedzie to pewna niedogodnosc.
> > 
> > Natomiast jak mi nie wstanie sshd czy xdm, bo ktos go skompiluje pod p4, to
> > sie delikatnie mowiac wkurze.
> > 
> > [...]
> > 
> >>Prędkość to chyba nie jest duży problem - gorzej z tym, że:
> >>
> >>a na SPARCu się znów wywaliło...
> > 
> > 
> > A co wywalenie i[356]86/zmiana optymalizacji tu pomoze ?
> 
> Zasoby, których podobno brak... A jak nie brak to nie ma problemu...

To jest kwestia polityki. Mozna przeniesc zasoby RA w "gorsze" miejsce
i troche zasobow odzyskac...

> >>>i386 IMO tez powinno zostac, zeby nie skazywac ludzi ze starym/dziwnym
> >>>sprzetem na niebyt.
> >>
> >>Tylko czy im będzie naprawdę potrzebna cała distro, Kurczę jakoś nie 
> >>wyobrażam sobie pracy w X na 386 (kernel 2.6 też ma większe wymagania 
> >>niż 2.2.... Czy nie szkoda czasu?
> > 
> > 
> > Rozwiniesz?
> > W jaki sposob traci sie czas obslugujac zlecenia dla 1 arch wiecej ?
> 
> 1. Jak masz sprzęt to OK - nie ma problemu.
> 2. Jeżeli glibce z patchem na NPTL (i bez 3 miesięcznego kombinowania, 
> specjalnie dla 386) się zbudują i reszta systemu na tym będzie chodzić 
> to też OK - w końcu to Twoja sprawa, że nie będziesz wykorzystywał w 
> pełni możliwości Twojego P4.
> Ale ponawiam: ile jest aktywnego sprzętu typu 386? Nie 486, K5, 
> transmety TYLKO 386!

A 1 nie wystarczy?
+ osoba, ktore ma 1000 innych i chce miec ten sam system na wszystkich?

Ilosc nie musi byc istotna.
Gdyby ilosc decydowala, to bysmy juz nie mieli nic poza x86.

-- 
=======================================================================
  Andrzej M. Krzysztofowicz               ankry w mif.pg.gda.pl
  phone (48)(58) 347 14 61
Faculty of Applied Phys. & Math.,   Gdansk University of Technology



Więcej informacji o liście dyskusyjnej pld-devel-pl