» »

Raspberry Pi & alternative

Raspberry Pi & alternative

««
20 / 23
»»

dottor ::

Objavljeno je bilo 1. apr. 2019

Ne preveč računat na to ;)
Xeon X5650@3.8GHz |Asus P6T|
2x4GB+4x2GB|ASUS R9 280X@1100MHz|
WD Green 240GB SSD + 4x1TB Hitachi

Red_Mamba ::

taz je izjavil:

rPi 4 (več verzij)



1. april :D
[st.slika https://img.shields.io/badge/Slo-Tech-green.svg test]
Linkedin >> http://goo.gl/839Aua
Mamba's Crypto & ICO's: https://t.me/joinchat/AAAAAExTkO4P4UDy0fIZdg

taz ::

dottor je izjavil:

Objavljeno je bilo 1. apr. 2019

Ne preveč računat na to ;)

Damt :D
Čeprou sm nekaj časa ustrajal z rPi, potem pa raje uporabil Core2Quad 6600, ko najdem pametno ponudbo bo sledil i3 8100. :D
Bi pa bil zanimiv tak Pi za kakšne manj zahtevne stvari.
Main: i7 870, 4x4 GB, Asus P7P55D-E EVO,6950@6970,Samsung840PRO,2x1TB WD Green
Smart home: Q6600, 8GB, Crucial BX120

dottor ::

Q6600 jaz še vedno uporabljam v kleti za 3D modeliranje, skupaj z 8GB rama in GTX260 216sp za CUDA podporo. Pač poleg 3D tiskalnika imam še en PC za generirat g-kodo in delanje popravkov na 3D modelu. Pa zadeva lavfa kar tekoče SolidWorks.
Xeon X5650@3.8GHz |Asus P6T|
2x4GB+4x2GB|ASUS R9 280X@1100MHz|
WD Green 240GB SSD + 4x1TB Hitachi

dottor ::

Ima RPi kakšen stabilen sistem za PCoIP? Na Windows Server 2016 bi virtualiziral Win10 za očeta, client pa bi postavu na RPi 3 B+ (za priklop ekrana, miške, tipkovnice in zvočnikov).
Xeon X5650@3.8GHz |Asus P6T|
2x4GB+4x2GB|ASUS R9 280X@1100MHz|
WD Green 240GB SSD + 4x1TB Hitachi

Irbis ::

Za PCoIP ne vem, za priklop z RDP na Win10 mi pa odlično deluje Remmina na Ubuntu MATE.

dottor ::

No da poskusim tole kako se odnese (za enkrat v virtualki). Hvala za enkrat.
Xeon X5650@3.8GHz |Asus P6T|
2x4GB+4x2GB|ASUS R9 280X@1100MHz|
WD Green 240GB SSD + 4x1TB Hitachi

Cr00k ::

Poglejte Nvidia Jetson Nano Developer Kit... jaz sem ga včeraj dobil. Petarda.

link_up ::

hehe, potem pa fotru dnevno snapshot delas. Naj se kriptira, bo vsaj virtualka imela kaj poceti :D
In and Out

BigWhale ::

Cr00k je izjavil:

Poglejte Nvidia Jetson Nano Developer Kit... jaz sem ga včeraj dobil. Petarda.


Ce mas za kaj rabit zgleda kr kul. :)

dottor ::

Dat 100€ za to da mi poganja kot client je malo brezveze... Sem prej poskusu Remmina pa zgleda delovat dovolj dobro :) Sicer sem testital vse v virtualkah (virtualiziran Win10 in Ubuntu), tako da predvidevam da bo na RPiju delalo lih tako vredu. Morem naročit enega pa sprovat :) Pa še dodatnega rama nabavit, ampak kaj ko je DDR3 še vedno malo predrag (rabim 4x4GB, alpa ECC E-ram (U-rem ne dela kljub Xeonu ga chipset ne da skozi).
Xeon X5650@3.8GHz |Asus P6T|
2x4GB+4x2GB|ASUS R9 280X@1100MHz|
WD Green 240GB SSD + 4x1TB Hitachi

youPlonker ::

Mogoče kdo ve, kje nabaviti nvidia Jetson Nano v eu?

Tenkju.

kihc ::

Živijo,

bolj nazaj v temi se precej omenja BME280 senzor. Ker je sam senzor kot vidim na voljo samo v SMD obliki, katere zadeve vi nabavljate, da se jih da prispajkat z DIY opremo?
6e673e69b8f91709aefa16c3594bb113

strumf666 ::

Member of OC-Lab Team
http://www.oc-lab.si/

techfreak :) ::

Pazi da bos res kupil BME280 in ne BMP280: https://goughlui.com/2018/08/05/note-bo...

kihc ::

Torej npr. tole: https://www.aliexpress.com/item/3284946... ?

Ni mi jasno, kako je lahko izven Kitajske cena samo čipa 5$, Kitajci pa imajo skupaj s PCB po 2,5$.
6e673e69b8f91709aefa16c3594bb113

hojnikb ::

marže.
#teamred
MediaBox: AMD R5 1600 AF, 16GB DDR4, 256GB SSD, 1060 6GB, B450M-DS3H, W10

BigWhale ::

Ce na Digikey pogledas ceno za BME280 senzor, je cena za en kos $6.5 ce vzames samo en kos. Ce jih vzames 1000 je pa cena za en kos $2.7 :) Pri deset tisoc je pa cena verjetno se nizja. :)

hojnikb ::

pri kitajcih tut ni 2x za rect, da je senzor kaksen njihov fake za 10c :)
#teamred
MediaBox: AMD R5 1600 AF, 16GB DDR4, 256GB SSD, 1060 6GB, B450M-DS3H, W10

kihc ::

Buo, skratka naročim in poročam. :)
6e673e69b8f91709aefa16c3594bb113

Dzhimen ::

Lep pozdrav.

Eno hitro vprašanje bi imel jaz glede Raspberry Pi 3B+, če ima kdo mogoče izkušnje iz prve roke glede "štopanja" časa na tej zadevi...

Kolega ima omenjeni model maline z Linuxom in piše program v C-ju, ki bi moral do 1 ms (milisekunde) natančno merit čas med dvema dogodkoma. Rekel je, da če nastavi te dogodke tako, da je med dvema dogodkoma cca 20ms, da zadeva deluje natančno (pravilno izmeri čas med dvema dogodkoma). Ko pa nastavi te dogodke da so na 4 ms narazen, pa stvar odpove in pridejo odstopanja do nekaj procentov, kar je za ta konkreten primer nedopustno. On pravi da je vse drugo eliminiral (žice, konektorje, procesor in RAM nista niti približno obremenjena, različne knjižnice je probal itd.) in da je prišel do zaključka da je kriv OS. Se pravi da se zaradi schedulerja klic funkcije za čas ob nekem dogodku ne izvede takoj in zato pride do napak pri merjenju časa med dvema dogodkoma. Probal je tudi z interrupti, ampak je bila napaka začuda še večja.


Moje vprašanje je samo tole: Ali je možno da Raspberry Pi 3B+ z Linux OS-om ne more beležiti časa na recimo 1ms natančno?

Vem da je možnih še veliko drugih vzrokov za tole napako, ampak me zanima ali mi kdo lahko iz prve roke z zagotovostjo pove, da ni kriv scheduler OS-a, tako da se lahko tole hipotezo eliminira ter se gre raziskovat druge vzroke?

Hvala lepa že vnaprej!

BigWhale ::

Pogledat je treba za kak Real Time operating system za RPi.

https://www.freertos.org/about-RTOS.html ali kaj podobnega.

1ms locljivost tezko dosezes z operacijskim sistemom, ki ni narejen posebaj za te reci, ker ti lahko neka I/O operacija od kaksnega drugega procesa zakasni zadeve.

Al to, al pa kak Ardiuno kot buffer, da lahko dogodke obdelas dovolj hitro, RPi pa potem pobira te stvari od Arduina.

hruske ::

To, da je z interrupti napaka še večja, je normalno. Praviloma se v interruptih ne naredi kaj dosti, ampak se jih uporablja samo za obveščanje, da je nekaj za prebrat.

Lahko poskusiš izolirat eno jedro - nastavit vse procese, da se izvajajo na vseh razen enem. Na tem prostem CPUju (in samo na tem) potem poganjaš program za branje, kjer delaš busy poll, ker je to najboljši način da dobiš kolikor toliko ok rezultat.

Ampak ja, verjetno rabiš arduino.

Relevantno branje: https://www.tablix.org/~avian/blog/arch...
Rad imam tole državico. <3

misek ::

twom ::

Gor daj real time operacijski sistem. RTOS ali kaj podobnega, ne vem kaj je na voljo za Raspberry.

Dzhimen ::

Hvala vsem za odgovore.

Razvija se rešitev, kot jo je BigWhale opisal. Arduino bo buffer in bo komuniciral z malino. Lahko da se bo celo celotna zadeva na arduino preselila, da ne bo treba met dveh ploščic...

Kakorkoli, hvala! ;)

misek ::

Sicer precej dražja rešitev ampak vseeno za splošno razgledanost :)
https://www.udoo.org/udoo-x86/
https://www.udoo.org/udoo-neo/
https://www.udoo.org/udoo-dual-and-quad/

BigWhale ::

Dzhimen je izjavil:

Hvala vsem za odgovore.

Razvija se rešitev, kot jo je BigWhale opisal. Arduino bo buffer in bo komuniciral z malino. Lahko da se bo celo celotna zadeva na arduino preselila, da ne bo treba met dveh ploščic...

Kakorkoli, hvala! ;)


Potem se splaca pogledat tudi ESP32 boarde. Zadeve imajo ze WiFi in BT in so dovolj zmogljive za marsikaj.

igorpec ::

BigWhale je izjavil:

Dzhimen je izjavil:

Hvala vsem za odgovore.

Razvija se rešitev, kot jo je BigWhale opisal. Arduino bo buffer in bo komuniciral z malino. Lahko da se bo celo celotna zadeva na arduino preselila, da ne bo treba met dveh ploščic...

Kakorkoli, hvala! ;)


Potem se splaca pogledat tudi ESP32 boarde. Zadeve imajo ze WiFi in BT in so dovolj zmogljive za marsikaj.


Mogoče tole, Rpi factor plata:
https://www.crowdsupply.com/thomas-mcka...

kihc ::

kihc je izjavil:

Torej npr. tole: https://www.aliexpress.com/item/3284946... ?

Ni mi jasno, kako je lahko izven Kitajske cena samo čipa 5$, Kitajci pa imajo skupaj s PCB po 2,5$.


Evo, tole sem dobil, zadeva deluje b.p.
6e673e69b8f91709aefa16c3594bb113

pierch ::

Good news za rockchip naprave.
Pierch

Ahim ::

pierch je izjavil:

Good news za rockchip naprave.

Bo to pricurljalo tudi na OrangePi RK3399 in podobne?

igorpec ::

Ahim je izjavil:

pierch je izjavil:

Good news za rockchip naprave.

Bo to pricurljalo tudi na OrangePi RK3399 in podobne?


Seveda.

AndrejO ::

Ker je S-T bolj stabilen, kot pa moji povsod raztreseni zapiski ... zaznamek za naslednjič, ko ga bom potreboval.

RPi 2/3/3+ in 64-bit Fedora 28/29/30: Zadeva kot mini strežnik načeloma deluje brez težav (kar pomeni, da grafike nisem niti povohal). Kar je moteče je to, da Fedora načeloma pravilno uporabi drevo naprav (Device Tree; DT) priloženo jedru in ne tistega, ki mu ga da na voljo GPU. Stvar je moteča, ker je potrebno za vsak na GPIO/SPI/I2C/... dodan kos strojne opreme posebej pacati DTB in telovaditi s podtikanjem tega DTB-ja na pravo lokacijo od koder se ga bo naložilo. Pri vsakem "dnf upgrade" to postane faktor tveganja.

Pogled pod havbo pokaže, da DTB dejansko naloži U-Boot, ki v nadaljevanju zgodbe zažene EFI zagon, kateremu posreduje naslov naloženega drevesa. Če drevesa ni mogel najti, pa mu posreduje vgrajeno/od_naprave_dostavljeno drevo. Za tukajšnjo razlago naj zadošča, da na RPi to drevo naloži GPU na naslov, ki ga U-Boot pozna, druge naprave pa imajo lahko to rešeno tudi drugače.

Dejanski fragment skripte, ki (posredno) zažene Grub izgleda tako:
if fdt addr ${fdt_addr_r}; then
  bootefi ${kernel_addr_r} ${fdt_addr_r}
else
  bootefi ${kernel_addr_r} ${fdtcontroladdr}
fi

Prevedeno v slovenščino, se glasi tako: preveri DT na naslovu ${fdt_addr_r}. Če tam DT obstaja, potem se kot EFI aplikacijo zažene blob naložen na naslovu ${kernel_addr_r}, posreduje pa se mu DT iz naslova ${fdt_addr_r}. Če DT tam ne obstaja, se zažene isto EFI aplikacijo, vendar z DT-jem na naslovu ${fdtcontroladdr}.

Spremenljivke imajo sicer ta pomen:
${fdt_addr_r}: naslov kamor je U-Boot (morda) naložil DTB za to napravo. V danem primeru se naloži DTB priložen Fedora jedru, ki prihaja iz kernel.org.
${kernel_addr_r}: naslov kamor je U-Boot naložil /EFI/BOOT/BOOTAA64.EFI iz EFI particije. Na Fedori je to shim, ki ve kako ugotoviti kje najti Grub za Fedoro (in še kaj drugega, če je tam in opremeljeno z ustreznim opisom).
${fdtcontroladdr}: Naslov, na katerem U-Boot pri svoji lastni inicializaciji (ker konec koncev mora tudi U-Boot vedeti kakšno strojno opremo ima - MMC, USB, NIC, ...) najde DT za napravo. Na RPi je to DT, ki ga je naložil GPU, preden je predal kontrolo U-Boot, ki deluje na CPU-ju.

Cilj je torej, da se fedorinega (oz. kernel.org) DT-ja ne naloži, temveč se EFI-ju pošlje DT, ki ga je pripravil GPU. Na srečo standardna U-Boot zagonska sekvenca predvideva tudi zagon skripte (/boot.scr) v katero lahko podtaknem, kar je potrebno, da bi to dosegel. Najprej moram preprečiti, da bi U-Boot sploh našel DTB za napravo, za vsak primer pa moram poskrbeti, da če je na ${fdt_addr_r} slučajno že sintaktično pravilen DT (se zgodi, pogled pod havbo U-Boot lahko radovednim pokaže zakaj), da ta ne bo spoznan.

Za ta namen zadošča skripta, ki jo shranim v boot.cmd:
setenv fdtfile nofile.dtb
mw.b ${fdt_addr_r} 0 1

Prva vrstica "pokvari" spremenljivko v kateri je zapisano ime DTB-ja za SoC in, ki ga bo U-Boot poskušal najti in naložiti. Druga vrstica pa pokvari prvi byte DT-ja, ki se bi slučajno že nahajal na naslovu ${fdt_addr_r}. Oboje skupaj zagotovi, da bo bootefi uporabil DT, ki ga je za SoC že pripravil GPU.

Skripto je potrebno še prevesti (kot root):
mkimage -A arm64 -T script -C none -d boot.cmd boot.scr
sudo cp boot.scr /boot/efi/

mkimage je orodje, ki se ga na Fedori najde v paketu uboot-tools (sudo dnf install uboot-tools).

E, voila. Sedaj se lahko v /boot/efi/config.txt po mili volji dodaja razne dtoverlay=... ukaze, kot to lahko počno uporabniki raspbiana. GPU bo config.txt prebral, postoril, kar je potrebno, naflikal stvari v DT in šele potem prepustil nadzor U-Boot na CPU-ju. Temu zaradi sveže dodane /boot/efi/boot.scr skripte ne bo uspelo uporabi fedorinega DTB-ja, kar pomeni, da bo uporabljen "tapravi", ki ga je pripravil GPU. Da bo stvar dejansko delovala je v config.txt verjetno potrebno ohraniti dtoverlay=upstream, kar pa načeloma ni težava. Fedora ta dodatek privzeto že ima.

Zgodovina sprememb…

  • spremenil: AndrejO ()

hojnikb ::

Js sn kr zadovoljen s stock debian lite. Naložu, skofiguriru in je to to. Kot NAS/Torrent/Nextcloud server čisto ok zadeva na rpi4. Prav tako nobenih težav z pregrevanjem, s katerim radi tukaj strašijo (večino časa čepi pod 60C)
#teamred
MediaBox: AMD R5 1600 AF, 16GB DDR4, 256GB SSD, 1060 6GB, B450M-DS3H, W10

Zgodovina sprememb…

  • spremenil: hojnikb ()

AndrejO ::

Zame je fora samo to, da imam neko standardno AArch64 distribucijo, glede na to, da RPi fundacije te stvari ne zanimajo. Stock distribucije (64- in 32- bitne) načeloma delajo b.p., ker gonilniki za strojno opremo obstajajo, kar je ni preveč zaprte (kreh, Broadcom, kreh, VC4, kreh, naj jih koklja brcne, kreh).

Moj žulj je bil samo to, da skoraj vse, kar priključiš na 40-pin konektor ima gonilnike, ne moreš pa jedru enostavno pojasniti kaj je kje priključeno, ker DT overlayi še nimajo izdelanih orodij. No, dokler to delo ne bo zaključeno, bo izgleda potrebno malo popacati U-Boot, da se izkoristi to, kar RPi že ima. Na kakšnem drugem SoC (kreh, Rockchip, kreh, lenobe lene, ki ničesar ne porinejo do konca do kernel.org, kreh, naj vas tudi koklja brcne) sem to moral urediti z malo bolj obsežno skripto.

Na koncu dneva mi je pomembno to, da ima 64 bitkov, ARM in ravno prav nastvljeno logiko, da vem, da me "dnf upgrade" ali "apt-get update/upgrade" ne bosta prisilila, da naokoli vlečem SD kartice. Tudi, če bodo U-Boot spreminjali, ne verjamem, da bodo radikalno spremenili zagonsko sekvenco, ki je bolj ali manj nespremenjena že najmanj 3 leta (morda pa še več, ampak dlje nazaj nisem rabil gledati).

hojnikb ::

mah, za taksen spas je bolse ostat na x86-64, kot se hecat z raznimi arm socji.
#teamred
MediaBox: AMD R5 1600 AF, 16GB DDR4, 256GB SSD, 1060 6GB, B450M-DS3H, W10

AndrejO ::

Vsakomur svoje. Na koncu dneva je rezultat tega heca to, da lahko že danes vsakdo, ki si to zaželi, uporablja 64-bitno stock Fedoro in 95% raznih tutorialov na netu, ki se začnejo z "v config.txt dodaj ..."

Ker nimam RPi 4 pri roki, ne vem kakšno je stanje vanilla jedra zanj, ampak s 4 Gib RAM in spodobnih 64-bitnim CPU je pravzaprav greh gor poganjati 32-biten OS.

hojnikb ::

se vedno je samo 4gb rama (naslovis lahko vse) in razn ce lovis kaksne extensije, ki so v aarch64, tudi 32bit cisto ok spila for the time being. Je vsaj poraba rama manjsa v tem primeru
#teamred
MediaBox: AMD R5 1600 AF, 16GB DDR4, 256GB SSD, 1060 6GB, B450M-DS3H, W10

Zgodovina sprememb…

  • spremenil: hojnikb ()

AndrejO ::

Za ceno večje porabe RAM dobim nekaj meni pomembnih aplikacij, ki se izvajajo hitreje, ker imam 3x več splošnih registrov (30 na aarch64, 10 na arm) in čisto mimogrede tudi hitrejši context-switch, kar mi pride prav pri moji uporabi.

Kot sem že enkrat napisal: "vsakomur svoje." Kaj komu pomeni "OK" je odvisno od človeka, ne strojne opreme. Čar je predvsem v tem, da imamo izbiro in si lahko izbiramo tisto, kar nam bolj ustreza.

Sedaj ... če bi samo še lahko prepričal clang, da mi ne bo delal miscompile za AArch64. ;((

WhiteAngel ::

Dzhimen je izjavil:

Lep pozdrav.

Eno hitro vprašanje bi imel jaz glede Raspberry Pi 3B+, če ima kdo mogoče izkušnje iz prve roke glede "štopanja" časa na tej zadevi...

Kolega ima omenjeni model maline z Linuxom in piše program v C-ju, ki bi moral do 1 ms (milisekunde) natančno merit čas med dvema dogodkoma. Rekel je, da če nastavi te dogodke tako, da je med dvema dogodkoma cca 20ms, da zadeva deluje natančno (pravilno izmeri čas med dvema dogodkoma). Ko pa nastavi te dogodke da so na 4 ms narazen, pa stvar odpove in pridejo odstopanja do nekaj procentov, kar je za ta konkreten primer nedopustno. On pravi da je vse drugo eliminiral (žice, konektorje, procesor in RAM nista niti približno obremenjena, različne knjižnice je probal itd.) in da je prišel do zaključka da je kriv OS. Se pravi da se zaradi schedulerja klic funkcije za čas ob nekem dogodku ne izvede takoj in zato pride do napak pri merjenju časa med dvema dogodkoma. Probal je tudi z interrupti, ampak je bila napaka začuda še večja.


Moje vprašanje je samo tole: Ali je možno da Raspberry Pi 3B+ z Linux OS-om ne more beležiti časa na recimo 1ms natančno?

Vem da je možnih še veliko drugih vzrokov za tole napako, ampak me zanima ali mi kdo lahko iz prve roke z zagotovostjo pove, da ni kriv scheduler OS-a, tako da se lahko tole hipotezo eliminira ter se gre raziskovat druge vzroke?

Hvala lepa že vnaprej!


Pismo, 1 ms se mi zdi kar veliko, da je raspberry ne bi mogel pohendlati z več jedri. Ali si izklopil namizje (raspbian lite), poganjal aplikacijo pod rootom in z najvišjim nice levelom? Je mogoče kakšna težava z io schedulerjem? Lahko ga zamenjaš v živo s parametrom. Ne vem, kaj drugega bi lahko tako dolgo imelo lock in to nad vsemi jedri.

hojnikb ::

AndrejO je izjavil:

Za ceno večje porabe RAM dobim nekaj meni pomembnih aplikacij, ki se izvajajo hitreje, ker imam 3x več splošnih registrov (30 na aarch64, 10 na arm) in čisto mimogrede tudi hitrejši context-switch, kar mi pride prav pri moji uporabi.

Kot sem že enkrat napisal: "vsakomur svoje." Kaj komu pomeni "OK" je odvisno od človeka, ne strojne opreme. Čar je predvsem v tem, da imamo izbiro in si lahko izbiramo tisto, kar nam bolj ustreza.

Sedaj ... če bi samo še lahko prepričal clang, da mi ne bo delal miscompile za AArch64. ;((

absolutno, vsaj moznost izbire official aa64 distrota nebi bla slaba, ceprav vprasanje kdaj ...
#teamred
MediaBox: AMD R5 1600 AF, 16GB DDR4, 256GB SSD, 1060 6GB, B450M-DS3H, W10

AndrejO ::

hojnikb je izjavil:

AndrejO je izjavil:

Za ceno večje porabe RAM dobim nekaj meni pomembnih aplikacij, ki se izvajajo hitreje, ker imam 3x več splošnih registrov (30 na aarch64, 10 na arm) in čisto mimogrede tudi hitrejši context-switch, kar mi pride prav pri moji uporabi.

Kot sem že enkrat napisal: "vsakomur svoje." Kaj komu pomeni "OK" je odvisno od človeka, ne strojne opreme. Čar je predvsem v tem, da imamo izbiro in si lahko izbiramo tisto, kar nam bolj ustreza.

Sedaj ... če bi samo še lahko prepričal clang, da mi ne bo delal miscompile za AArch64. ;((

absolutno, vsaj moznost izbire official aa64 distrota nebi bla slaba, ceprav vprasanje kdaj ...

Upam, da nikoli. Pravilna rešitev je "vsak distro načeloma dela iz škatle".

Ja, vem ... optimist. Ampak večino osnov je že notri odkar U-Boot dovolj dobro emulira EFI. Ko je enkrat ta sloj usposobljen na kateremkoli SBC-ju, so preostanek dela samo in zgolj gonilniki in DT. DT je načeloma dovolj enostaven, da se da verzijo 0.1 pofejkat iz dokumentacije. Gonilniki pa so še vedno rak rana OSS, ker imajo fuj in fej OEM-i še vedno neke mentalne blokade.

Ampak saj bo. Morda bo tudi Broadcom trznil, ko bo na trgu vedno več SBC-jev ki bodo delali z naključnim distrom praktično out of box in, ki ne bodo imeli njihovega gor črne škatle z imenom BCMxxxx.

igorpec ::

Brezplačna Orangepi 4 z RK3399 in AI chipom.

https://twitter.com/orangepixunlong/sta...

seminal ::

A obstaja kakšen thin client za pija? Fural bi iz VM tako da če je kakšen za winse, oz ubuntu važno da dela čim bolj tekoče, in da večino "težkega" dela opravi virtualka.

jukoz ::

https://comstrok.si/namizni-racunalniki...

Ceneje in hitreje. Poglej še na ebay za thincliente. Zastonj so.

seminal ::

Ceneje ni ne če morem kupit, pi pa počiva v predalu. Rabo bi za delavnico za parkrat na leto kaki datasheet pa te zadeve pobrskat na netu. nič drugega.

sas084 ::

seminal je izjavil:

A obstaja kakšen thin client za pija? Fural bi iz VM tako da če je kakšen za winse, oz ubuntu važno da dela čim bolj tekoče, in da večino "težkega" dela opravi virtualka.

Poglej si rpitc. Drugače pa RPI4 z virt-viewer (SPICE protokol) dela solidno.

AgiZ ::

WTware je dober thin client, ki dela dobro na RPiju. Ni pa (več) zastonj (od neke verzije naprej je plačljiv).
Tudi sam iščem nekaj free, ki ima še aktiven razvija in je tekoče, pa ne najdem. Čudi me da tega ni več.

seminal ::

Tole vidim da je za winse vse. Je kaj za linux oz ubunto podobnega pa da je free?
««
20 / 23
»»


Vredno ogleda ...

TemaSporočilaOglediZadnje sporočilo
TemaSporočilaOglediZadnje sporočilo
»

Orange PI (strani: 1 2 3 4 5 6 )

Oddelek: Strojna oprema
28636096 (691) igor53
»

Raspberry Pi (strani: 1 2 3 482 83 84 85 )

Oddelek: Strojna oprema
4229578008 (7152) AvtoR
»

Najcenejša varianta zmogljivega "seedboxa"? (strani: 1 2 )

Oddelek: Strojna oprema
535906 (4409) billy
»

Raspberry Pi 2 - malina na steroidih z Okni (strani: 1 2 )

Oddelek: Novice / Znanost in tehnologija
8519576 (10175) rebro
»

Smart tv ali raspberry pi, android micro pc ali smart dongle ali...

Oddelek: Kaj kupiti
383162 (2288) Invictus

Več podobnih tem