Kedves guruk!

Azt hittem nem kell nagy gurunak lenni ahhoz, hogy valaki
tudja, egy x-bites proci mit jelent.
Mi mar elsoeves informatika eloadason megtanultuk hogy ez a szam
az ADATBUSZ MERETET jelenti. Ennek pedig a programozo altal
latott strukturahoz csak kozvetett koze van.
Peldaul a sebesseg: Egy ketszeres bitszelessegu adatbuszon
ketszer annyi adat megy at egysegnyi ido alatt azonos orajel
mellett.

Regiszterek:
Tobb pelda is van ra, hogy 8 bites procinak 16 bites
adatregisztere van: Z80 vagy 8088.
De peldaul egy Pentium (64-bites) is dolgozhat byteokkal.

Cimzes:
A 6502/6510-es, vagy Z80-as is tudott 2-bytos cimeket kezelni.
(Viszont aki programozott C64-en, emlekezhet, hogy a nullalapos
cimzes gyorsabban futott!)  Es ha jol tudom bar erre nem merek
merget venni: egy Petium se kezel 32 bitnel hosszabb cimeket.

ALU:
Ritka eset, hogy egy 32 bites adatbuszu gephez olyan ALU-t
epitenenek, ami csak 16 bites muveletek tud vegrehajtani.
Egyszeruen ertelmetlen. Viszont peldaul a Z80 8-bites letere
tudott 16-bites osszeadast vegrehajtani, persze lenyegesen
lassabban, mint egy nyolcbitest. Ellentetben a 286-ossal,
ahol ez a ketto ugyanannyi idot vesz igenybe. (mert a 16-bites
adatbusz lehetove teszi az adatok egyideju beolvasasat az
ALU-ba.)


Pelda arra, hogy a programozo altal latott belso felepitesnek
nincs koze ahhoz hogy hany bites a proci:
8088  8-bites
8086  16-bites
Megis ugyanugy programozhatok.
vagy:
80386SX  16-bites
80386(DX) 32-bites (A DX itt annyit tesz: nem SX)
A programozasuk tokeletesen megegyezik.

Tehat megegyszer:
egy processzor x-bites :<=> ADATBUSZA x bites

Ilyen egyszeru.

Udvozlettel: Krisztian

A Linux ingyen van (termeszetesen :-)). Viszont a kulonbozo CD-forgalmazok
tobbyire hozzatesznek valami extrat, installacios segitseget, tamogatao
dolgokat, ilyesmit (az Yggdrasil pl. technikai tamogatast is iger vagy egy
evig, persze Mo.-rol odatelefonozni nem igazan nyero ;-))...
-- 
 Zoli  (note my old full address @bcuxs2 is retired)
"For my assured failures and derelictions, I ask pardon beforehand of my
betters and my equals in my calling." - Rudyard Kipling

A "bitesseg" vita eleg erdekes, mert vegul is az osszes bit szelesseg
valamilyen hatassal van a processzor sebessegere, nagysagara stb. 
(valamilyen jellemzojere). Vegul is csak az a fontos, hogy a beszelgeto 
partnerek pontosan ertsek, hogy mirol van szo.

A legjellemzobb (es a szo kvalifikalasa nelkul hasznalt) bitesseg az
viszont a cim busz szelessege. A tegnapi levelemben, mar leirtam, hogy
ez miert igy van.



 irja : 

> Szerintem nem a cimbusz szelessege a meghatarozo. a 286 a maga 16 mega
> cimteruletevel 24 bites? (mar megint kenytelen vagyok emlekezetbol
> adatot irni)
>  
> >Ebben az esetben, az hogy hany darab lab van a processzorra illesztve, az
> >teljesen mindegy, mivel adatokat lehet kevesebb labra is multiplexelni es
>  
> A sebesseg es a felepites szempontjabol nem mindegy. A program viszont
> tenyleg semmit se vesz eszre.

A 286-os az tobb mint 16 bites, de hogy pontosan hany bites, azt nem tudom.
Lehet, hogy igazad van es 24 bites. A masodik pontoddal egyetertek, en is
ugyanarra gondoltam.



 irja :

> Hat en moszkvaban ugy tanultam, hogy eppenseggel a cimbusz
> szelessegenek nincs koze ahhoz, hogy hany bites a CPU, annak viszont
> annal inkabb, hogy az aritmetikai egyseg hany bittel tud egyszerre
> elvegezni egy osszeadast (akkoriban meg az osztas-szorzas nem volt
> divatban). Szoval szerintem se a labak szama, se a regiszterek merete,
> hanem az ALU kepessegei...

En pedig azt tanultam, hogy a cim busz szelessege a meghatarozo. Nem
hiszem, hogy ez csak a hideghaboru miatt lenne a Michigani es a
Szovjet meghatarozas "csakazertis" kulonbozo, hanem mas is lehet a
dologban. Nem tudom, hogy mikor jartal az egyetemre, de ha regebben
(7 vagy tobb evvel ezelott), akkor lehet, hogy az akkori Szovjet
processor tervezok szemeben fontosabb volt az arithmetika gyorsasaga,
mint sok adat elerese. Lehet, hogy abban az idoben sokkal kisebb memoria
is elegendonek tunt es ezert mas jellemzovel illettek a gepeket. Ez a 
nezet nem volt tul jellemzo az amerikai tervezokre, mivel az elmult
20-30 ev altalam olvasott irasaiban a bitesseg (ha csak magaban volt
megemlitve), akkor mindig egyertelmuen a cim szelessegre utalt.

A mostani vilagban sem mindig egyertelmu a "bitesseg", mivel a marketing
osztaly altalaban szereti a nagy szamokat es ezzel az igazsagot egy
kicsit elferditeni. Pelda erre a sok uj video jatek, amibol sokat 128
bitesnek illetnek, pedig maga a gep 32 bites sincsen.



Zalka Erno ) reszere :

> Toled pedig azt kerdeznem: a M68000 hany-bites is akkor? Mivel:
> - Regiszterei, aritmetikaja 32-bitesek
> - Effektiv cimei 32-bitesek (ugye, ami alapjan te dontesz)
> - Valojaban azonban csak 24-biten tud cimezni, mert 24 addr kivezetese van.
>   (A Motorola hivatalos dokumentacioja ova int attol, hogy a teljes cimekben
>   emigyen "fennmarado" 8 bitet akarmilyen informacio tarolasara hasznaljuk,
>   legyen mindig $00 - igazuk van).
>  
> Akkor hany bites is a M68000 szerinted?

24 bites. Egyebbkent, a tegnap emlitett IBM 360-as ugyanebba a csapdaba
esett, amit a Motorola egy figyelmeztetessel problat elkerulni; a fennmarado
8 bitbe nem szabad adatot tarolni, mert az a bovithetoseget akadalyozza.
Kerdes : Mit ertesz az effektiv cim alatt ?

> Szinten >-nak: a PDP-11 cimzesi rendszere a kovetkezo:
>  
>       XXXXXXXXXXXXXXXX - 16-bites cim
>     XXXXXXXXXXXXXXXX00 - kiegeszitve 18-ra
> XXXXXXXXXXXXXXXXXX0000 - tovabb bovitve 24-re
> ----------------------
>         <Effektiv cim>

A PDP-11-esrol sajnos nem sokat tudok, csak nehany peldaban emlitettek egy par
konyvben. Nehanyszor karnyujtasnyira is lattam egy par kikapcsolt PDP-11
kasznit egy pinceben.



Udv, -- KRisztian

Kedves kemia-guruk!

Kerlek terjesszetek tanszeketeken, intezetetekben a kovetkezo allashirdetest:
Kosz:

Diana

> ----------------------------------------------

     FACULTY POSITION

     Central European University, Budapest

     The Environmental Science and Policy Department of the Central European
     University seeks to recruit to the following position the post to
     be taken up around 1 January 1996.

     FULL/ASSOCIATE PROFESSOR with a substantial record of research in
     environmental chemistry or chemical engineering, in particular
     pollution associated with industrial activities, and at least five
     years post-doctoral experience.

     The position is full-time and the salary is competitive at appropriate
     international levels.

     The Department is situated in Budapest.  All teaching in the
     University is in English and applicants must be fluent in the language
     and have experience in teaching.

     Applications (2 copies) with a full c.v. and the names of two referees
     are to be sent to the Secretary General, CEU, 54 Huvosvolgyi ut, 1021
     Budapest, Hungary.  Further particulars can also be obtained from the
     Secretary-General's office.

     The closing date for applications is the 24 July 1995.

> ----------------------------------------

Kedves GURUk!

Lenne egy nagyon lamer kerdesem. Adott ket PC ami be van kotve ugyanabba a
lokalis halozatba (NOvell). Mikeppen lehetne azt elerni, hogy:
1. Mindket gep lassa egymas winchestereit?
2. Legalabb az egyik lassa a masiket?
3. File-okat attenni az egyikrol a masikra kozvetlenul, es nem ugy, hogy elobb
   az egyikrol belepek egy serverre, oda lenyomom majd a masikrol is belepek es
   felszedem.
A valaszt lehetoleg nagyon alapszinten kernem (es ha lehet magan mailben
)

Koszonom
Zsolt

Hello GURUK,

Olvasom a GURU-ban:

> Azok a gepek amik 32 bites cimeken keresztul kepesek a memoriat cimezni,
> anok 32 bitesek, amik nem, azok nem 32 bitesek

Ez komoly felreertes. A cimzes szelessegenek semmi koze a 16-24-32-64 bites
gep lenyegehez. A cim vonalak (address lines) szama csak a memoria nagysagat
(real memory) hatarozzak meg. 16 cimvonal 64K-ig tudja a memoriat elerni,
0-tol (64K-1) cimekig. Az hogy azon a cimen hany bit van tarolva, az egy
mas kerdes. Ma majdnem mindig byte cimzesu gepeket epitenek ahol 9 bit
szelessegu (8bit data + 1 parity bit) a cimzett szo. Regebben voltak 16 bites,
32 bites, 64 bites etc szo szelessegu gepek.
 
A cimzett szo, vagy byte tartalma adat vonalakon van elerve (data lines).
Ez elvileg 8+1 line lenne szukseges byte memoria eseten. Mivel a memoria
eleres relative lassu, modern gepek mindig tobb byte-ot hivnak le memoria
elereskor (memory access width). 4, 8, de nagy gepeknel 64, 128 byte az
eleres szelessege. Az elert adat a cache memoriaba tarolodik egy darabig
hatha a cpu keri azt a kovetkezo nehany ciklusban. A cache felhasznalas
optimizalasa (cache replacement policy) es algoritmusai egy kulon tema.

A memory-access-width, bar jelentos egy computer teljesitmenye szempontjabol,
meg mindig nem hatarozza meg hogy egy cpu 16, 32, 64 bites vagy nem.
Ez a csoportositas azon alapul, hogy mikor a cpu muveleteket hajt vegre,
(add, subtract etc.) hany bit-en dolgozik egyszerre. Mivel a legtobb muvelet
igenyel registereket, egy 32 bit-es gep registerei 32 bitesek. Adatatviteli
utasitasok gyakoriak, egy 32 bit-es gep 32 bit-es "bus"-szal rendelkezik.

Memoria eleres lehet 16, 32, 64, 128 etc bit-es, nem ez a meghatarozo.
A memoria cim nagysaga pedig teljesen lenyegtelen, az csak a cpu altal
elerheto maximalis cimet (real address) hatarozza meg. Modern gepek virtual
address-t hasznalnak, ugy hogy ennek nem sok jelentosege van, kiveve hogy
mekkora memoriat tehetsz a gepbe. 
 

Udv

Lou

Kedves Hunyady Istvan es Balogh Mihaly, Krisztian !

  > Ha sok a cimvonal, akkor a fizikai cim kiszamitasa eleg
  > sok idot vehet igenybe, az atvitelek miatt.

  Ez kicsit meredeknek tunik. Alapvetoen igazad lehet, de a gyakorlatban 
  szerintem nem sokat szamithat. Meg kellene kerdezni egy CPU tervezot, milyen 
  gyorsitoaramkoroket hasznalnak a sokbites osszeadasok gyorsitasara...

Szerintem inkabb a kulso dekodolo aramkorok lassithatnak inkabb. Pl
memoria chip, periferia chip kivalasztasa.
A cimkiszamitasnal pedig figyelembe kell venni a logikai cim ->
fizikai cim konverziot is, amely tobb lepcsos is lehet. Pl hiearchikus
lap- illetve szegmens leirok. Ilyen a vedett mod 80386- es 80486-nal,
vagy a Motorola 68020-40-es procik hiearchikus lapszervezese.

  > Ha valahol leallitjuk az
  > atviteleket, akkor valamivel gyorsabb lesz a rendszer: ezen alapulnak a
  > szegmenscimzesek. Persze 486-nal mar erzekelhetetlenek a kulonbsegek.
  > Viszont a 8086-nal szerintem epp ezert vezettek be a dolgot.

Mi ?? Hogy-hogy nincs atvitel ? A szegmensregiszert is hozza kell adni
az adott regiszterhez.

  Szerintem meg azert, mert a 8086-os processzor teljes belso architekturaja, 
  minden regisztere (a programszamlaloja is) 16 bites, ami alapesetben csak 
  64K cimtartomany megcimzeset tenne lehetove, ugyanugy, mint a Z80-nal. Mivel 
  tul akartak lepni a 64K-s cimtartomanyt, ezert bevezettek a 
  szegmensregisztereket, amelyek szinten csak 16 bitesek, de a cimaritmetika 4 
  bittel eltolva hasznalja oket. Ezzel a trukkel a cimtartomany 16-szorosara 
  nott (1 MB).

Igen. Ez mar jol hangzik.

  > Persze, mar a Z80 is ki tudta rakni akar az egesz kepernyot egy utasitas 
  alatt...

  Az LDIR utasitasra gondolsz ? Az csak a programozo szamara egy utasitas, a 
  CPU a gyakorlatban minden byte atvitele utan ujra es ujra eloveszi es 
  vegrehajtja ugyanazt az utasitast (csak annyi a trukk, hogy nem noveli 
  kozben a PC-t). Idoben tehat (tudomasom szerint) nem kulonbozik attol, 
  mintha leirnal egymas utan sokezer LDI-t.

Sot az LDIR meg lassabb is, mint a szamlalo (BC reg)-nek megfelelo
szamu LDI egymas utani vegrehajtasa. OK: a Z80 es altalaban minden
CPU, az utasitas es a hozzatartozo adatok beolvasasa utan mar
aktualizalja a PC uj erteket. Ezert LDIR eseten egy relativ ugrast is
vegrehajt vissza onmagara az LDIR utasitasra. Forras: HT1080Z
assembler cimu, szerintem eleg jo konyv, a szerzore sajnos mar nem emlekszem.

  Kedves Krisztian !

  > Azok a gepek, amik 32 bites cimeken keresztul kepesek a memoriat cimezni,
  > azok 32 bitesek, amik nem, azok nem 32 bitesek.

  Eszerint a 8086-os egy 20 bites processzor. Nem inkabb a belso 
  adatregiszterek szelesseget kellene figyelembe venni ?

En meg azt hallottam az eloadomtol annak idejen, hogy az adatbusz szelessege
hatarozza meg az adott CPU bitszamat, igy Z80, M6510 8 bitesek, 8086,
80286 16 bitesek, 80386, 80486 32 bitesek

  > Ebben az esetben, az hogy hany darab lab van a processzorra illesztve, az
  > teljesen mindegy, mivel adatokat lehet kevesebb labra is multiplexelni es
  > ezaltal a processzor arat lecsokkenteni.

Azonban a multiplexeles lassit: ugyanannyi adat kevesebb labon jon ki,
mintha nem multiplexel a CPU. Peldak multiplexelesre: adat es cim,
adat also-felso resze, stb.

  Egyetertunk, kiegeszitesul annyit, hogy nem annyira a processzor, mint 
  inkabb a kulso aramkorok aranak csokkenese a lenyeges.

Sot az elterjedt kulso aramkorok is.

  Udvozlettel:
  Hunyady Istvan

UDV
Gabor

Az a benyomasom, hogy Kolonits es Barczi elbeszelnek egymas mellett. Zoltan 
kicsit hercigeskedik es bajos, apro programocskakrol beszel amit Imre 
"industrial  strength" programokkal hasonlit ossze.
Zoltan irja:
>> Ha a programozo csak tiz percet raszant
>>az overlay csoportok kialakitasara, akkor ilyen modon viszonylag keves
>>folosleges szemetet toltott be az overlay. 
Tetel: olyan programot, amit 10 perc alatt optimializalni lehet, nem erdemes 
optimalizalni.
Sejtes: valoszinuleg futtatni sem.
=========
Imre:
> vegyuk eszre, hogy nem a kod, 
> hanem az adatok swappelese a kritikus. A kod merete ugyanis azert egy 
> megaba mindig elfer 
Hm?! Maradjunk abban, hogy van amikor a program nagy, van amikor az adat
es van amikor mindketto. (Adatot azert mindig strapasabb swappolni, mert 
amilyen aljas,  valtozik es ki kell irni. Program bezzeg -nem ugy, mint 
a regi szep 8-16 bites idokben, ugye Zoltan?- nem irja magat felul.)
===========
>>  Illetve meg van: manapsag minden valamirevalo programozo az objektum-
>>orientalt divatot koveti (mas kerdes, hogy tudja -e mit csinal :-)
>>A modszernek alapveto kovetkezmenye, hogy az objektum osszes eljarasa,
>>a gyakran es sohasem hasznaltak, egymas melle kerul a programban.  Vagyis

>Ketfele ember van, az egyik tudja, hogy mi az az objektum-orientalt
>programozas, es hasznalja is azt, a masik tipus pedig ezen elobbi
>nepcsoportot cikizi es szidalmazza,

Es ha szabad hozzatennem: es nem tudja, hogy mirol beszel.

Semmilyen (altalam ismert) OO modszernek nem "alapveto kovetkezmenye", hogy
legyen az objektumnak "sohasem hasznalt" modszere. Zoltan osszekeveri az OO
programozast a linkelessel (statikus vagy dinamikus) es (ez inkabb jogos) a
forras kod karbantartasaval. Kozepes (1millio sor) es annal nagyobb 
programokhoz igen sok analizalo eszkozt hasznalunk, mint pl. "code coverage" 
es "execution path" analiziseket. (Az elobbi a tobbi kozott ki fogja szorni 
a "sohasem hasznalt" eljarasokat.) A tudomany mar ismer olyan modszereket, 
amivel egy objektum (gasp!) tobb fajlban lehet implementalva. Hol/hogyan 
hintunk el "inline" kodot egy masik muveszet. Azt, hogy mi van "gyakran" 
es "ritkan" hasznalva, igen konnyu megallapitani. Sot, meg azt is
konnyu elerni, hogy ezek *ne* legyenek egymas mellett. ... de ez nem 
feltetlenul kivanatos! (Pl, ha egy ciklust inicializalok, utana a ciklus fut 
10,000-szer es utana terminalok, az inicializalo es terminalo rutinok 
10,000-szer 
ritkabban fognak futni, mint a ciklus. Es *megis* lokalisan akarom oket tartani
 
-- *kiveve* ha a ciklus magja emiatt swappolodik, amikor nem -- *kiveve* ha a 
ciklus magja amugy is swappolodna, mert akkor a lokalitas legalabb egy swappot 
megsporol -- etc, etc.)

Es most meg csak "hagyomanyos" nyelvekrol beszeltunk; nemsokara lesznek
"idustrial strength" CASE tool-ok, ahol a forras kodot esetleg soha nem is 
latod, stb.

Szoval tobb dolgok vannak... (Talan az Imre altal emlitett C magazinokbol mast 
is kene olvasni, nem csak az editorial-t?)
===================
Gyorsan a CD-rol.
Gergo az en eredeti "pongyolasagomba" kotott bele, amikor azt mertem irni, hogy
"vegyel linux-ot". A dolog (szandekosan?) ki lett ragadva szovegkornyezetebol.
A lenyeg az, hogy ipari (tehat nem magan es nem kutato) kornyezetben 
tetszoleges operacios rendszer ara gyakorlatilag nulla. Az, hogy a Warp kerul 
200 dollarba, vagy a linux, senkit nem erdekel (valoszinuleg meg az ibm-et sem,
 
majd megtudom.) ["ar"-on termeszetesen az (OS ar) / (applikaciok ara + 
karbantartas 
es kepzes + hadware ar) tort erteket ertem.] Ezert voltam bator azt allitani, 
hogy a 
tervezett applikaciok kell hogy csovaljak az OS-t es  nem forditva. Az ingyen 
lunix 
tul van lihegve.

a JaJo

Zalka Ernonek Hunyady Istvan-t es Balogh Mihalyt idezem:

>>Eszerint a 8086-os egy 20 bites processzor. Nem inkabb a belso
>>adatregiszterek szelesseget kellene figyelembe venni ?

>>Szerintem nem a cimbusz szelessege a meghatarozo. a 286 a maga 
>>16 mega cimteruletevel 24 bites?

Ez eddig a legjobb erv. De mindenki mas is ezzel ert egyet, ugy latom.

Lajber Zoltan irja:

>>1, ugy tudom, winNT-n egy alkalmazoi program nem banthat fizikai memoriat,
>>de a device driverem hogy tud egy meghatarozott fizikai memoriacimet
>>lefoglalni, irni/olvasni, felszabaditani?

Fogalmam sincs, de tippelek: A megfelelo DPMI hivason keresztul kell
csinalni, bar nem tudom, hogy van-e API hivas, ami megfelel a DPMI 
hivasoknak. Ha nincs, akkor a DPMI service interruptot kell hivogatni.

>>2, Hogy lehet ugyanezt megcsinalni win3.11/win32s alatt? van kernel szintje
>>a win32s-nek is, vagy kizarolag win driverrel?

Szerintem ugyanugy.

Egyebkent nem vesztem el, Zoltan, nemsokara valaszolok!!

Balogh Mihaly irja:

>>Ha tenyleg a sebesseget tekintenek egyetlen jellemzonek, akkor de szep
>>volna minden...

A dominans jellemzo szerintem igenis a sebesseg.

>>A hatekonyabb program szerintem azt jelenti, hogy kevesebb utasitas
>>vegrehajtasaval hozza ki ugyanazt az eredmenyt. Nem a programban szereplo

Mondtal egy definiciot a 'hatekony program' es az 'utasitasciklus'
kifejezesekre,
nem mondom azt, hogy nem helyesek, mert nem tudom, de azt gondolom, nincs
sok ertelmuk. A hatekonysagnak ugyanis semmi koze a definiciod szerint 
a sebesseghez, akkor meg milyen jellemzore utal a hatekonysag? (Tegnapelott
is ugyanezt kerdeztem.)

>>Ezt a fogalmat ujabb gepeken nehezebb megfeleloen ertelmezni: hasonlo a
>>helyzet, mint az utasitasciklusnal. Erre lehet pelda az altalad felhozott
>>utasitaspar is. (nem neztem utana)

Nyugodtan utananezhetsz.

>>Altalanossagban azonban elmondhato, hogy ugyanazon a gepen egy hatekonyabb
>>program gyorsabb is.

Eppen erre hoztam ellenpeldat, de akkor meg egyszer: a 486-oson vannak 1 es
kozel
100 orajeles utasitasok is, azaz az utasitasok vegrehajtasi ideje annyira
kulonbozo
lehet, hogy tovabbra sem sok ertelmet latom ennek az utasitasciklusos mokanak.

>>Az 'erzekelhetetlen' szot azert hasznaltam, mivel meg nem lattam a 486-rol
>>idodiagrammot. Lehetsegesnek tartom, hogy ott is van kulonbseg egy egyszeru
>>es egy bonyolult cimzesmodu utasitas vegrehajtasa kozott.

Semmikeppen nem beszelhetunk olyan kulonbsegrol, aminek nem egy orajel 
a mertekegysege. A CPU az szinkronban jar, nemde? Az, hogy a cimzesmodok
kozott van kulonbseg, az normalis, orajelben kifejezheto kulonbseg, nem pedig
valami 'ismeretlen' idodiagrambol kiderulo kesleltetes.

>>Erdekes. Szerfolott sok programot lattam mar, ahol a pontkirakasra kulon
>>rutint irtak. Melyik modszer az altalanosabb?

Lehet igy is, meg ugy is, de azert olyan programok, ahol gyors kepernyofrissite
s
kell (pl. a jatekok) nem cimezgetnek pontokat, hanem egybefuggo teruleteket,
sokszor az egesz kepernyot egyszerre rakjak ki, es ekkor el az ido, amit irtam.

>>A programok sebessegenek novekedese nem koveti a processzorok sebessegenek
>>novekedeset.

Persze hogy nem, mert egyreszt sokkal tobb funkciot gyomoszolnek be a 
programokba, masreszt a hardver bizonyos elemei (pl. memoria, hattertar) nem
lettek
annyival gyorsabbak, mint a procik.

Udv,

Imre

A tegnapi nepszabiban olvastam a szamitastechnikai 'ipar'
jelen pillanatban legbiztatobb hiret:

oktoberre halasztottak a win95 szallitasat!!!!!!

Imre

Szasztok!

Valaki nemreg ajanlott 286-ba RAMot, de sajnos a cime nincs meg.
"Speci RAM wanted" cimu irasomra valaszolt.
Ha a vonalban vagy legyszi irj.
Koszi.

Szasztok!

Valaki nemreg ajanlott 286-ba RAMot, de sajnos a cime nincs meg.
"Speci RAM wanted" cimu irasomra valaszolt.
Ha a vonalban vagy legyszi irj.
Koszi.

> Ha valaki el tudna magyarazni, hogy lehet ugy ftpzni, hogy ne kelljen megvarn
i,
> 
> orokre halas lennek. (vmi .netrc-vel kell+nohup)
>     Koszi
>         -= Ha Kap Eszi =-

    En nem hasznalok .netrc fajlt, de ha nagyon akarod, lehet:
    
    van egy x jogos fajlom (mondjuk doftp) a kovetkezo tartalommal:
    
    nohup ftp -nv ftp.ahova.akarod <ftpdo >pofazmany
    
    
    az ftpdo fajlban pedig:
    
    user ftp thulya@
    cd /pub/itt/is/oda/ahova/akarod
    bin
    prompt
    get amit.akarsz
    mget *.*
    bye
    
    
    Ha meg tetezni akarod az egeszet, hogy akkor induljon el, amikor
    kicsi a forgalom, akkor hasznald az "at" parancsot. A "man at"
    utasitast ajanlom ezzel kapcsolatban.
                                                    Thulya

In article >,  (Madarasz Ge
rgely) writes:
>>> Ki az a <oncenzura>, aki VESZ linuxot?!? ;-)
>>
>> En. Megeri nekem, hogy megvan a CD a polcomon, ahelyett hogy
>> tobb tucat floppy-t masolgatnek es cipelnek haza.
                                               ^^^^^<<<<<<<<<<<<<<<<
>> Meg ismerek masokat is. Akiknek az ido penz.
>
>> Gabor az onceruza
>
>Bocsi, azt hiszem kicsit elhamarkodottan irtam... Mellesleg en nem
>masolgatok tobb tucat floppyt, ha linuxot akarok installni, ilyenkor kettot
>hasznalok: root, es boot... nfs-rol igazan kenyelmes az installalas,

Jo neked, ha hazaig er az NFS! Mekkora savszelesseged ven? 64k? 2M?

>kulonosen mivel igy mindig a legujabb slackware-t tehetem fol...
>A CD-vel az a bajom, hogy (szerintem) nem eleg friss, draga (nem
>nagyon keresgeltem eddig, de egyszer lattam egy boltban linux CD-t 6000
>Ft-ert! szerintem pofatlansag ennyit kerni), valamint nincs CD meghajtom

Nem az Infomagic dupla albuma volt az osszes GNU forrassal,
tsx-11 es sunsite snapshot-tal? Nem olyan sok az.... Csak nem eleg friss.

Gabor

In article >,  (Simon Jozsef) writes:

> A file-ok lehozatalat PC-rol vegzem, hol az FTP programmal, hol
> kulonbozo Windows alatt futo FTP programokkal, vagy Minuettel.
> Ha ez a modszer "olcsobban" meguszhato Unix gepen, arra is van
> lehetosegem, csak nem eppen nagyfoku Unix ismereteimrol vagyok
> hires.

Van egy remek PERL-ben irott program, ami pont erre valo.
Mirror a neve.

AVAILABILITY:
The latest version of mirror is available from:

	src.doc.ic.ac.uk [146.169.2.1]
		directory: computing/archiving/mirror
		(shortcut packages/mirror)
	
        ftp.th-darmstadt.de [130.83.55.75]
        	directory: pub/networking/mirror


	ftp.sun.ac.za [146.232.212.3]
		directory: pub/unix/packages/mirror

De nyilvan tobb helyen is megvan.

Gabor

>Nem vagyok benne biztos, de azt gondolom, hogy aki a Linux CD -t
>megvette az nem vette meg a Linux -ot. Ezt abbol gondolom, mert ugy
>tudom, hogy a Linux -ert mint programert _TILOS_ penct kerni, a
>mediaert vagy a masolasert lehet. Ha tehat walaki megveszi a Linux
>CD(ket), amik annyira olcsoak, hogy csak tenyleg a korong ara lehet
>bennuk, nem vasarol programot. Ilyen okbol tenyleg nem lehet massal
>operencias rendszerrel osszehasonlitani, mert ingyen van!
> Azt viszont nem egeszen tudom, hogy a Linux milyen esetekben
>(uzleti eletben is?) hasznalhato ingyen. Talan megerne Linux
>telepitessel foglalkozni, hiszen a program ingyen van? :)

Ezek szerint nem olvastad meg a GPL-t, ami (tobbek kozott) a Linuxra 
is ervenyes...
Nyugodtan eladhatod a Linuxot, mint oprendszert, annyiert, amennyit 
nem szegyelsz kerni erte, azzal a feltetellel, hogy akinek eladod, 
annak is ugyanolyan jogai lesznek a szoftverrel kapcsolatban, mint 
neked, tovabba ha az illeto keri, oda kell adnod a forraskodot is.
Ebbol az is kovetkezik, hogy barmilyen celra hasznalhato a Linux.
Sot, ha akarsz, penzert technical supportot is nyujthatsz Linuxra.

Egyebkent javaslom mindenkinek, aki meg nem olvasta, olvassa el a GNU 
GPL-t. Igen tanulsagos... 
(Velemenyem szerint minden letezo oprendszerre a GPL-nek kene 
vonatkoznia....)


Udv:
SzG

I'me a magyarulHOGYAN kezdetleges va'ltozata: (reme'lem gyorsan fejlo"dik majd)
.

> -----------------------------------------------------------------------------

Hungarian HOWTO for linux, coded in iso8859-2, in hungarian.

magyarulHOGYAN, avagy tippek e's tru:kko:k szerencse'tlen magyarul besze'lo"
Linux-felhaszna'lo'knak.

Va'rom az egye'b tippeket (esetleg ke'rde'seket) a  
ci'mre!


TARTALOM

1. Hol e'rheto" el a magyarulHOGYAN?
2. Hogy lehet ra'venni a bash-ot e's a tcsh-t, hogy magyar karaktereket
is elfogadjon?
3. A less magyari'ta'sa
4. Latin-2 (ISO-8859-2) ko'dkioszta's haszna'lata
5. Hol tala'lhato'ak magyar kiege'szi'te'sek linuxhoz?
6. TeX



1. Hol e'rheto" el a magyarulHOGYAN?

ftp.tarki.hu/pub/magyar/linux/magyarulHOGYAN



2. Hogy lehet ra'venni a bash-ot e's a tcsh-t, hogy magyar karaktereket
is elfogadjon?

A ko:vetkezo" sorokat kell bei'rni a dolgozo' saja't (HOME) 
bejelentkeze'si ko:nyvta'ra'ba elhelyezett .inputrc nevu" a'lloma'nyba:

bash haszna'lata esete'n:

------------ itt va'gd ki --------------------
set meta-flag on
set convert-meta off
set output-meta on
------------ itt va'gd ki --------------------

tcsh haszna'lata esete'n (/etc/csh.login, vagy .tcshrc):

------------ itt va'gd ki --------------------
setenv LC_CTYPE ISO-8859-1
stty pass8
------------ itt va'gd ki --------------------



3. A less magyari'ta'sa

Ez nagyon egyszeru".  A megolda's:

------------ itt va'gd ki --------------------
LESSCHARSET=latin1
export LESSCHARSET
------------ itt va'gd ki --------------------

Ezt a ke't sort kell behelyezni a /etc/profile a'lloma'nyba.
(Vagy a .profile-ba).



4. Latin-2 (ISO-8859-2) ko'dkioszta's haszna'lata

A linux rendszermag alapesetben a latin-1-es kioszta'st haszna'lja u'gy,
hogy a latin-1-es ko'dokat leke'pezi a PC-s 437-es ko'dlapra.
Ezzel a mo'dszerrel csak olyan latin-1 betu"ket tud megjeleni'teni, 
melyek szerepelnek a 437-es lapon.  
A latin-2-es ko'dkioszta's haszna'lata'hoz ke't dolog szu:kse'geltetik:
- a karakterke'szlet beto:lte'se (VGA/EGA monitorok esete'n)
- a fent emli'tett leke'peze's a'ta'lli'ta'sa norma'l leke'peze'sre
(betu"ko'd = ke'pernyo"ko'd)

A leke'peze's megva'ltoztata'sa't a ko:vetkezo" parancs ve'gzi el:

echo -ne '\033(K'

A mapscrn paranccsal lehet egye'bke'nt a leke'peze'st a'ta'lli'tani.
A latin-2-es karakterke'szlet beto:lte'se (slackware linux esete'n):

setfont /usr/lib/kbd/consolefonts/lat2-16.psf



5. Hol tala'lhato'ak magyar kiege'szi'te'sek linuxhoz?

almos.vein.hu/ssa/kbd_es_font/:      magyar billentyu"zetkezelo"k e's betu"ke's
zletek
ftp.tarki.hu/pub/magyar/linux/hunlin-0.1.tar.gz:  magyar bill.-kezelo"
  szabva'nyos billentyu"zethez e's lat-2 betu"k

Megjegyze's:
Az almos.vein.hu/ssa ko:nyvta'rat az ftp.vma.bme.hu e's az ftp.tarki.hu tu:kro:
zi.
(Bp-ro"l gyorsabb az adata'tvitel.)


6. TeX

Le'tezik egy magyar elva'laszto'-program TeX/LaTeX ala', a HION.  
Ele'rheto":
 
ftp.digital.bme.hu:HION
ftp.tarki.hu/magyar/TeX/hion.tar.gz

[Egye'b TeX info'?]