Linux

Linux - pitanja i odgovori

bunker sri 14.4.2021 10:06


Nuclear, vjerojatno i među programerima ima multipraktik osoba, no one koje sam ja dosada upoznao neznaju pošteno primiti šrafciger a kamoli riješiti potrganog heatsink i sl.

A da nevelim o tome da se lojtrama zavuku u kanalicu pa rješavaju kabliranje u kanalici punoj mišjih govana i sl...

Ili da vise na sigurnosnom pojasu na krovu ili rubu nebodera podešavajući usmjerenu antenu radi dometa do udaljenije zgrade... Ti znaš programere koji to ponekad rade ? Ja ne. 😄

MrBlc sri 14.4.2021 11:20
bunker kaže...
Znanje programiranja ti netreba za poznavanje osnova rada računala i operativnih sistem i najčešćih aplikacija. Programeri razvijaju aplikacije i često izvan toga ti pojma nemaju o ičemu drugome. Daj programeru shemu matične i zamoli ga da izračuna konturne struje na nekom chipu pa buš vidla 100 izgovora...

To ti ne bi znalo izačunati ni 99% diplomiranih elektroničara, barem 50% asistenata i solidan postotak profesora iz stručnih predmeta na studiju elektronike.

 

S druge strane, programer koji radi išta više od web-a ili jednostavnih korisničkih aplikacija, mora znati barem odnove arhitekture računala i OS-a.

bunker sri 14.4.2021 13:17


Mrblc , slažem se. Možda niti ja nebih znao dobro konturne struje da me nije 4 puta rušio profa iz osnova elektrotehnike baš na konturnim strujama pa sam ih morao doktorirati...

Da, možda programeru i treba poznavanje osnova računalne arhitekture, no prosječnom a niti naprednijem korisniku računala netreba niti najmanje znanje programiranja.


A dalo bi se diskutirati o tome koliko su programeri voljni i vični za it radove koji su prljavi ili opasni po život i zdravlje.

A fizičku spremu i kondiciju uvjek možemo odmjeriti na nekoj tekmi malog nogometa ili u boksačkom ringu, no na tim poligonima nekako vlada deficit programera, bar na ovima gdje ja upražnjavam te sportove.... 😉

MrBlc sri 14.4.2021 13:52
bunker kaže...
Da, možda programeru i treba poznavanje osnova računalne arhitekture, no prosječnom a niti naprednijem korisniku računala netreba niti najmanje znanje programiranja.

Opet to ovisi što ćeš sve utrpati pod programiranje.

 

Izrada jednostavne skripte u stilu AutoIT-a ili naprednije kalkulacije u Excelu spada u neku širu definiciju programiranja...

Ana9 sri 14.4.2021 18:27

Ipak je problem bio u biosu.

Izvadili su čip sa matične, postavili bios na čip iz početka, zalemili čip na matičnu... Kaze da nije mogao bez skidanja čipa. Eto Mint radi ko urica za sad, u bios ulazim sa F2 bez ikakvih problema kao i prije. Na kraju ne znam razlog, objasnjenje je da se to zna desit ponekad... 

 

Puno hvala svima na pomoci, dali ste mi korisne savjete vezano uz Linux i da nije bio tolko zeznut bios sigurna sam da bi uspjela.

 

Hvala jos jednom!

Ana9 sri 14.4.2021 19:40

 

@bunker

 

Na mom je bio samo DOS, naknado sam sama Windowse stavljala gore. isto sam ga oko 2014 kupila. Sad me zanima koju grešku je bacao tvoj, isto problem s BIOSom?

Kad se oni prave glupi onda bi možda dobar argument bio da su trebali stavit upozorenje da se ne smije instalirati Linux

Ma mislim ko je ikad čuo da bi instalacija Linuxa "pokvarila" komp, ma mislim to je takvo izvlačenje... fakat ne drži vodu

Al problem je i da odeš na sud s tim pitanje dal bi sudac uopce kužio u cemu je stvar... a i vjerojatno ti se nije dalo više natezati s njima.

 

 

bunker sri 14.4.2021 21:00


Ana9 , ja sam iskoristio priliku i kupio poveću količinu tih laptopa jer je cijena bila smiješna ako uzmem na palete ( msan) . Par sam ostavio sebi a ostatak rasporodao na tadašnjim oglasnicima i među poznatima.


I jedan od tih koje sam sebi ostavio je krepao totalno, nije davao nikakve znakove. Samsung se ogradio na način da sam ja kupio devices koji se sastoji od hardvera i softvera ( win 8 tada ) te da je uređaj kao takav projektiran, testiran i pušten u prodaju, a da sam ja instalacijom linuxa u bitnome promijenio svojstva uređaja te da sam stavio nekompatibilni softver za koji uređaj nije testiran i da je to uzrokovalo prestanak rada matične. Rutinski sam odradio prijavu inspektoratu, oni su prihvatili samsungovo tumačenje, a ja sam dobro zaradio na tim laptopima pa i nisam kukao za tim jednim.....


Velika većina tih laptopa radi i dan danas, jedan je kod moje kćerke koja ga koristi za rad ( prevođenje, lektura , korektura ) i svaki dan radi satima, baterija je dala svoje ali ostatak laptopa radi čilo i veselo ( win 10 ).

hrx sub 1.5.2021 02:15
Ana9 kaže...

Ipak je problem bio u biosu.

Izvadili su čip sa matične, postavili bios na čip iz početka, zalemili čip na matičnu... Kaze da nije mogao bez skidanja čipa. (...)

Samsung NP300 E5X ima bugovit BIOS (kao i dosta Samsungovih prijenosnika), tako da treba staviti najsvježiju dostupnu verziju. Jedan od najčešćih upita je kako ući u BIOS, jer izgleda da F2 prestane raditi kada se odaberu određene opcije (koliko sam primijetio, većina je isključila Secure Boot) - odgovori su F10 i odabir opcije Enter Setup, ili ako to ne radi, korištenje vanjske tipkovnice (što vrijedi i za neke druge Samsungove modele s istim problemom).

 

Ana9 kaže...

 

(...) Ma mislim ko je ikad čuo da bi instalacija Linuxa "pokvarila" komp, ma mislim to je takvo izvlačenje... fakat ne drži vodu (...)

Bilo je slučajeva kroz godine - nekih manje, nekih više ozbiljnih.
 
Vrlo ozbiljan problem iz 2012. za vlasnike Samsungovih prijenosnika: UEFI boot live-usb bricks SAMSUNG 530U3C,np700z5c laptop  Zbog bugova u BIOS-u, UEFI način bootanja s Ubuntuom 12.04 brickao je prijenosnik, dok je legacy mode radio bez problema.
 
Nešto svježiji slučaj iz 2017. koji je, pored niza modela drugih proizvođača, zahvatio priličan broj modela Lenovo prijenosnika pri instalaciji Ubuntua 17.10: corrupted BIOS due to Intel SPI bug in kernel  Nakon bootanja i instalacije, SPI flash čip s BIOS/UEFI-jem bio bi prebačen u read-only mod - nije bilo moguće spremiti promjene u BIOS-u, bootati s USB-a niti mijenjati EFI zapise (tj. instalirati druge distribucije Linuxa ili Windowse). Problem je zahvaćao prijenosnike koji su bili opremljeni određenim modelima Winbond, GigaDevice i ESMT SPI flash čipova.

 

Zechina sri 12.5.2021 12:19

Povijesno gledano, većina BIOSa za PC su oduvijek bili "sprčkani"  (AMI BIOS, Phoenix...) - bugovi su bili uglavnom benigni, no nevjerojatno je koliko je esencijalnom komadu softvera (firmware!) poklanjano premalo pažnje.
Samsung je samo nastavio "tradiciju". :)

Svojedobno sam se igrao sa modificiranjem BIOSa, npr mijenjanjem OEM "splash screena" i sličnim glupostima; 3rd party alati za to su u dokumentaciji imali popriličan broj dokumentiranh bugova BIOSa (kojih nije bilo u službenoj dokumentaciji) i upozorenja što se smije a što je bolje ne dirati.

 

Sa prvim (U)EFI pločama stvar je tek porasla na n-tu: sjećam se kompa u kojem sam npr u UEFI meniju imao odabir "screen savera" sa zvjezdicama i sličnih gluposti, ali npr običan USB boot za namjestiti je bio - mission impossible.

 

No, probajte podesiti Mac, kolega veli da je grub dječja pjesmica vs blesavi bless :)

Chupo pon 28.6.2021 01:38

U dve Virtualbox virtualne masine sam instalirao Debian s istog image-a s tom razlikom da sam kod instaliranja drugog VM-a stavio kvacicu samo na MATE desktop environment a u prvom VM-u sam kod instaliranja stavio kvacicu na sve desktop environment-e i tamo se logira preko gdm3 display manager-a koji se je instalirao automatski a na novom VM-u se je instalirao samo lightdm a nakon sta sam instalirao gdm3 je boot svaki put zablokirao pa sam morao s Alt + F2 otvoriti command prompt i s dpkg-reconfigure ponovo aktivirati lightdm. Probao sam editirati config u /etc/gdm ali s gdm3 nisam uspio postici da bi boot radio.

 

U cemu bi mogla biti stvar?

ihush pon 28.6.2021 08:57

- u tebi :)

.. tj u kombinaciji, redosljedu, sec.fičerima, grubu, .. kraće dll-hell koji izazivaš korištenjem distre koja je za rad + KISS.

-kad želiš điđemiđe ideš na npr mint, deb je stabilan-čist, ako od njega stvoriš mint tad to nije deb a tad je kraći put instalirati tu distru.

 

-ovisi jel to za rad ili učenje.. ako je za rad, ponovi, brže je i odluči se, tj ovo je kao da malo zidaš pa se predomisliš o tlocrtu pa rušiš-bušiš.. ako je za učenje, tad je i to učenje, tj brži način dolaska do dllhella ili tako učiš što ne treba raditi jer je život prekratak da bi sve probao-učio-klikao.. tj nikakve posebne koristi nemaš ako sad nađeš fix za ovaj problem nekompatibilnosti kdm-gdm-ldm managera-guija .. tj ako želiš gnome koristiš gdm, ako želiš kde koristiš kdm.. ostalo je upitno tj do prije +5god je kde bio sporedan i zapostavljen, tj ovisi o distri i što tim želi tj debian nije takva distra nego stabilan-temel .. a ako želiš ubuntu ili mint tad njih instaliraš, lakše-brže tj nema smisla na sve trošiti vrijeme jer i prije nego sve poloviš već dođe novi fičer, distra itd.. pa je tako bug managera iz 16te možda još prisutan jer nitko nema vremena-volje-potrebe to fixati.

 

-ponoviš instalaciju s pravim potrebnim managerom od nule, tad nema problema s grub-sec.bootom i sl. pa 99% radi kako očekuješ ili nastaviš tražiti fix (s kojim nisi postao guru-haker tj u učenje spada i pronalazak optimalnog puta, trošenje reusursa na nešto što nije opravdano.. pa i izbor adekvatne distre ili guija i sl.).

Chupo pon 28.6.2021 15:50
ihush kaže...

- u tebi :)

.. tj u kombinaciji, redosljedu, sec.fičerima, grubu, .. kraće dll-hell koji izazivaš korištenjem distre koja je za rad + KISS.

-kad želiš điđemiđe ideš na npr mint, deb je stabilan-čist, ako od njega stvoriš mint tad to nije deb a tad je kraći put instalirati tu distru.

 

-ovisi jel to za rad ili učenje.. ako je za rad, ponovi, brže je i odluči se, tj ovo je kao da malo zidaš pa se predomisliš o tlocrtu pa rušiš-bušiš.. ako je za učenje, tad je i to učenje, tj brži način dolaska do dllhella ili tako učiš što ne treba raditi jer je život prekratak da bi sve probao-učio-klikao.. tj nikakve posebne koristi nemaš ako sad nađeš fix za ovaj problem nekompatibilnosti kdm-gdm-ldm managera-guija .. tj ako želiš gnome koristiš gdm, ako želiš kde koristiš kdm.. ostalo je upitno tj do prije +5god je kde bio sporedan i zapostavljen, tj ovisi o distri i što tim želi tj debian nije takva distra nego stabilan-temel .. a ako želiš ubuntu ili mint tad njih instaliraš, lakše-brže tj nema smisla na sve trošiti vrijeme jer i prije nego sve poloviš već dođe novi fičer, distra itd.. pa je tako bug managera iz 16te možda još prisutan jer nitko nema vremena-volje-potrebe to fixati.

 

-ponoviš instalaciju s pravim potrebnim managerom od nule, tad nema problema s grub-sec.bootom i sl. pa 99% radi kako očekuješ ili nastaviš tražiti fix (s kojim nisi postao guru-haker tj u učenje spada i pronalazak optimalnog puta, trošenje reusursa na nešto što nije opravdano.. pa i izbor adekvatne distre ili guija i sl.).

 

U prvoj instalaciji gdje sam instalirao sve display manager-e mogu koristiti bilo kojeg. Display manageri se moraju moci instalirati naknadno cak i ako je inicijalna instalacija bila headless.

Chupo uto 29.6.2021 01:10
ihush kaže...

-teoretski da, praktično kako kad.. kao što vidiš ili treba 'dokaz'? .. :)

 

Nabrojio si neke od mogucih uzroka problema ali nisi predlozio niti jedno rjesenje osim reinstalacije OS-a.

 

Evo ti onda drugo pitanje:

 

Na SBC je instaliran Debian Buster i kad se na uredjaj spoji preko PuTTY-a onda je situacija sljedeca:

 

a) Kada je u PuTTY-u konfigurirano Window > Translation > Remote character set: UTF-8 onda se u aptitude i recimo armbian-config line drawing characteri za iscrtavanje okvira prikazuju pogresno a u Midnight Commander-u se prikazuju ispravno.

 

b) Kada je u PuTTY-u konfigurirano Window > Translation > Remote character set: Use font encoding onda se u aptitude i recimo armbian-config line drawing characteri za iscrtavanje okvira prikazuju ispravno a u Midnight Commander-u se prikazuju pogresno.

 

U Linux-u je character set podesen kao UTF-8.

 

Sta treba napraviti da bi se line drawing character-i u svim programima prikazivali ispravno?

ihush uto 29.6.2021 11:38
Chupo kaže...
ihush kaže...

-teoretski da, praktično kako kad.. kao što vidiš ili treba 'dokaz'? .. :)

 

Nabrojio si neke od mogucih uzroka problema ali nisi predlozio niti jedno rjesenje osim reinstalacije OS-a.

 

Evo ti onda drugo pitanje:

 

Na SBC je instaliran Debian Buster i kad se na uredjaj spoji preko PuTTY-a onda je situacija sljedeca:

 

a) Kada je u PuTTY-u konfigurirano Window > Translation > Remote character set: UTF-8 onda se u aptitude i recimo armbian-config line drawing characteri za iscrtavanje okvira prikazuju pogresno a u Midnight Commander-u se prikazuju ispravno.

 

b) Kada je u PuTTY-u konfigurirano Window > Translation > Remote character set: Use font encoding onda se u aptitude i recimo armbian-config line drawing characteri za iscrtavanje okvira prikazuju ispravno a u Midnight Commander-u se prikazuju pogresno.

 

U Linux-u je character set podesen kao UTF-8.

 

Sta treba napraviti da bi se line drawing character-i u svim programima prikazivali ispravno?

- riješenje problema dmana ne riješavaju ni timovi koji održavaju dsitru.. zašto/kako bi ja ili ti? tj dok oni to ne riješe nećeš ni ti, dok to navodim kao jedan od mogućih uzroka, možda je nešto treće.

-problem ili uzrok je što se različite stvari ponekad ne poslože do kraja, previše dijelova.. + tempo izmjena iz sasvim drugih razloga i tad taj dio nije u fokusu tj postoji nešto važnije i to se preskoči dok se kroz neko vrijeme neki gui odbaci-zamijeni drugim, fork-forka i svaki guru vuče na nešto svoje. Čim postoji nešto različito postoji moguć problem .. i isti problem ti je u idućem dijelu-pitanju, tj zašto bi neki terminal ili filemanager pogrešno prikazivao neki charset.. a to je jednostavno tako, jer npr usa ne zanima čćđž.. i taj problem im nije u fokusu.

 

-kako se riješava takav problem? .. u samoj app recimo, koja može provjeriti koji charset, regionalne postavke, font itd.. i tad ovisno o tome koristiti za iscrtavanje umjesto ahciija tj sve to može loviti neki presretač no kako će to sve u svim kombinacijama raditi realno ne zanima nikoga tj možeš postaviti bezbrojne situacije-probleme, izmisliti ih.. možeš daleko više nego što ekipa koja to riješava može 'popraviti' .. resursi i smisao, tj stvarnost je takva da se neće sustav prilagoditi tebi nego obrnuto.. mada reklame to sugeriraju.. no možeš vjerovati meni ili reklami, ne moraš.. vidiš rezultat i du-d-mat.

 

-onak,.. što s puttyjem ili mid.commanderom? kakve oni veze imaju s prikazom? .. tj ako možeš pribavi npr neke od starih dos-charset alata (com utilsi, TSR tipa, kao driver) za ahcii-croscii .. i prebacuj se f-tipkama u prikazu tj korištenju kodne stranice npr usa-437 ili 852.. tj microsoft je oduvijek imao 'svoj' standard, no postao defacto standard i konstantno imaš paralalelno kodne stranice, iso-win npr 1250 i 8859-2..

-kraće scrolaj do charova-kodnih stranica i vidi koji je znak na kojem mjestu u kojoj kodnoj tablici.. to je uzrok. Svaki promašaj daje pogrešan prikaz znaka dok točna kodna stranica-tablica daje zamišljen-željeni rezultat, jednako kao i slova ili qwertrz-qwerty tj sam raspored fizičkih tipki po qweretiju ili dvoraku itd.

-kad koristiš takve dodatke, 'dos-tipka' i sl. oni mijenjaju (remapiraju) chr$ kod na željeni.. teoretski, dok je većina hardkodiranog u usa-437 tj većina programskih alata neovisno o platformi, basic, c, visualstudio-ide.. koriste tu kodnu stranicu ispod haube i rezultat je takav tj kad to neka app predviđa-koristi tad to može biti pravilno prikazano, pa će neka app koju su radili programeri iz naših krajeva pravilno prikazivati u oba slučaja dok će zapadne-usa apps prikazivati točno samo usa, ostale ne baš pa do tog da uopće nemaju neki char-znak neko slovo ili oznaku € Ć dok se Đ koristi kao backslash ... tj znak koji može stvarati problem (rušenje) ako ga se pokušava pogrešno printati jer je recimo nedozvoljen znak u nazivu zato jer se koristi kao file marker patha.. tj razlika linuxa i dos-wina recimo mala-VELIKA slova.. dok je *nixu sve samo file a naziv ili path su samo kombinacija znakova koja može biti bilo koja, pa pod linuxom nije .exe nešto što pokrećeš kao pod win-dosom tj sve je file a da bi ga pravilno pročitao-tumačio moraš znati što svaki byte u njemu predstavlja, jer su sve to binarne nul-jedinice a značenje im je u nekom trenutku npr slovo A u drugom operacija-funkcija ili adresa pointera.. tj interpretacija je problem kao i dekripcija filea kad nemaš ključ i tebi interpreter prikazuje ono što misli da treba prikazati dok je byte koji dobije isti, kad promjeniš char enkoding tad prikazuje po drugom rasporedu, no možda treba po trećem, četvrtom.. ima toga :) + ovisi o tome koliko je prljavo napravljena app tj zato su 'naše' po tome bolje jer kreću s tim setovima i moraju biti kompatibilne s usa, obrnuto ne baš..

-soft-util tog tipa je već zaboravljen u povijesti, s dosom, danas nećeš nešto lako pronaći, pogotovo linux koji jednostavno nije bio dominantan kao dos-win i time alati-riješenja..

 

-što time želiš? može slika problema? tj iscrtavanje ascii-croscii je nevažno, ignoriraš osim ako baš trebaš, a ako pokušavaš portati neki stari soft, tad napravi kako spada, ne copypaste nego napraviš po današnjim pravilima čisto, ne prljavo kao to staro sa zakrpom, jer tako problem ostaje, tj tad je ta zakrpa potrebna i ako je netko nema problem je opet tu (na drugom računalu, drugi os..) .. potraži stare dosovske alate, ne znam da postoje noviji ili linux verzije i vidi kako rade, što rade, tad će ti biti jasno kako tražiti riješenje.

 

-prikaz nekog frontenda, x11, terminal.. je stvar tog guija, njegovih pravila, mogućnosti pa i kodnih stranica koje koristi, a to nije nešto što radi-popravlja juzer, nego je to stvar distre i platforme kao i standarda.

 

(a nikako mi nije jasno što želiš, tj kakve veze ima neki filemanager kao mc i prikaz.. tj želiš da se pod različitim kodnim stranicama ponašaju isto-točno, a to tako ne radi, tj takve app recimo dosovskog tipa koriste char kao slovo-znak i upravo zato postoji standard, tj ne prikazuje se tad nešto pogrešno nego upravo kako je napravljeno s time da je tad pogrešna kodna stranica i umjesto očekivanog-željenog znaka dobiješ čvrčku no sa samom app kao mc to nema veze tj to radi frontend koji presreće skenkodove i prikazuje ih na ekranu ili pisaću itd. tj to rade oni dos utilsi kao konverteri kad 'popravljaju' pogrešnu cp koja ne može biti točna-kriva nego samo željeno slovo-znak u tablici je ili nije ono što želimo.. hoće li to fixati nekei TSR ili ćeš promijeniti CP rezultat je isti (dvostruka negacija, dvostuka komutacija, isti rezultat).. no to ne eliminira razliku u tome da svaka app za sebe živi i koristi cp tj postavka za jedan slučaj je ok no to ne znači da je za sve-ostale.. i upravo tako dobiješ riješiš jedno, pokvariš drugo, jer to je tako, ili-ili ili je slovo A ili B ili je qwertz ili je qwerty.. a da bi bilo točno, moraju svi dijelovi biti jednako podešeni, dok različite app to nisu nego su neovisne o ostatku svemira, pogotovo u linux svijetu gdje ne moraju koristiti ni isti x-gui dok su pod mac-win ipak jedan os, tj sama razmrvljenost distri stvara takav problem kad si recimo 'mali narod' za fontove, dok tad dominira glavni-usa a svatko se tad mora pobrinuti za sebe, napraviti svoj font itd. Problem koji je trajao dugo i bio nerješiv, pa ga nećeš ni ti sad riješiti, pogotovo što sad nema smisla, tj nepotrebno jer dos ili terminal nisu ono što je danas u fokusu IT biza, tj kao programiranje u asembleru vs pythonu i sl. efikasnost, smisao i mogućnosti novih računala s resursima pa korištenje par KiBija umjesto GiBija nije važno tj ne štedi se ram i sl.. važniji je internet browser nego putty ili mc .. tj pitaj prosječnog juzera zna li što je npr nc? prethodnik mc-a.. kome je to danas važno-potrebno dok svi znaju za chrome, koji pravilno prikazuje slova, slike, yt ..)

Chupo uto 29.6.2021 15:18
ihush kaže...

-onak,.. što s puttyjem ili mid.commanderom? kakve oni veze imaju s prikazom? .. tj ako možeš pribavi npr neke od starih dos-charset alata (com utilsi, TSR tipa, kao driver) za ahcii-croscii .. i prebacuj se f-tipkama u prikazu tj korištenju kodne stranice npr usa-437 ili 852.. tj microsoft je oduvijek imao 'svoj' standard, no postao defacto standard i konstantno imaš paralalelno kodne stranice, iso-win npr 1250 i 8859-2..

 

Cekaj malo - tu smo na dijelu foruma gdje se raspravlja o Linuxu a ti pricas o DOS-u!?

 

I pitas me: "što s puttyjem ili mid.commanderom?", a u pitanju sam to sta pitas objasnio detaljno.

 

Znaci:

 

- Na SBC board-u (u ovom slucaju na Orange Pi PC-u) je instaliran Linux

 

- Na SBC se s Windows kompjutera spajam preko SSH a za to koristim PuTTY

 

- Character set podesen u Linux-u je UTF-8

 

- Govorimo o line drawing characterima

 

A ti pises o DOS-u, o croscii fontovima koji rjesavaju probleme s mapiranjem nasih slova u nekoliko razlicitih encoding-a koji su se koristili u DOS-u i u ranijim verzijama Windows-a, spominjes TSR alate koji presrecu evente pa pritiske na tipke mapiraju s obzirom na odabrani standard (vjerojatno mislis na Bronzinove programe Tipka i Tipkawin), spominjes browser i raspravljas o tome da li prosjecni korisnik zna sta je Norton Commander a ne spominjes recimo ncurses s kojim je radjen aptitude komandnolinijski frontend a koji se, kako sam napisao, ponasa isto kao i frontend za armbian-config.

 

I jos si napisao: "a nikako mi nije jasno što želiš, tj kakve veze ima neki filemanager kao mc i prikaz..". Cini se kao da nisi procitao dio texta u kojem sam napisao da se preko PuTTY-a u sklopu kojeg postoji terminal emulator spajam na uredjaj na kojem je headless instalacija Linuxa. A na to pitanje sam odgovorio vec u inicijalnom postu kad sam napisao: "Sta treba napraviti da bi se line drawing character-i u svim programima prikazivali ispravno?".

 

Linux sam instalirao preko Armbian repozitorija:

 

https://docs.armbian.com/

 

a jedini razlog zasto pitanje postavljam ovdje je jer vec par dana cekam da mi administrator na Armbian forumu aktivira account pa da mogu otvoriti topic.

 

Pitao si za slike problema, evo i slika:

 

01: U PuTTY je translation opcija koju sam spomenuo ranije podesena na UTF-8

02: U PuTTY je translation opcija koju sam spomenuo ranije podesena na Use font encoding

03: U PuTTY je translation opcija koju sam spomenuo ranije podesena na UTF-8

04: U PuTTY je translation opcija koju sam spomenuo ranije podesena na Use font encoding

Djuro von Prekoplotovich uto 29.6.2021 16:03
Chupo kaže...
ihush kaže...

-teoretski da, praktično kako kad.. kao što vidiš ili treba 'dokaz'? .. :)

 

Nabrojio si neke od mogucih uzroka problema ali nisi predlozio niti jedno rjesenje osim reinstalacije OS-a.

 

Evo ti onda drugo pitanje:

 

Na SBC je instaliran Debian Buster i kad se na uredjaj spoji preko PuTTY-a onda je situacija sljedeca:

 

a) Kada je u PuTTY-u konfigurirano Window > Translation > Remote character set: UTF-8 onda se u aptitude i recimo armbian-config line drawing characteri za iscrtavanje okvira prikazuju pogresno a u Midnight Commander-u se prikazuju ispravno.

 

b) Kada je u PuTTY-u konfigurirano Window > Translation > Remote character set: Use font encoding onda se u aptitude i recimo armbian-config line drawing characteri za iscrtavanje okvira prikazuju ispravno a u Midnight Commander-u se prikazuju pogresno.

 

U Linux-u je character set podesen kao UTF-8.

 

Sta treba napraviti da bi se line drawing character-i u svim programima prikazivali ispravno?

 

PuTTY nije taknut vec dulje vrijeme, osim kada su nedavno isli pokrpati jedan kriticni bug.

Ovi moji na poslu koriste KiTTY (https://www.9bis.net/kitty/#!index.md, fork PuTTY-a).

On ima opcije za eksplicitno podesavanje tih featurea koje trebas (line drawing).

Probaj s time.

Ili probaj s neke druge Linux kante.

 

Za tvoje pitanje vezano uz DE - moze biti svasta. Od konfiguracije, ili biblioteka, do systemd-a. Bez logova je tesko gatati na daljinu.

Uzmi zadnji Devuan, stavi ga u virtualku i probaj napraviti isto. Ako na njemu radi, onda je do systemd-a.

Devuan je bliski fork Debiana i koristi prakticno iste pakete i u 99% slucajeva sa istim verzijama.

 

Ne svadjaj se s ihushom, on je lokalni AI, mislim da ce ga uskoro prebaciti na GPT-4.

ihush sri 30.6.2021 02:12
Chupo kaže...
.. "Sta treba napraviti da bi se line drawing character-i u svim programima prikazivali ispravno?".

..

 -ništa, tj ne možeš ništa, jer program je kakav je i uopće to nije stvar programa, nego aktivne codne stranice npr ekranskog prikaza display managera koji ako je cp437 prikazuje za chr-x neki znak, dok na 8859-2 isti ili drugi, na 1250 treći itd.. tj to je razlika kodnih stranica i nikako ne možeš različite stvari prikazati istovremeno, istom postavkom jednako-točno-željeno, naprosto je umjesto recimo crte neki drugi znak (pogledaj slike..) dok line-draving ekšli ne postoji jer se ne iscrtava grafički objekt linija-pixel i sl nego char iz charseta izabrane stranice a to je definiran raster pixela koji može biti bilo što, prazan-blank do potpuno pun-invertan ovisno o dimenziji slova (ili fonta) u text modu kao i rezoluciji i dimenziji ekrana ili drugog objekta kao printera i sl. ali je jedan znak u izabranoj kodnoj stranici, nije drugi istovremeno što ti za različite stvari treba da bi bile jednako-točno prikazane, tj ono što je različito nije isto... i zato imaš tu situaciju.

 

-lako je s textom, file, konvertiraš ga u 'pravi' format, npr s našim slovima na pravom mjestu i tad umjesot čvrčki imaš čitljiv text, no s appsima to ne možeš, jer nije samo text, tj to je interno hardkodirano i tad bi interno trebao zamijeniti samo taj dio, dok konverzija na nivou filea mijenja sve a to tad mijenja i sam kod koji ne mora biti grafički prikaz-tablica nego može biti operacija-rutina-nešto što app radi tj ovisi o tom dijelu jel grafički prikaz ili nešto drugo dok je sam kod-char možda isti kao što bi vidio 'iste' charove da otvoriš razne fileove, npr text, sliku, zvuk, program.. vidjet ćeš hrpe čvrčki i nešto čitljivog texta, no ta čvrčka je u svakom fileu nešto drugo, pixel, operacija, zvuk.. itd.. ne samo crta.

 

-usporedba s dosom jer od njega to počinje, dominira kao i win i 99% povijesnih problema kao i standarda je s tim povezano kao i s ibm-om.. dok je linux začet na dosu kao nadogradnja.

-jednostavno linux zajednica nema toliko alata iz tog doba, za usporedbu, dok je putty nešto s dos/wina, kao i nc.. pa zato pomisao da pokušavaš nešto sa starim appsima recimo iz dosa.. tj dos-lin.. razlike su minorne u osnovi, kao auto-traktor, svi imaju motor, kotače, volan..

 

-prijašnje pitanje o problemu display managera, zašto nešto ne radi ldm-gdm-kdm.. pa primjer, 2016ta, kdm.. problem iz kojeg je zamienjen sddmom.. u vrijeme kad su prelazili na systemd.. pa se sad opet vraćaju na gnome3 i klasične x-e.. tj svakih nešto godina se sve promijeni, raspadne-pokrpa i tad opet treba vremena dok se sve uskladi a nešto se napusti. To rade timovi pa im ne ide baš.. tako da nećeš ni ti uspjeti nešto više.

 

vidi što sugeriraju:

One important point to note that, currently due to a bug (I checked in 16.04) you cannot start GNOME3 or Ubuntu Unity session using SDDM. So, if you have both KDE and Unity or GNOME3 installed, make sure your display manager is either gdm3 or lightdm.

 

Chupo sri 30.6.2021 02:24
Djuro von Prekoplotovich kaže...

PuTTY nije taknut vec dulje vrijeme, osim kada su nedavno isli pokrpati jedan kriticni bug.

Ovi moji na poslu koriste KiTTY (https://www.9bis.net/kitty/#!index.md, fork PuTTY-a).

On ima opcije za eksplicitno podesavanje tih featurea koje trebas (line drawing).

Probaj s time.

Ili probaj s neke druge Linux kante.

 

Kad se na isti uredjaj spajam preko SSH iz terminala u Debianu instaliranim u Virtualbox onda su u svim programima svi karakteri ispravni. Znaci da je problem u PuTTY-u. Ali nije mi jasno zasto bi isti terminal emulator u slucaju jednog programa UTF-8 charactere prikazivao na jedan nacin a u slucaju drugog programa na drugi nacin. Jedina razlika koju vidim je da se u slucaju kad se umjesto line drawing character-a u prvom slucaju prikazuju l, q, x, k, i m characteri a u drugom slucaju se umjesto svakog specijalnog character-a prikazuje nekoliko pogresnih znakova pa to vjerojatno znaci da kodovi u prvom slucaju zauzimaju jedan byte a u drugom slucaju zauzimaju vise byte-ova.

 

Vidim da u PuTTY-u ima i opcija "Copy and paste line drawing characters as lqqqk" a bas se ti characteri u prvom slucaju prikazuju umjesto znakova za okvire.

 

EDIT:

Nakon desetaka clanaka na Stackoverflow i raznim forumima sam na kraju naletio na ovo pitanje gdje je netko odgovorio da u PuTTY > Connection > Data treba pod opcijom Terminal-type string umjesto xterm upisati linux i nakon toga se znakovi u svim programima prikazuju ispravno.

 

Djuro von Prekoplotovich kaže...
Za tvoje pitanje vezano uz DE - moze biti svasta. Od konfiguracije, ili biblioteka, do systemd-a. Bez logova je tesko gatati na daljinu.

Uzmi zadnji Devuan, stavi ga u virtualku i probaj napraviti isto. Ako na njemu radi, onda je do systemd-a.

Devuan je bliski fork Debiana i koristi prakticno iste pakete i u 99% slucajeva sa istim verzijama.

 

Nije mi problem instalirati novu virtualnu masinu ili klonirati postojecu ali me bas zanima u cemu je stvar i kako bi se to moglo rijesiti.

 

Djuro von Prekoplotovich kaže...
Ne svadjaj se s ihushom, on je lokalni AI, mislim da ce ga uskoro prebaciti na GPT-4.

 

:-))

Djuro von Prekoplotovich sri 30.6.2021 12:56
Chupo kaže...

Ali nije mi jasno zasto bi isti terminal emulator u slucaju jednog programa UTF-8 charactere prikazivao na jedan nacin a u slucaju drugog programa na drugi nacin. 

Vidim da u PuTTY-u ima i opcija "Copy and paste line drawing characters as lqqqk" a bas se ti characteri u prvom slucaju prikazuju umjesto znakova za okvire.

 


 

Nije mi problem instalirati novu virtualnu masinu ili klonirati postojecu ali me bas zanima u cemu je stvar i kako bi se to moglo rijesiti.

 

 

UTF je kompliciran i broj programera koji ga ne razumije je veci od onih koji znaju o cemu se radi.

Terminal-emulatori su takodjer komplicirani, kod njih moras viditi racuna o bugovima starima vise desetljeca i koji nikada nece biti ispravljeni.

 

Ne, nisam rekao da koristis Devuan, nego ga instaliraj i provjeri ima li isti problem. Ako nema, znati ces gdje provjeravati dalje na Debianu.

Chupo čet 1.7.2021 00:24
Djuro von Prekoplotovich kaže...

UTF je kompliciran i broj programera koji ga ne razumije je veci od onih koji znaju o cemu se radi.

Terminal-emulatori su takodjer komplicirani, kod njih moras viditi racuna o bugovima starima vise desetljeca i koji nikada nece biti ispravljeni.

 

Ne, nisam rekao da koristis Devuan, nego ga instaliraj i provjeri ima li isti problem. Ako nema, znati ces gdje provjeravati dalje na Debianu.

 

Sad je s ovim kako sam napisao rijeseno i sve radi ispravno.

 

EDIT:

Ipak ima jedna razlika - kad se za Terminal-type string umjesto "xterm" stavi "linux" onda se karakteri u svim programima prikazuju ispravno ali se u programima tipa Midnight Commander vise ne moze u terminalu koristiti i mis a s "xterm" se moze.

Zechina čet 8.7.2021 17:35
Chupo kaže...

EDIT:

Ipak ima jedna razlika - kad se za Terminal-type string umjesto "xterm" stavi "linux" onda se karakteri u svim programima prikazuju ispravno ali se u programima tipa Midnight Commander vise ne moze u terminalu koristiti i mis a s "xterm" se moze.

 
Tek Midnight Commander ti je kaos za namjestiti kad ne radi: sve funkcije nisu implementrane; neke ne rade, neke ne rade točno kako su opisane a neke su žbrlj bagovite.
Osnovne funkcije ugl. dobro rade, ali probaj npr "skin" (setting boja) promijeniti - zamrzit ćeš De Icazu više nego li MS korisnici ;)

ihush sub 17.7.2021 08:50

-normalno.. čak očekivano.

-msu odavno nije važan koji os juzer koristi (ako će plaćati usluge msu)..

-os? .. os je samo os, dok je ovo još samo jedna distra (i to dobra za namjenu..).

-čude se stručnjaci? iznenađeni? pa čak i recimo kvalitetom? .. ili time što ms oko toga ne radi promociju (mada radi, geekovski tj pravim načinom kako se umiliti geekovima, hvaleći linux itd. jer nema više neprijatelja..).

 

-par desetljeća, 'samo što nije' .. 'lin će pojesti win'.. i tad to napravi sam ms dok simbolički host (server) guesta clientside, upravo neki dan objavljen win365..

-paradox ali ne kad se gleda stanje na tržištu, tj paradox je samo dok geekovi ostaju 'neprijatelji' u rovovima umjesto da se o softu razmišlja kao o softu.. dok je os ili u ovom slučaju distra samo nakupina modula koji rade ono što os treba raditi, što os je, .. most za hw-appse, dok je frontend samo skin ili stvar ukusa.

ihush čet 12.8.2021 10:43
Zechina kaže...

.. i zašto (i ima smisla):

..

 

 -to se moglo (trebalo) znati od početka, svaka 'kutijica' koju juzer koristi na način upali-vozi, je 'bolja' s rollingom (eliminira dllhell problem usklađenosti verzija sys-dijelova.. jer se updatea sve) itd.

-no za soft je lako, do sad je falio temelj.. tj konzola, koja će možda sad zaživjeti pa je izgleda i vrijeme da se ozbiljnije razmisli o softu .. dok je steamos završio gdje mu je i mjesto :)