Történelmi programnyelvek csoportjait tiltotta ki a Google a Google Groups-ból

Címkék

Alex McDonald küldött be egy támogatási kérelmet a Google Groups Help-re, amiben arról panaszkodik, hogy a Google az elmúlt napokban több Usenet hírcsoportot is kitiltott, köztük a történelmi jelentőségű comp.lang.forth és comp.lang.lisp csoportokat. A Google szerint ezek a csoportok megérettek a ban-ra, mert spam-et, malware-t és egyéb rosszindulatú dolgokat tartalmaztak.

McDonald szerint a Google a történelem egy részét és ezen csoportok kollektív emlékezetét törölte és ez nincs így jól.

A Google reagált a kérelemre azzal, hogy mivel az Usenet hírcsoportoknak nincs tulajdonosuk, így nincs lehetőség fellebbezni sem a döntés ellen. Vannak, akik nem értenek egyet a Google magyarázatával.

Hozzászólások

Minixnek még van szerepe az oktatásban, nem? Bár nem kedveli minden egyetem. Oprén úgy vártam volna egy jó kis Minixet és a hozzá írt könyvet, de nem volt része a tananyagnak. :) 

Azt nem értem miért nem rakta csak read onlyra ezeket a csoportokat?! A spamekre lett volna több megoldás is. Csak az inaktív évek tartalmát törlik, ahol a spamek vannak. Illetve pont a Googlenek elég jó mintafelismerő szoftverei vannak spamre, akár ki is gyomlálhatta volna. 

Amióta telenyomták NetBSD-s cuccokkal, okafogyottá vált a project. Nem tett jót a hírnevének az Intel Management Engine sem.
Le sem fordul, néha jön egy két ifjú titán, megpróbál valamit kezdeni vele, de nem nagy sikerrel.

A 3.0-tól kellene forkolni és tenni bele USB és SATA támogatást. Alkalmatlan mindenre, mert nem hagy a kernel hozzáférni a perifériákhoz, ha szívni akar az ember, ott a NetBSD vagy a linux.

A Z80-as hobbi projetekhez meg túl nagy.

http://plazmauniverzum.hu <> A látható anyag 99.999%-a plazma <>

Őőőő, na szóval! Mert csak olvashatóvá nem tudták volna tenni (nehezen hiszem el)? 

Nem akarásnak nyögés a vége...

Épp ezt akartam írni én is. Minden ilyen Groups téma azért szellemi tartalmat hordoz, nem kéne törölni, az a minimum, hogy olvashatónak kéne maradnia. Elfér, ha a jövőben csak 1 ember is hasznát veszi, már megérte neki tartalmat szolgáltatni. Ekkora szerverparkkal és birodalommal nehogy már a Google-nek ezen múljon, hogy pár plain text GG témát törölnie kelljen, mert nincsen tárhely és sávszélesség. Spam ide, spam oda, kínos az egész.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

jah, a googlenek olyan rohadt nehez aztan kigyomlalnia a spamot, nincs is nekik egy gmail-juk.... :/ meghat eleve, szerintuk sok a spam, akkor azt valahogy detektaltak. eleg lenne az altaluk detektalt spam leveleket kiszorni a RO listabol es kesz.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Lehet, viszont megfigyeléseim szerint az IT művelői számára a múlt általában jóval kisebb jelentőséggel bír, mint a jövő. Gyakorlatilag kijelenthető, hogy egy ezen a területen dolgozó 30 alatti ember számára a számítástechnika múltja nem létezik. Az ő valóságában a Commodore 64 nem történt meg.

Ebből következőleg én csodálkozni ezen a híren nem nagyon tudok.

Amivel csak annyi a bajom, hogy *tudtommal* még a Lispet is használják a világban, és a Sun gépek Forthban programozható boot-loadere mellett a FreeBSD boot-loadere a mai napig Forth-nyelven bővíthetó - még ha jelenleg a Luasítás irányába mennek el) - azaz az, hogy aktívan mondjuk nem a Usenet hírcsoportokban megy róluk az értő társalgás, hanem a stackoverflow-n és társain, az nem jelenti azt, hogy ott nem lenne hasznos / használható infó.

De érteni értem amit mondasz.

30 alatti ember számára a DOS sem történt meg. De amit írsz így teljesen nem igaz. A múlt ugyanis létezik informatikában is. Csak a hobby-múlt és vakvágány múlt lett eltörölve. SUN Microsystems gépeiről mi is tanultunk, elég részletesen. Érintőlegesen mainframekről, DEC PDP-król, VAX/VMS-ről, többi unixról is. Ha úgy tetszik a "komoly" számítógépek múltja nincs eltörölve. Csak az otthoni játék számítógépek merülnek a feledés homályába.

Marhaság. A mai technológia kialakulásához az Intel 8080, 8085, 8086, a Zilog Z80, a 6502, 6510 volt az út, és elég nagy baj, ha valaki agyatlanul programoz, miközben fogalma sincs a számítógép működéséről, szinkron szekvenciális hálózatok tervezéséről. Szerintem, de én ebben szigorú, poroszos elveket képviselek.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Kis ország kis foci. Azok akik már, khm hogy szépen mondjam, régebb óta fiatalok azok számára ez volt a informatika számukra látható evolúciója. ( Úgy tudom a magyar egyetemi oktatás egyébként helyesen kezdetektől kerülte a hobby-számítógépeket, valahogy beszereztek akkori drága unix és vms gépeket és azokon oktattak. Persze nehezebb volt géphez jutni és ennek egyik öröksége a papíron programozás még ma is egyes egyetemeken, ami szerintem qrva nagy f@szság. :) 

Szóval a valódi evolúció : Zuse Z2 - ENIAC - IBM System/360 - DEC PDP-k - Xerox Alto - Vax/VMS - IBM PC - Sun Sparc - Sun UltraSparc - SGI - Windows NT PC(Pentiun Pro-tól) - Linux PC - Linux és Mac ARM

Persze nem teljes a lista és vannak párhuzamosságok, de ezek a gépek jelentik a valódi informatikát. A hobby gépek csak lábjegyzetet képeznek. 

Szerintem hiba kihagyni a hobby gépeket.

Ez kb. olyan, mintha (háháhá) a gépjárművek fejlődését csak a 3000ccm feletti dízeleken keresztül mutatnád be, aminek a vége mondjuk egy haul truck lenne.

A hobby gépeknek garantáltan nagyobb közvetlen hatása volt a világ fejlődésére, mint mondjuk egy PDP-nek. Szerintem az IBM PC-nek legalább két "szellemi őse" volt: 1) az általad sorolt ősvasak 2) a hobby gépek. Utóbbiak mutattak üzleti irányt.

Én már semmit nem tanultam ezekről a gépekről. Egyáltalán nem érzem ennek hátrányát. Archik is az egyetem utolsó féléveiben voltak és nem az elején. Ez is teljesen rendben volt szerintem így.
Van egy csomó tévhit, ami egykor még igaz lehetett ma már viszont masszív önszívatás, ami öreg motorosok fejében keményen berágta magát. Például, hogy a lehető legoptimálisabb programokat assemblyben írják. Ilyenkor gyakran ezek a hobby gépek jönnek példának. Nagyon más ma már az informatika. Ma is van szerepe a 8-bites gépeknek de teljesen más területen más módon, és a 8-bites processzorok is mások. Még ezeket a beágyazott lapkákat sem érdemes assemblyben programozni. 

Hát a fene tudja. A programnyelvemet eredetileg C++ nyelven kezdtem el írni, illetve meg is írtam több változatát abban, de a végén mégis áttértem sima C nyelvre, habár sajnáltam feláldozni a C++ némely valóban kényelmes szolgáltatását. Mégis, így több dolgot tudtam saját magam optimalizálni és ennek igazán jelentős sebességnövekedés lett az eredménye (úgy két és félszeres nagy átlagban, ami semennyire se mondható elhanyagolhatónak).

De még a C nyelv esetén is akadtak esetek amikor rohadtul sajnáltam hogy épp C nyelven programozom és nem valami assemblyben, mert mély meggyőzőfésem hogy úgy még sokkal hatékonyabb kódot írhattam volna. Persze mazochizmus lett volna az egészet assemblyben megírni, ilyen értelemben igazad van. De bizonyos „szűk keresztmetszetek” esetén... Még komolyan gondoltam is rá hogy na ide meg oda esetleg betegyek valami inline assembly blokkot vagy valami más módon azt assemblyben írom meg... Végül kizárólag amiatt vetettem el ezt az ötletet mert a hordozhatóság rovására ment volna. De azóta is néha azon rágódom, jó döntést hoztam-e...

Szóval, igenis a mai csilivili szuperszolgálatkész magasszintű nyelvek nem okvetlenül jók mindenre (mármint, jók, csak messze nem ideálisak...), és igaz hogy abba az irányba megy a „fejlődés” hogy mindent ezeken oldanak meg, de ez a szakma elkurvulása a szememben, s a programozók elkényelmesedése.

Cseppet se helyeslem...

Az lehet hogy én egy fura fickó vagyok a szemetekben, sokszor olyan ötletekkel amik nevetségesek, az is igaz hogy itt-ott lehetnek lyukak a szakmai ismereteimen, de azért határozottan VANNAK ilyen ismereteim, nem is akármilyenek, és ne vegyetek ám mérget arra hogy itt-ott nem tudok sokkal többet mint valami manapság az iskolából kikerülő ifjú titán! Az az egy azonban teljesen biztos, hogy én a magam módján nagyon is TISZTELEM a szakma olyan „nagy öregeit”, akik még tényleg „kis” gépeken kezdték a pályafutásukat. Mert én is ott kezdtem, s emiatt mélyen hiszek abban, aki azokon KELLETT hogy megoldjon egy fogós feladatot, az mesze jobban ismeri a szakmát mint a mai nemzedék akiknek már akármikor van bőven elég memória meg műveletvégző sebesség a munkájukhoz... LEGALÁBBIS AZT HISZIK... (A tesztgépeiken van. Produktív környezetben már nem okvetlenül...)

Egy szavam nem volt a C vagy C++ ellen. A kettő közül a C -t jobban kedvelem. Ennek talán az az oka, hogy előbb tanultam magas szintű nyelveket (Java, C#) és nagyon nem kedveltem C++ -ban az olyan megmagyarázhatatlan hibákat amiknek okát a laborvezető tanár sem értette. C -ben ez nem fordult elő. Szerintem ezek nem fognak eltűnni, mert gépközeli programozási nyelvre továbbra is szükség van. A Java vagy C# biztosan nem fogja kiszorítani. Konkurenciát inkább olyan új nyelvek jelentenek mint a Rust vagy GO. De talán ezek talán valóban jobb alternatívák is. 

Ezek mind architektúra független nyelvek. Az Assembly viszont ezer szállal kötődik a hardveres és mellette persze a szoftveres architektúrához. Jóval tovább tart egy feladat lekódolása és nagyon könnyű hibázni. Multiprocesszorok hatékony kihasználása elég nehéz Assemblyben. És amióta már úgysem azok a kódok kerülnek ténylegesen végrehajtásra a CPU-n amit Assemblyben megírtál a totál gépközeliség is csak illúzió. 

És amióta már úgysem azok a kódok kerülnek ténylegesen végrehajtásra a CPU-n amit Assemblyben megírtál a totál gépközeliség is csak illúzió.

Itt mire gondolsz? Ha olyan a hardware architektúrád, amelyen ez így van, akkor ott valóban nem assemblyben kell programozni. Az assembly épp odavaló, ahol pontosan az fog történni, amit leírtál, ahol az assembly kód és a gépi kód között közvetlen megfeleltetés van.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

    mov cx, 204
    mov dx, 1
    mov al, 1
u1: 
    mov ah, 0ch
    int 10h

    dec cx
    cmp cx, 1
    jae u1

Ez ferde vonal. De valójában egészen biztosan nem ezek az utasítások lesznek végrehajtva a CPU-n, mert már régóta RISC magja van az Intel prociknak, AMD-nek is. RISC-en pedig nincsenek 2 operandusos utasítások. Az órajel növelése miatt is szét kellett törni a bonyolult x86 utasításokat  több, egyerűbb és gyorsabb utasításra. És ott van még a reorder buffer, elágazáskezelés, átnevezési regiszterek. 

Még az egyszerű dekódolók is átalakítják az egyszerű 1db x86 utasítást 1db risc utasítássá. D1 és mis dekódolók pedig 4db vagy több risc utasítássá alakítanak át egy darab x86 utasítást. 

Ebben csúsztatást érzek. A mikroarchitektúra lehet RISC, de kompatibilitási okokból az ősi CISC utasításkódokat kell a CPU-nak végrehajtania, mégpedig kódkompatibilisen. Az a CPU belügye, hogy ezt mikrokódokkal, RISC utasításra bontva, vagy közvetlenül, akárhogy, de meg kell csinálnia. Így hát az assembler nem fordíthat ki magából mást, mint a CISC utasításkódokat, amelyek mnemonikos alakját leírtad. Az persze más kérdés, hogy cache, queue, pipeline-ok miatt aztán a fene sem tudja, hogy a konkrét esetben hogyan hajtódik majd végre. De ez az x86_64 architektúra, egy 8 bites mikrokontroller, amelynek van 35 vagy 48 RISC utasítása, már egészen más világ.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nem hinném, hogy néhány 10 byte RAM, két, esetleg nyolc szintű CPU stack, amelybe adat nem, csak visszatérési cím kerülhet, optimális platform lenne magas szintű nyelvekhez. A C ugyan elég alacsony szintű, de mégis ott van egy bizonytalanság: mit akar, mit fog ebből fordítani a fordító? Sokkal biztosabb assemblyben leírni, amit szeretnél. Nyilván nem PC-re, noha szerintem a Linux kernelben is van assembly kód, ha nem is sok. A másik érdekes kérdés a futásidő. Vannak nagyon valósidejű problémák. Az adat végeláthatatlanul ömlik be a bufferbe, s azzal csinálni kell valamit, mégpedig azonnal. Ez sok esetben megoldható C-ben, de nagyon feszes még így is, ki kell force-olni, hogy változót regiszterbe allokáljon, és hasonlók.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

A mai C fordítók már jobban optimalizált kódot fordítanak mint amit 100-ból 99 assembly programozó közvetlenül megír. Egy egyszerű félda C-ben:

int main(void)
{
int i=10, j=20, k;
k = f1(i,j);
printf("\n%d", k);
return(0);
}

int f1(int x, int y)
{
int k;
k = x + y;
return(k);
}

Ennek az eredménye minden esetben 30 kiírása a képernyőre. Ezt észreveszi a C fordító, ezért végül ezt fordítja belőle:

mov esi, DWORD PTR __imp__printf
push 30
push OFFSET ??_C@_03IOBBOKCP@?6?$CFd?$AA@
call esi

Nem lesz felesleges függvényhívás, futás idejű összeadása i és j -nek, mert az eredmény mindig 30. 

Ez természetesen egy eléggé leegyszerűsített példa volt, amit mindenki észrevenne. De egy összetett programnál már sok felesleges vargabetűt nem vesz észre az emberi szem. Ezért végül az esetek 99%-ában optimálisabb kódot fordít a C fordító, mintha közvetlenül kütyüzné a feladatot valaki assemblyben. 

Programozok mikrokontrollerre assemblyben. Talán nem is az a kérdés, mennyire optimális kódot állít elő a C fordító, hanem az, hogy ellenőrizetlen az egész, nem tudod, hogy mit fordít a forrásból. Ha meg bogarászod az assembly-t, egyszerűbb eleve abban írni, akkor még érthető és logikus is lesz. Elég jól programozok ahhoz assembly-ben, hogy minden további nélkül elteszek két-három változót egy byte-ba, vagy egy változót két byte két-két bitjébe, miközben ezen byte-ok maradék 6 bitjei egy másik és harmadik változók. Hogyan bízzam C fordítóra azt, hogy minden feltételes elágazás órajelre pontosan ugyanannyi idő alatt fusson le? Mert volt ilyenre szükségem, és assemblyben természetesen megoldottam.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ez nagyszerű, csak nagyon nem mindegy a számábrázolási limit, ezért hülyeség ez a koncepció. Ha teszem azt, egy lineáris sztereo wav-ot szeretnék feldolgozni, amelyben 16 bites egészek vannak, akkor bizony erősen jó volna ezt nem belegyűrni egy byte-os int-be, mert nem fér bele, meg 32 bitesbe sem, mert annak semmi értelme.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

De nem is kell ilyet 8-bites architektúrán csinálnod, nem? 

32-biten viszont nyugodtan hagyhatod "veszni" felső 16 bitet. Néha lehet gyorsítani ilyen kettesével rakunk 2x16-bitet egy 32-bites int-be trükkökkel. Bár nem mindig. Nem vagyok ellenne az ilyen fogásnak, amíg nem eredményez átláthatatlan kódot, amit pár év múlva már a program saját írója sem lát át. 

A nyafogásom tárgya az volt, hogy ha leírod azt, hogy

int var;

akkor nem tudod, hogy var hány bites, ami akkor nem túl nagy baj, ha 0-tól 10-ig számolsz benne, de ellenkező esetben akadhat ebből probléma. Sokan - így én is - inkább írják pl. azt, hogy int16_t.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Csak, hogy legyen megint ellenvélemény. Olyan programozási elveket mint például inversion of control vagy dependency injection elég nehezen lehetne megvalósítani assemblyben. Márpedig ha a feladat elér egy komplexitási szintet, akkor ezekkel nagyon sok extra munkát lehet megspórolni. A tisztább kód átláthatóság mellett, kevesebb hibalehetőséget is jelent. 

Az ég szerelmére, a fenti hozzászólásomban nem írtam egy árva szót se az assemblyről!

Én arra gondoltam, a C nyelvet már eredetileg is úgy kellett volna megalkotni hogy a típusok bitmérete (hossza) fix, örök időkre rögzített legyen! És kész. Azaz mittudomén az int mindig 32 bites, a short int mindig 16 bites, etc.

Azt meg hogy hol ennyi meg hol annyi, eleve be se kellett volna venni a szabványba mert bizonytalanságot visz az egész mindenségbe. Akinek nagyon fontos hogy a program lefordulhasson különböző bithosszakkal rendelkező architektúrákon, az ne használjon int-et meg ilyesmit, hanem használja így:

ehelyett:

int valami;

használja ezt:

#define myint int

// ...............

myint valami;

És ennyi az egész...

Igen, ez több energia a részéről, de inkább ő szopjon mint MINDENKI MÁS, hogy jaj most tutira annyi bitet jelent-e ez a deklaráció amennyit eredetileg gondoltam...

Amúgy én is ezt az utat követtem csak fordítva. A programnyelvem forráskódjában nem szerepel unsigned long long (kivéve a printf utasításokat amikor a kiírás érdekében a magam típusát explicit módon erre castoltam) hanem helyette szerepel hogy

usag myvar;

(például)

és egy headerfájlban van rögzítve hogy az az usag típus egy 64 bites unsigned típus.

Holott X86_64 architektúrán dolgozom kizárólag. JELENLEG. Megtehettem volna hogy arra hagyatkozom hogy itt úgyis 64 bites az unsigned long long. De minek kockáztassak és ki tudja mit hoz a jövő...

És minden más típussal így jártam el még a char-ral is.

De nagyon utálom ezt. Illene hogy az ilyesmi a C nyelv szabványában legyen rögzítve. Örök időkre.

Jó régen alkották meg a C nyelvet. Talán nem volt szerencsés így elnevezni, de az arch függő változó ötlete az eléggé új Rust nyelvben is ott van. Valahol érthető, hogy kell egy leggyorsabb típus adott archon akkor is ha ennek az ára az, hogy nem tudjuk az intervallumot. Linux kernelnél jól jön, aminek sok architektúrán működnie kell, optimálisan, mindezt úgy, hogy ne kelljen teljesen külön kódot írni minden processzorra. Azért nem teljesen orosz rulett így sem, mert 32-bit alatt nincs Linux. Ezért annál kisebb bitmérettel biztosan nem kell számolni. 64-bit lehetőségét meg nem kell kihasználni általános programkódnál. 

Nekem C++ nyelvnél sokkal több problémám volt például strcpy_s erőltetésével mint az int-el. 

Van a C és az assembly között is nyelv, azt szeretettel használom.

uint32_t reg;

asm mov [reg], IO_PORT;

 

A regisztert a fordító foglalja le. Az asm képes C változót írni és olvasni. A konkrét szintaxisra nem emlékszem, annyit használom. :)

 

Regiszterek helyett változóneveket használsz.

Nagyon helyesen a fordító dönt.

A C függvények és assembly necces dolog. Hasadra ütött regiszterrel simán felülírhatsz C változókat.

- vagy tiszta C

- vagy tiszta asm, te foglalsz regisztert, de a függvényedben kizárólag asm lehet

- vagy kevert C és asm, de ilyenkor inkább a fordító foglaljon regisztert

 

Nálam eddig csak olyan bug volt, hogy az asm belekontárkodott a C regiszterekbe. Olyan nem volt, hogy a fordító rosszul allokált valamit. A gcc által generált kód ugye erősen verziófüggő, inkább ne piszkálj bele

Ha valaki ilyet ír, fogalma sincs arról, hogy mi volt a Commodore 64. Nem ártana fényesen felvilágosodnod.

 

Légyszíves, menj el a könyvárba, vegyél ki egy Commodore újságot, utána menj ki a körútra és vegyél egy Chip magazint. Megdöbbenéssel fogod tapasztalni a két újság közötti szakmai színvonalbeli különbséget.

Kb. annyi a különbség, mintha a Doom Eternalról értekeznének, vagy a 3D grafikás motorok működéséről.

 

A Commodore 64 időszakában a Next-Next-Go figurákat nem nevezték profi számítógépeseknek. Fizika tanár az otthoni Commodore 64-en, vagy Plus 4-en programot írt, számolt vele. Rengetegen tudtak valamilyen szinten programozni.

Olyan emberek is vannak, akik csak a C64-et ismerik, mert nem képezték magukat tovább. Megrekedtek azon a szinten. Tudni kell, hogy bejött a Microsoft a Next-Next-Go irányvonallal, amit a Chip magazin bőszen átvett, az emberek meg leszoktak a gondolkodásról. Sokan feladták, nem foglalkoznak vele, klikkelnek, Chip magazint olvasnak szabadidejükben.

 

A Commodore 64 bukása után jött az informatika egyik legsötétebb időszaka, ami őrült sok kóklert termelt ki.

Hány informatika tanár tud ma programozni? A C64 idejében gép közelébe sem engedték az ilyet.

 

A Commodore 64 egy múlt, ami nagyon sok tekintetben egészségesebb világot takart, mint ami ma van. Akkor a tudás érték volt, a féltudás nem. A gépek technikailag megerősödtek, az emberek ezzel párhuzamosan épültek le mellettük.

Meg a kevés RAM, rossz bővítőcsati, szar grafikai chip, primitív hang, kevés szoftver. Egy csomó gyengéje volt ZX-eknek. A Z80-as proci nem emiatt volt sikeres, hanem a 8080-s procival és ezzel végső soron a CP/M-mel való kompatibilitás miatt volt népszerű, amíg az x86 + DOS át nem vette a hatalmat.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Na most nagyon a szívemből szóltál!! Hű de nagy pluszegy!

 

Egyetlen példa a saját korszakomból. Programozó voltam egy cégnél. Jött oda valami külsős szoftverfejlesztő muki, hogy eladja a cégnek a (C-64 -re írt) programját. Bemutatta. Az eredményt kinyomtatta, persze egy mátrixnyomtatón, mert akkoriban ugye azok voltak ezekhez a gépekhez. Látom az eredményt, kérdezem tőle hogy miért nem ékezetes betűkkel írta ki a szöveget? Elkezdi magyarázgatni hogy azért, mert az LEHETETLEN. És fölényes hangsúllyal kioktat engem hogy ha én vagyok itt a programozó, akkor illene tudnom, hogy ezekbe a nyomtatókba be van égetve a karakterkészlet, ami angol, tehát nem várhatom el hogy legyenek benne ékezetes betűk.

A főnököm is ott volt, és hát ugye én nem szeretek égni hogy így megalázzanak... emiatt mondtam a pasinak hogy na most figyeljen, mert lesz ám itt neki csoda mindjárt... Betöltöttem a gépbe az egyik általam írt programot, és minő meglepetés, az képes volt ékezetes betűket (is) kinyomtatni!

Az ipse csak nézett döbbent pofával...

Én pedig megmagyaráztam neki, hogy ő mint __állítólagos__ programozó __illene__ tudja, hogy ezeknek a nyomtatóknak van úgynevezett „grafikus üzemmódjuk” is! Azaz más se kell hozzá mint hogy kissé „megpatkoljuk” a $FCE2 címen kezdődő (máig emlékszem e címre!) kernal rutint ami „egy karakter kiiratása az elsődleges output perifériára”, s ez minden meghívásnál ellenőrzi, ez a periféria a nyomtató-e. Ha igen, megnézi, a kiírni kívánt karakter ékezetes betű-e. Ha az, átkapcsolja a nyomtatót „grafikus üzemmódra”, kiküldi neki azokat a bájtokat amik az ékezetes karakter alakját határozzák meg majd visszakapcsolja a nyomtatót karakteres üzemmódra... Még azt is figyelte a rutinom, épp „duplaszéles” karaktert kell-e nyomtatni, hogy a nyomtató ezen lehetőségéhez is alkalmazkodjék...

Szóval akkoriban is voltak olyan „programozók” akik inkább be akarták mesélni hogy valami lehetetlen semmint hogy gondolkozni kezdtek volna, de ez a mentalitás manapság még sokkal jobban elterjedt. A legszomorúbb meg az hogy még ezeknek áll feljebb, és megvetően beszélnek a Nagy Öregekről, mondván hogy azok a „múltba maradottak”, nem haladnak a „fejlődéssel”, most már FELESLEGES amit ők tudnak, stb...

Az ő valóságában a Commodore 64 nem történt meg.

 

Na bumm. Nem lesz tőle rosszabb szakember. Én is Plusin kezdtem még gyerekként, full "gémerként", de a jelenlegi munkámhoz kb. annyi köze van, mint ha az számítana, hogy ismerem-e a Piroska és a farkast.

Ismerek jó pár öreg C= hekkert, nekik sem jobb attól most, amit 30 éve csináltak, max. őket is irányba állította és így meghatározta az egész életüket.

Egyetértek. Attól, hogy valaki ezeket a régi architektúrákat nem ismeri, az még nem jelent semmit, csak azt, hogy később kezdte az ipart űzni, attól még lehet jó szakember. Én egyébként nem szerettem sose a C64-et, használtam, de szerintem mindig is egy túlhájpolt, túlértékelt gép volt, az összes Commodore-géppel együtt.

Egyedül egy előnye van annak, aki programozott ilyen régi gépeken, hogy megtanulta a programját jól optimalizálni, mert akkoriban ez gyenge, erősen korlátos hardveren kényszerűség volt, egyébként nem futott volna rajta a szoftver, vagy csak használhatatlan sebességgel. Akkor még nem volt ez, hogy minden Electron-alap webszutyok, 800 absztrakciós rétegen és API-n átvezetve, dobjuk össze, majd a fordító optimalizálja meg lesz helye a sok giga RAM-ban alapon.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

megtanulta a programját jól optimalizálni, mert akkoriban ez gyenge, erősen korlátos hardveren kényszerűség volt

Ha ezt gondolod egy Commodore 64-ről, hogyan vélekednél egy mikrokontrollerről, amelyben nem több tíz kilobyte, hanem sokszor több tíz byte RAM van? :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Az attiny24 128 byte SRAM-ot tartalmaz.

A flash hozzá 2KB, de ez leginkább a ROM-mal rokonítható.

 

A 128 bájtban a verem is benne van. Sok függvényhívás ne legyen, mert a verem elég gyorsan elfogy.

Ha adatot akarsz tárolni, azt néhány 10 bájton érdemes és a rekurziót felejtsd el.

Például a Microchip PIC12F510-esében van 38 byte RAM. A PIC16F84-ben 68 byte van. Tudom, vannak újabbak, stb., de szerintem nem kell mondjuk kerékpár lámpa LED villogtatáshoz 64 lábú TQFP tokban 32 bites MCU. Mert nagy, mert vélhetően többet eszik, mint a kicsi. Nem jó irány, hogy az egyszerű feladatok alá is oprendszert teszünk, aztán ha nincs szerencsénk, egy kerner driver bug miatt kivilágítatlan lesz a kerékpár, s elüt az autó.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nem használhatatlan. Csináltam ilyenből időzített világítás vezérlést, illetve kerékpár hátsó világítás vezérlőt. Az interrupt felől ne aggódj, emlékeim szerint ugyanis nem kezel megszakítást egyáltalán. :) Ha jól emlékszem, az egyiknek két, a másiknak nyolc mélységű stack-je van, bár ez utóbbi már kezel IT-t. Elfogadott IT esetén csak két regisztert kell menteni: a W-t és a STATUS-t.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Jaja, total hasznalhatatlan, Atmel vonalon 32 byte RAM a legkisebb, es van benne interrupt is. ld az adatlapot.
Ahhoz kepest van olyan feladat, amire egy 555 is eleg, ez csak egy kis lepessel megy tul rajta, ha az mar nem lenne eleg.

Egyebkent igen, ha nem millios darabszamrol van szo, es nem csak a technikai kihivas hajt, akkor beleteszel egy kicsit nagyobb mikrot, es kenyelmesen megirod amit szeretnel. Vagy beleteszed a prototipusba a csalad legnagyobb tagjat, aztan ha kiderul mekkoraba fersz bele, a vegtermekbe mar mehet a vele kompatibilis kisebb uC.

A strange game. The only winning move is not to play. How about a nice game of chess?

Látszik hogy nem érted. Nem arról van szó hogy valaki ismerje meg ezen régi gépek mindegyikét. Sőt, akár egyet se muszáj ismernie. Itt a lényeg az, hogy ismerjen meg legalább egy igazán KIS gépet, de NAGYON alaposan! Lehet olyan gép is amit manapság gyártottak - bár konkrét példát erre ne várj tőlem mert ezeket meg én nem ismerem. (A C-64 -et annál jobban... Ha hiszed ha nem de már arra is írtam saját programnyelvet...)

Na és azért kell ismerni legalább egy ilyen kis gépet mert különben egyszerűen nem tudsz kódot optimalizálni igazán a mai nagy gépeken se. Nyilván, én se veszem semmi hasznát annak hogy máig fejemben van hogy a C-64 esetén az interrupt rutin a $EA31 címen kezdődött, meg más hasonlók. Tényleg semmi bajom se töürténne már ha ezt elfelejteném. De a lényeg nem ez, hanem hogy közben megtanulsz A GÉP ESZÉVEL GONDOLKODNI. Egyszerűen beléd ivódik egy olyasféle „ösztön” vagy hogy mondjam, hogy amikor később egy BÁRMILYEN gépen írsz egy BÁRMILYEN programot, már előre MEGÉRZED hogy hol lesz a programodban a „bottleneck”, a szűk keresztmetszet... Vagy rosszabb esetben ha nem is érzed meg ELŐRE, de amikor kiderül hogy a progid lassú, azonnal beugrik, hogy „hm, ez azért lehet mert...” - és akkor rögtön azon a területen kezdesz el kapirgálni ahol valóban érdemes...

Mert tudod, mert érzed, hogy mi történik „ott lent a mélyben”, hardware-szinten!

Nyilván nem tudod teljesen pontosan mert a régi gépek nem azonosak a maiakkal. Eleve például csak „egyszálasak”, stb. Mégis, nagyjából tisztában leszel vele, sokkal inkább mintha csak a C lenne a legalsóbb szintű nyelv amit ismersz. Holott az manapság már tök jó ha valaki legalább a C nyelvet ismeri mert egyre nő azoknak a száma akik még azt se mert nekik már az is „túl nehéz”, komolyan a pofám leszakad amikor ilyeneket hallok... Rém elszomorító... Mi lett volna ezekkel tényleg a C-64 idejében?! Felvettek a vállalathoz programozónak. Megmondták a feladatot, megcsináltam. Természetesen Basicben, az volt ugye a C-64 „alap” nyelve, a ROM-ba beleégetve... a program működött, igen... épp csak iszonyat lassú volt! Elkezdte a számítást péntek reggel. A nap végéig nem fejezte be... Bekapcsolva hagytam hétvégére... Hétfőn amikor munkába mentem még mindig számolt, de szerencsére délelőtt tízre befejezte. Tizenegykor jött a főnök az eredményért, szerencsém volt, nem győztem törölgetni a verítéket a homlokomról megkönnyebbülésemben... Igen, de megkaptam az újabb feladatot, és tudtam erre nem lesz egy újabb hétvégém holott ez még nehezebbnek tűnt... Na mit tehettem, tudtam, gyorsítani kell a progin... irány az ASSEMBLY, mert más NEM VOLT!

Ja, szakirodalom se volt hozzá, csak NÉMETÜL. Én meg egy árva szót nem tudtam azon a nyelven... Még a vécén is a szótárt forgattam és próbáltam rájönni hogy a francba írjak meg egy assembly programot. Assemblerem se volt csak a ratmon-64 nevű úgynevezett „monitorprogram”. Ami címkéket kezelni se tudott, azaz az ugrási címeket nekem kellett külön kiszámolgatnom hexadecimálisan...

Na de megoldottam mert meg AKARTAM oldani!

A mai „örömprogramozók” ezt már nem értik. Nekik ez „túl nehéz”, meg „szopatós” meg ilyesmi... és igen, valóban nehéz és szopatós. De ebből lehet TANULNI...

Ha valaki így kerül be a „szakmába”, az utána egészen másképp tekint egy számítógépre meg a programnyelvekre.

És mondok mégvalamit. Nehéz volt meg szopatós? Igen, az. De kapaszkodjatok meg: ÉLVEZTEM! Az az igazság hogy az egészbe hogy saját programnyelvet írok mostanság, azért is kezdtem bele mert ugyanezt az örömöt, a „bütykölés örömét” akartam élvezni megint... Nos, sikerült is valamilyen fokon, de azért messze nem annyira mint akkor régen, megboldogult ifjúkoromban a C-64 esetén...

Én sajnálom a mai programozókat, mert nemcsak elkényelmesedtek, de épp ez a kényelem elvette tőlük a programozás IGAZI VARÁZSÁT.

A mai programozók tömegtermelni akarnak, illetve még azt se, hanem csak sok pénzt keresni, aminek a tömegtermelés a módja azt hiszik. Oké, pénzügyileg talán még igazuk is van, nem tudom... épp csak ez teljesen más szemlélet mint az én koromban volt, amikor bennünket nem a pénzkereset vitt a pályára hanem maga a programozás SZERETETE!

És ez ott jön a témához hogy amit szeret valaki, azt sokkal alaposabban megtanulja mintha csak egy kenyérkereseti forrás lenne a számára, egy a sok közül. A mai programozók azonban nem AKARNAK programozók lenni, csak úgy azzá lettek szinte véletlenül. Épp úgy alakultak a körülmények hogy ide felvették őket, vagy beprotezsálta őket az XY akárkijük, mittudomén. Ha kicsit másképp alakulnak a dolgok, nem programozó lett volna belőlük hanem mittudomén gépészmérnök, vagy fizikatanár vagy akár urambocsá' ókortörténész. Mindegy. A lényeg hogy legyen valami állás ahol ledolgozza a napi 8 órát aztán elfelejtheti az egészet.

Nálam nem így volt. Én ismerni AKARTAM azt a gépet, minden porcikáját!

És erősen hiszem nemcsak én voltam így ezzel, de azok óriási többsége is akik akkoriban kezdtek szagot fogni a számítástechnikáról.

amig nemvolt google, hol "taroltak" ezeket a csoportokat? oda nem tudnak visszamenni?

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Valószínűleg már régen valami indiai szeméttelepen kalapálják helyi gyerekek azokat a szervereket, hogy kinyerjék belőlük a drága fémeket. A szerencsésebbek meg vitrin mögött alusszák örök álmukat valami infó kiállításon. 

Google ingyen adta a vasat és szoftvert így költözzünk oda volt a kényelmes megoldás.

Van egy mondás, az ingyen leves a legdrágább a világon. Állítólag Mr. Rotschild mondta. Hát most megjött a számla. Valaki a guglinal kitalálta, hogy ebből lehet costcut, a legal départment megnézte, hogy nincs tulajdonos aki nekük mehetne a bíróságon, a pr beárazta az esetleges negatív sajtóból adódó brand sérülést és döntöttek.

Lehet, hogy pr értékben dobott volna valamit, hogy körbekérdeznek mielőtt letörlik és keresnek valaki más befogadót. 

Mondjuk amikor azt mondták hogy menjen hozzájuk örökbe fogadásra akkor nem tudom mi volt a deal.

Nem kell ezt túlgondolni. Az a rész jogos a Googletől, hogy valamit tenni kell az ilyen abandonware spam és malwarelink mágnes csoportokkal. Az is érthető még, hogy pusztán a read-onlyvá változtatás nem elég, mert a már ott levő spam azzal maradna. Szvsz nem lett volna nagyon megerőltető megkeresni az utolsó még aktív évet, onnan visszafelé archiválni read-onlyba, az után következő éveket pedig törölni. Valószínűleg olyan fiatal Google dolgozó hozta meg a döntést, aki soha nem használt ilyen csoportokat, és nem is nézett utána mire voltak ezek. 

Francokat.

Ha senki nem vette a fáradtságot az archiválásra, meg tényleg évek óta csak a szemét gyűlt, akkor már vagy nem él senki a tagok közül, vagy már őket sem érdekli.

Az mondjuk tény, hogy a G bedobhatott volna minden csoportba 2-3x 1-1 üzenetet, hogy 2020.07.31-n zúzda és ha valaki felteszi a kezét, akkor megkérik, hogy takarítson. Meg ki tudja, nem keresték-e azt, akivel a deal-t megkötötték anno.

Egyébként úgy látom, visszaállították (vagy nem, a GGroups szerintem mindig fos volt).

Sokkal kisebb az esélye, hogy egy nagy cég mint a Google felhőjében elvesznek az adataid mint saját vason valami havernál hostolva. Tanulságos történet az eredeti Gentoo wikié. Nemcsak az Gentoo hanem minden hc Linuxos tutorial alfája volt. Majd a szerverházat üzemeltető fővállalkozó nem fizette az épület bérleti díját, a épület tulajdonosa pedig elvágta a netet és lefoglalta a tartozások fejében az ott levő szervereket. A Gentoo wiki pechje az volt, hogy ők ráadásul egy alvállalkozóval voltak szerződésben. Soha nem kapták vissza a szervert. Ezek után vette át a helyét az Arch wiki.

Bocs de ez nekem fából vaskarikának tűnik. Ha „egy alvállalkozóval voltak szerződésben”, akkor az NEM SAJÁT VASON VOLT HOSTOLVA. Akkor ők azt bérelték vagy valami ilyesmi.

A saját vas, az például az én 2X2 TB külső merevlemezeim amikre backupolok alkalmanként. Meg más ilyesmik. A saját vas az az ami a birtokomban van.

Abból amit írtál nekem az jön le hogy a Gentoo wikinek a szerverei nem a Gentoo tulajdonában voltak, nem is abban az épületben voltak ami az ő tulajdonuk volt, s a korona az egészen hogy eszerint egy francos bizonsági mentésük se volt, legalább mittudomén az előző hónap állapotáról, ami mentés a saját birtokukban (=saját vason saját épületben...) lett volna.

Tehát, az én fogalmaim szerint mindent a „FELHŐRE” bíztak. Na, az eredmény látható...

De szólj ha valamit félreértettem volna. Tényleg nem ismerem a történetet, csak annyit tudok róla amennyit te ide fentebb leírtál. Abból azonban nekem ez esik le perpillanat.

Kerestem az eredeti írást ahol a srác leírta mi történt de sajnos nem mentettem anno a linket. Először is nem hivatalos Gentoo projekt volt hanem, olyan gentoosan egy lelkes emberük megcsinálta maga. gentoo-wiki.com domainen futott. Ő maga vett hozzá valamilyen rack szervert is. 

A fő hosting szolgáltató bérelt egy épületet. De voltak kisebb alvállalkozói akik meg tőle béreltek rack szekrényeket, illetve üresen maradt egy-egy rack helyet értékesítettek kicsi, egy szerveres ügyfeleknek. Egy ilyennel állt szerződésben a gentoo-wiki tulajdonosa is, aki még ismerőse is volt. Egészen biztosan saját vas volt, innen Európából nem is értettük, hogyan lehet lefoglalni másnak szerverét elmaradt bérleti díj miatt ha csak közvetve volt kapcsolatban vele az épület tulaja. De azt írta a srác, hogy sajnos az ottani jog ezt megengedi. A nagy halak egyezkedtek a épület tulajjal, és visszavásárolták a szervereiket. De vele szóba sem állt. Az adatokat sem tudta lementeni. Eleve csak a fővállalkozó közvetlen ügyfeleivel vette fel a kapcsolatot. Több mint egy évvel később lett interneten elérhető másolat, mert valaki még időben lementette: http://wikigentoo.ksiezyc.pl/index.htm

De ez bőven elég volt arra, hogy gentoo-wiki mögötti közösség szétszéledjen. Ráadásul sokan okkal voltak zabosak. 

Köszi. Ebben az esetben azonban a dolog még sokkal inkább gáz, mert ebből meg az jön le nekem hogy igazából NEM IS LÉTEZETT hivatalos gentoo-wiki! Tehát egy lelkes fickó csinált valamit lényegében a maga számára, "AS-IS", aztán mindenki azt hitte ez egy hivatalos gentoo wiki, holott egy „magán” wiki volt csak...

Ezzel nem a srác munkáját akarom ekézni, nyilván sokaknak nagyon hasznos volt meg minden, és így is köszönettel tartozunk neki, stb. De ez akkor is egy „magán” erőfeszítés volt, lényuegében egy "one-man-project" ami a hardware-t meg ilyesmit illeti, és eszerint magához a „Gentoo szervezethez” (ha lehet így mondani) lényegében semmi köze nem volt. Ez egyrészt meglepő nekem, másrészt rémségesen elszomorító is... Viszont ekkor is az van hogy az én fogalmaim szerint a srác a „felhőre” bízta a dolgait. Birtokában volt a vas? Nem. Nem, mert kiadta a kezéből. Olyan helyen volt a vas, amihez neki nem volt hozzáférése. Hiszen csak úgy kitilthatták őt onnan, nem mehetett be a gépéért. Ez az én szememben már elégséges ismérv ahhoz hogy „felhőnek” nevezzem.

Egy adatközpont-féleségben volt a gépe (már ha tényleg nevezhetjük az ő gépének mert én még ebben se vagyok biztos) és ha adatközpont, az a szememben már bőségesen „felhő”.

Mondom: az nem felhő nekem amihez akármikor odamehetek és darabokra szedhetem, összetörhetem, bővíthetem, átalakíthatom, ki- és bekapcsolhatom, stb. Ami az ENYÉM. Teljesen.

Elismerem ennek vannak bizonyos árnyoldalai, kényelmetlenségei is. Mindazonáltal én is azok közé tartozom akik ebben jobban bíznak.

Két fajta adat van tudod:

1. Amit elmentettek.

2. Ami MÉG nem veszett el...

Na most ami felhőben van az mind olyan a szememben ami MÉG nem veszett el. Az a szememben nem másolat (mentés) hogy a szolgáltató azt ÍGÉRI, hogy majd Ő backupolja X időközönként. Nem tudhatom, mit ért ezalatt. Lehet hogy a backup is ugyanabban az épületben van... (és akkor azt is lefoglalják ha nem fizeti a bérleti díjat, hehehe...) rosszabb esetben ugyanazon számítógépre kötött másik lemezre backupol amit aztán le se csatol róla... Még rosszabb esetben ugyanazon lemezen lesz lérehozva egy másik fájl, na köszönöm szépen az ilyesmit...

Tudnék még további horrorisztikus példákat felhozni.

Ez nem azt jelenti hogy én ne tárolnék adatokat „felhőben”! Hogy a csudába ne, nem is egy helyen... De mindig szem előtt tartom, hogy mennyire fontos vagy nem fontos az az adat amit ott tárolok, és ami IGAZÁN fontos, arról mindig van FIZIKAILAG NÁLAM LEVŐ hogy úgy mondjam OFFLINE backup is, nem is egy példányban...

-ugyanazon partíción másik fájlpéldányként

-másik partícióra is átmásolva

-több pendrive-on, amiket másolás után lecsatolok

-külső merevlemezeken (van vagy fél tucat...) amiket szintén lecsatolok a másolás után

-van két másik laptopom is, azokra is át szoktam másolni a fontosabb dolgokat

Gyakorlatilag a felhőbe mentés nálam NEM arra van hogy az offline mentést HELYETTESÍTSE, hanem KIEGÉSZÍTÉSKÉPP, hogy ha valami egészen extrém katasztrófa miatt a teljes otthonom megsemmisülne, vagy netán MINDENT ami adathordozó ellopnának onnan, akkor is vissza tudjam kapni a fontos adataimat, ekkor ugye a „felhőből”. Hiszen valószínűtlen hogy a felhő is épp akkor döglik be amikor nálam is bekövetkezik az apokalipszis...

Erre jó a felhő. De nem az offline backup teljes helyettesítésére.

A Gentoo mindig ilyen laza társaság volt. Viszont a forrásalapú disztribúció python alapú portage rendszerrel (ami egy továbbgondolt BSD ports) annyira masszív elpusztíthatatlan valami, hogy igen viharos múltja ellenére máig létezik a Gentoo. Az Overlayek bevezetése óta az is elkenődött mi a hivatalos, fél-hivatalos vagy egyáltalán nem hivatalos gentoo csomag. Asszem ennek az első gentoo wikinek az volt az előtörténete, hogy ment a vita arról milyen is legyen a hivatalos wiki. Valamiért elvetették a MediaWiki alapot, de amit választottak baromi körülményes volt és nehezen kezelhető. A srác megunta és csinált egy sajátot saját szerveren és  a jól bevált MediaWikivel. Mivel a Gentoo nagy hozzáértést igényelt akkor is a felhasználóitól nagyon jó közösség alakult ki. Ami ma az Arch wiki az volt akkor a Gentoo wiki. Sőt még jobb is volt, mert a Gentoo rugalmassága olyan dolgokat is lehetővé tett ami Archon nem oldható meg. 

Példának azért hoztam mert ha anno olyan nagy szolgáltatóhoz viszi mint a G felhője, akkor ma is a gentoo-wiki lenne a standard alap. Ilyen eset a szerver elvesztésével a Googlenél biztosan nem történt volna meg. Illetve ha már wiki akkor a Wikipedia mögötti cég Fandom.com szolgáltatása lett volna a triviális választás, ami akkor Wikia néven ment. 

A mostani cikk arról szól, hogy egy évtizede mindenki által leszart Groupokat törölt nem túl szerencsésen a Google spam és malware miatt. Ez sem OK de totál más kategória és elég esélyes, hogy ezt is vissza fogja csinálni a Google. 

Ahogy írod természetesen felhős szerverről is érdemes backupot készíteni. Szerintem az is belefér, hogy ez a backup egy másik felhős cégnél legyen. Annak esélye, hogy egyszerre semmisül meg a Google és Amazon felhője igen kicsi. Atomháború vagy meteorbecsapódás esetén talán, de akkor meg úgyis mindegy :) Felhős cég választásánál továbbra is a nagy megbízható multikat érdemes választani szerintem. Egy Google vagy egy Amazon lényegesen biztonságosabb mint egy nevesincs felhős szolgáltató. 

Megfeledkezel a politikai szándékról, naiv a hozzászólásod, különösképpen az USA-ban a TikTok videomegosztó tiltása kapcsán írom ezt. Hogy lehetsz annyira naiv, hogy azt gondolod, a Google mindig mindenkinek elérhető lesz a jövőben? Miből gondolod, hogy az elérhetőségnek nem lesznek sohasem politikai feltételei? Vagy nem lehet egyik pillanatról a másikra megváltoztatni úgy az ÁSZF-et, hogy utána privacy okokból nem áll módodban elérni a saját adataidat?

Amikor felhőbe mentesz, ugye nem csak valamelyik nyugati állam cégénél üzemelő felhőbe teszed? Mert ha igen, s emigrálnod kell Oroszországba vagy Kínába, hogyan fogod elérni a dolgaidat? Mi lesz egy háborúban? Tudom, neked a ZX81, ZX Spectrum, Commodore 64, Commodore VIC-20 meg sem történt. És 1945. augusztus 6-a és 9-e vajon megtörtént? 1956. október 23-ától november 4-éig, és az utána lévő időszak megtörtént? Hány ilyen esetnek kell még megtörténnie ahhoz, hogy a ma élők is elhiggyék: ezek bármikor újra megtörténhetnek! Az elménk távol tartja magunktól ezeket a gondolatokat, mert annyira borzalmasak, annyira nem szeretnénk, de érdemes megnézni, mennyire feszült, konfliktusokkal terhelt a világunk, s ez egyre rosszabb lesz. A közlekedési baleset is az az esemény, ami mindig csak másokkal fordulhat elő, velünk soha. Valóban?

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nem hordok alusisakot a fejelemen. Így nem érzékelem ezt a nagy veszélyt. 
Azért gondold át minek nagyobb az esélye? Valami globális jövőbeli konfliktus miatt elérhetetlenné válik a Google felhőben működő szervered? Vagy megdöglik a háttértárad a saját szerveredben, amiről éppen idő ésvagy pénzhiány miatt nem csináltál tegnap backupot. A gentoo-wikis példa egy saját pénzből csinált szerverről szólt, amit lelkesedésből csinált és csak vitte a pénzét. Márpedig általában ilyenkor van egy határ időben és pénzben is. 

Ha megdöglik a háttértár ami SSD volt, akkor az azon levő adatokat már a Kürt sem tudja megmenteni. 

De még abban az esetben is ha valami miatt Európából elérhetetlenné válna a Google minden előjel nélkül egyik napról a másikra, ott egy OpenVPN vagy valami tunnelezett ssh kapcsolat, még mindig számtalan lehetőséged marad. 

Atomháború esetén meg ... szvsz szerintem nem ez lesz a legnagyobb problémád. :)

Nézd, én eléggé masszívan használtam és használom most is a Google szolgáltatásait, de ez rém messze van attól, hogy bízzam benne.

Egyrészt, gyakran gondjaim vannak bizonyos szolgáltatásainak az elérésével mert ezeket ahhoz köti, mennyire MODERN a kibaszott böngészőm! Holott ne gondolj semmi különösre, tudom, az adott feature simán elérhető lenne a régi Palemoon vagy Firefox browserrel is, de mégis... És nekem nem tetszik hogy Ő a Nagy Cég akarja megszabni, ÉN mit használok a SAJÁT gépemen!

De ez félig off volt. Hanem most figyelj! Talán pár éve történt valami nagyobb vírusfertőzés vagy mi a világban. És ekkor a Google kurvára belassult. Nekem meg épp kellett volna valami állomány, amit még jó régen csináltam, és tudtam hogy elküldtem valahová akkor régen egy email csatolmányaként. Egy .tar.bz2 fájlról volt szó.

Emlékeztem a levél szövegéből pár szóra, rákerestem, megtaláltam. Na most jön a slusszpoén: a Google NEM ENGEDTE LETÖLTENI a csatolmányt, már nem emlékszem mit írt ki konkrétan de valamiféle biztonsági kockázatokról gagyarászott! Még olyasmit se engedett hogy a saját kockázatomra töltsem le, érted?! Ott volt a file, láttam, de nem juthattam hozzá, AHHOZ A FÁJLHOZ, amit ÉN MAGAM TÖLTÖTTEM FEL!

Még ha más által küldött csatolmánnyal műveli ezt az is ciki lenne, de hogy azzal amit évekkel ezelőtt ÉN MAGAM küldtem el?! Hát én csak tudom talán vírusos-e! És persze hogy nem volt az. De akkor volt ez a víruspara a világban, talán (csak tippelek) a google-nak nem volt épp szabad erőforrása kicsomagolni és ellenőrizni a letöltendő fájlt, így inkább ő úgy DÖNTÖTT persze HELYETTEM hogy nem engedi letölteni!

Ilyen esetben ha figyelmeztet letöltés előtt, az szerintem oké. De nem ezt tette hanem egyszerűen nem engedett inkább hozzáférést nekem a fájlhoz...

Végül valahogy mégis letöltöttem valami kerülőúton, már nem emlékszem miként... De azután épp emiatt úgy döntöttem keresek valami a Nagy G-től független szolgáltatót is, azóta az igazán de tényleg IGAZÁN létfontosságú dolgaimat a protonmailhoz is elküldöm...

Szóval nem, nem, attól hogy valami olyan nagy mint a gugli, még nincs garantálva semmi se. Igen, a felhőnek vannak előnyei, elismerem. De ha CSAK felhőd van, akkor lényegében semmid sincs IGAZÁBÓL, és teljesen ki vagy szolgáltatva.

Tökmindegy, az USA-nak, Svájcnak, Kínának, a ruszkiknak, akárminek. A név és nemzet meg ország változhat, de az elv ugyanaz: Az a tied igazából, ami NÁLAD VAN. A többi csak illúzió.

2 éve amikor futótűzként fenyegetett, hogy cryptomalware hullám végigmegy a windows saját háttértárak mellett az SMB -vel csatolt fájlokon is, akkor a Microsoft egyik napról a másikra kinyírta az SMB megosztást Windowson. Akkor ez volt a legjobb megoldás, nem volt mit tenni. Tessék, a saját A gépedről nem éred el B-ről csatolt fájljaidat. Akkor tervezzünk saját architektúrát, saját számítógépet, saját operációs rendszerrel? Az már tényleg biztos de igen körülményes megoldás lenne! 

Később gondolom újra le tudtad tölteni a tar.gz fájlodat. Szóval csak nem veszett el. 

Nem értek a windoshoz, az SMB-hez meg még annyit se. Az általam írt példában azonban a Google azt kellett volna tegye, hogy kiírja, hogy nem tudja ellenőrizni a letölteni kívánt fájlt hogy vírusos-e vagy akármi, le akarom-e tölteni így is mindenképp a saját felelősségemre? IGEN-NEM

Ezt kellett volna tennie. De nem ezt tette hanem egyszerűen úgy döntött Ő, azaz ő, HELYETTEM, hogy márpedig nem tölthetem le semmiképp se!

És kész. Ő jobban tudja. Megfosztott az állományomtól. Abban igazad van hogy csak ideiglenesen. De ha nekem az valamiért épp akkor rohadtul fontos lett volna...?!

Mi jogon dönt a gugli helyettem az ÉN FÁJLOM felől?!

Nem, én semennyire se bízom a felhőben. Használom, igen, rendszeresen, sokat, de olyan böszmeséget soha el nem követnék hogy KIZÁRÓLAG a felhőre bízzam magamat (az adataimat).

Ez nem a havernál hostolás miatt volt, hanem hogy nem volt róla biztonsági mentés, amit ki lehetett volna tolni más szerverre. Nem ismertem ezt a fickót, de amatőrnek tűnik így a leírásod alapján, az az énvagyokahekker típus, akit egy ilyen alap dolgon is megszopatnak, mert nem gondol ilyenekre. Pedig egy ilyen Wiki tömörítve nem egy nagy tétel, jól tömöríthető szöveges és bináris adat, több példányban csinálhatott volna róla rendszeres mentést.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Egy globális felfordulás, háborúk, politikai, gazdasági, katonai nyomásgyakorlás, a társadalmi rend alapvető megváltozása, ideértve a ma ismert pénz megszűnését akár, mindent felülír, azt is, ha fizetsz a szolgáltatásért. Az állami szabályozók alkalmasak lehetnek arra, hogy beleszóljanak ebbe. Tényleg, nem is kérdeztelek arról, mi a véleményed, Trump talán ma adja áldását a TikTok USA-ból való kitiltásához. Ha valamelyik amerikai állampolgár használja, az terrorista lesz? Vagy csak a cégek? Netán lesz nagy tűzfal is? Ugyanez Magyarországon nem probléma a Facebookkal, Google-lal, Microsofttal kapcsolatban?

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

facebook-nál is vesznek a csoport hozzászólások

sima felhasználóként 1+ évnél régebbi bejegyezéseket már nem lehet elolvasni, kb 2000 hozzászólásnál többet már nem lehet visszascroll-ozni praktikus okokból

rákeresek a keresőben a régi hozzászólásokra és tudom hogy lenne 100 találat, mert pl én írtam, és összesen kiad 3-at

vagy sok helyen kiírja hogy "a bejegyzést törölték vagy nem tölthető be", és tudom hogy nem törölték, előző nap még ott volt

max a csoport admin-nak lehetnek meg a hozzászólások ha letölti archiválva a csoportot, de én azt nem tudom hogy működik-e

Hát, ez tanulópénz....

Még mindig saját szerveren kell levelezőlistát üzemeltetni,

soha ne bízz ingyenes szolgáltatásokban....

Airconditioned terminal, do not open Windows.