- A hozzászóláshoz be kell jelentkezni
Hozzászólások
Upton went on to say, "I expect this will be fixed in a future board revision, but for now users will need to apply one of the suggested workarounds. It's surprising this didn't show up in our (quite extensive) field testing program."
in a future board revision
Hat mit kepzel ez? Tehat nem a __next__, hanem az akarhanyadik, ha jol ertelmezem a mondatot.
- A hozzászóláshoz be kell jelentkezni
Hát lehet elromlott az irónia detektorom, de azt gondolja hogy mint egy rendes nem garázs cég már egy picit előrébb járnak a tervezéssel, kapacitás lefoglalással a gyártósoron és esetleg nem az elsőbe fog beleférni hogy ezt a hibát javítsák. Mivel egyébiránt megy jól pl. hat tőle veszel tápot.
Én pl emlékszem hogy egy régebbi esetnél az volt a mondás, nincs hiba "rosszul tartod".
Hát ez sokkal korrektebb megoldás.
- A hozzászóláshoz be kell jelentkezni
Vegre otthon kikopott minden "regi" telo, es most mar type-c minden tolto.
Akkor itt ez a __nagyon__ kell nekem pi, es azzal szivjak majd, hogy csak a sajat szaros tapjaval fogom tudni hasznalni, mert amugy meg minden szegletben a hazban van egy toltom, csak baszhatom, mert.
- A hozzászóláshoz be kell jelentkezni
Nyilván kellemetlen, de rPi-t milyen sűrűn mozgatod? Nálam teljesen jól megvan egy helyen, szerintem amióta megvan hozzá se nyúltam max ssh-val, szvsz simán belefér hogy legyen egy "fix" kábele.
- A hozzászóláshoz be kell jelentkezni
Nalam a pi a git server, tehat minden nap munka utan jon velem haza, reggel meg jon velem a melohelyre; egyszemelyes fejleszto vagyok, es nalam a GitHub-ot valtja ki a pi.
- A hozzászóláshoz be kell jelentkezni
Ezt most fel kell tennem: de miééért?
- A hozzászóláshoz be kell jelentkezni
Mert ezt talaltam ki, es egesz jol mukodik.
Ha pl. a GitHub-ot hasznalnam verziozasra, akkor ott lenne a forgalom a GitHub es a ket (munkahelyi es az otthoni) gep kozott. Igy meg csak egy bridge van a git server es valamelyik gep kozt, es nincs havi kvotazas.
Nekem nagyon bejon, hogy ott van a fejlesztoi gep mellett a git server, es berakom a taskaba, ha megyek haza.
Amig nem giteltem, addig hazamenetel elott mindig bezippeltem a "working directoryt", aztan masotam pendrajvra. Amiota viszont gitelek, azota ez a masogatas teljesen eltunt az eletembol, es igy kenyelmesebb minden; a push-sal lemegy a masolas is, nekem csak le kell huznom az rpi-t a madzagokrol, es mehet a taskaba.
Azt nem tudom –mert nem igazan gondolkodtam rajta–, hogy mi lenne, ha nem egyedul lennek fejleszto a cegnel, de igy nagyon kenyelmesnek talalom. Persze kenyelmesebb lenne a GitHub onmagaban, ha nagyon gyors internet eleresem lenne mindket helyen, es nem lenne forgalmi kvota.
- A hozzászóláshoz be kell jelentkezni
Azért kérdeztem erre rá, mert én pl. nem aludnék nyugodtan, ha magammal hordozgatnám a git repoimat: ha bármikor lenyúlhatják a kis dobozt, az szerintem nagyon nagy kockázat. Nekem nagy biztonságérzetet ad az, hogy legfeljebb annyi munkám veszhet el, amennyit még nem küldtem fel a GitLab-ra. Nem beszélve azokról a balesetekről, amik még érhetik, ha ott van mellettem: véletlenül leöntöm, megsül a memóriakártya, stb.
Milyen kvótára gondolsz? Nem mértem, de **szerintem** nem forgalmazhat túl sok adatot egy git, ha jól csináljuk: mivel a repóba jó esetben nem kerül be semmilyen nagyméretű "blob", ezért "csak" szövegfájlokat kell felküldeni a kapcsolaton keresztül. Plusz a felküldött cucc is csak delta, ráadásul tömörítve, ha jól értem.
- A hozzászóláshoz be kell jelentkezni
Ha elhagyom/ellopjak, akkor is ott van azon a gepen az aktualis allpot, ahonnan eljottem; nem tartom nagy kockazatnak, ha viszi valaki a forrast, mert nem fog vele semmire sem menni. Ha kozben meg megadja magat a gep, ahonnan eljottem, akkor max 1 napi munka esik ki, de ilyen azert ritkan fog elofordulni. Ha a kave belemegy stb. akkor lecserelem egy ujra, de nem tartom kozvetlen mellettem, a memoriakartya ha elszall, erre nagyobb az esely, akkor az szivas lehet, de erre majd kitalalok valamit: mondjuk leszinkronizalom a kartyan levo adatokat valahova.
A kovta alatt meg azt ertem, hogy ha ott van a GitHub, de szerintem a GitLabnal is hasonlo a helyzet, akkor van egy havi kvota a forgalomra, amit ha tullepsz, akkor nem fogsz tudni adatot fel/le tolteni, vagy fizetni kell erte pluszban.
De ha a kvota nem is lenne, akkor is kenyelmes a zsebszerver, mert neha jol esik egy clone-t csinalni, es ilyenkor 1 giga adat is kozlekedhet (nalam minden anyag ott van a working tree-ben, ami a projekthez tartozik, nyilvan az .gitignore-ban fel vannak veve azok a reszek, amelyek nem track-keltek, pl. a juzertol lementett adatbazis nincs a git felugyelete alatt, de ott van tobb peldanyban a workingben, mert hova kellene mashova tennem (persze lehet linkekkel is mutagatni mashova, de elegem lett abbol, hogy egy projekthez tartozo dolgok itt-ott vannak elszorva. Miota attertem a gitre, ez az egyik legjobb dolog, hogy mindent egy directory ala tudok becsoditeni, es a verziozas (mentés) meg egy masik dolog.
- A hozzászóláshoz be kell jelentkezni
> mondjuk leszinkronizalom a kartyan levo adatokat valahova.
Mondjuk egy tavoli git repoba?;
---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
- A hozzászóláshoz be kell jelentkezni
Pontosan, de az csak egy biztonsagi mentes lesz.
A lenyeg nalam az, hogy mellettem van a a "remote", es mindent ugy csinalok, mint ha tavol lenne.
- A hozzászóláshoz be kell jelentkezni
"A kovta alatt meg azt ertem, hogy ha ott van a GitHub, de szerintem a GitLabnal is hasonlo a helyzet, akkor van egy havi kvota a forgalomra, amit ha tullepsz, akkor nem fogsz tudni adatot fel/le tolteni, vagy fizetni kell erte pluszban."
Tudtommal ilyen nincs, és eddig soha nem ütköztemn limitbe, de ha tudsz linket adni, azt megköszönöm.
Clone-csinálás: sima cp miért nem jó a már ott lévő anyaghoz?
Asset kezelés: lehetnek például egy bucketben valahol a felhőben.
- A hozzászóláshoz be kell jelentkezni
Én egy limitbe futottam bele eddig GitHub-on: talán két éve nem tudtam 100+k ref-et egy 'git push'-sal feltölteni, de egy egyszerű for ciklussal 10k ref-enként gond nélkül felment mind. Hogy ez a korlátozás valahol dokumentálva van-e a halandó userek számára, vagy hogy még mindig így van-e, azt nem tudom.
Ami a forgalmi kvótát illeti: sorban egymás után tudtam clone-ozni a linux, gecko-dev, gcc, webkit, chromium repókat, ami összesen kb 30GB, szóval ha van is forgalmi kvóta, az sok-sok nagyságrenddel többnek tűnik, mint a napi backup-okhoz szükséges adatforgalom.
- A hozzászóláshoz be kell jelentkezni
De minek kell ehhez a rpi? Csak felesleges bonyolításnak tűnik, hiszen 'git push'-olni ugyanúgy lehet egy pendrive-on lévő repo-ba is... és talán még gyorsabb is lesz.
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
+1
Én az ilyen nagyon érzékeny dolgot úgy oldottam meg, hogy:
- vagy egy 4-8-16 GB-os virtuális gépen futott a GitLab, ahol volt LUKS / TrueCrypt / VeraCrypt, és ezt hordoztam vagy mentettem
- vagy csak a Git repo / Git Data könyvtárat (ahol az összes repo van) tartottam titkosított konténerben (lásd előző sor), a VM egy külön image-ben volt, és boot-kor mountolta fel ezta másikat, amiben csak adat volt. Így a VM-ben nem volt érzékeny adat, csak a másik konténerben
És ezeket az image-okat általában USB3 / 3.1-es keretben, SSD-n tartottam vagy nagyon gyors pendrive-on, továbbá mindig volt +2 fizikai helyen valamilyen mentés: szinkronizáltam valahova a titkosított image file-okat. Mondjuk soha nem volt így adatvesztésem.
Sakk-matt,
KaTT :)
- A hozzászóláshoz be kell jelentkezni
mi az paksi iranyito sw-t fejlesztesz? =-O
- A hozzászóláshoz be kell jelentkezni
Nem, inkább személyes kihívás, hogy meg lehet-e oldani, csak tesztből használtam ilyet, ez nélkül egyszerűbb... :) Bízom benne, hogy az ottani szoftvert nem PHP-ban fejlesztik... :-)
Sakk-matt,
KaTT :)
- A hozzászóláshoz be kell jelentkezni
vagy úgy.
a kihívás az kihívás :)
- A hozzászóláshoz be kell jelentkezni
Uppsz!!!
Mindig tanulok valami ujat. :)
Nem tudom miert bonyolitottam tul. Talan azert, mert nem regota gitezek, es nem jutott eszembe, hogy beirjam a git:// helyere a file:// -t.
Akkor az rpi-rol leveszem ezt a "terhet", mert a pendrajvval nem versenykepes (meretben sem es egyszerusegben sem...).
Koszi a felvilagositast!
- A hozzászóláshoz be kell jelentkezni
Sőt:
dual-bootnál egyes repo-k duplan megvannak, (hogy az IDE ne kavarodjon meg) es siman athuzhatod az utolso valtoztatasokat a masik particion levo repository-ból :)
- A hozzászóláshoz be kell jelentkezni
mellete meg mindig berelhetsz par $-ert egy vps-t, azon hosted gitlab (vagy barmilyen git kezelo, akar a pure gitcore), aztan syncelheted fel a repot. aztan meg a pendriveot se kell vinned (engem mondjuk a notibol kiallo cuccok szoktak zavarni)
--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
ezen a ponton mar megbizol egy kulso szolgaltatoban es a halozatban is.
akkor miert nem github,gitlab,bitbucket whatever?
- A hozzászóláshoz be kell jelentkezni
ohMY.
docker fut rajta nekem is, de semmi olyan amit ha elpukkana nem sajnálnék :)
- A hozzászóláshoz be kell jelentkezni
Tudom, nem mentség, de nem azt mondták, hogy csak a sajátjával megy, hanem azt, hogy nem mindennel megy.
Úgy olvastam, hogy telefonokhoz való töltőkkel általában megy, laptophoz való töltővel meg nem.
Szóval még akár az is lehet, hogy a ház minden szegletében tudnád használni.
- A hozzászóláshoz be kell jelentkezni
A régi pi-k sem feltétlen mentek okos töltőkkel, mert azokon nem volt ellenállással megadva, hogy értse a töltő, adhat több ampert.
Az új pi-nél megint csak butatöltővel megy, valsz most is csak azért nem rázták le a panaszkodókat, mert a type-c elvileg előírja, hogy milyennek kell lennie az ellenállásoknak.
A régi táp + pár centes type-c adapter is valsz jól fog menni. Laptol töltővel és más, spéci okoskábellel nem megy.
- A hozzászóláshoz be kell jelentkezni
Ilyenek miatt is érdemes várni egy új verzióval. Sok pHAT és board nem megy RPI 4 esetén, csak a 3B+ -ig kompatibilis.
Sok eszköznél láttam a webshop-okban, hogy: "NOT FOR RPI 4!".
Sakk-matt,
KaTT :)
- A hozzászóláshoz be kell jelentkezni
Talán nem kellett volna annyira sietni a Pi4 kiadásával.
- A hozzászóláshoz be kell jelentkezni
Szerintem normális az, hogy egy adott eszközhöz tervezett hardver nem működik egy másik eszközön, ami eltérő felépítésű.
Majd lesznek olyan kiegészítők, amik az újhoz jók.
Biztos vannak és lesznek olyanok is, amik nem használnak hardver specifikus dolgokat, és most is működnek meg a jövőben is valószínű működnek.
- A hozzászóláshoz be kell jelentkezni
Ezzel csak az a gáz, hogy a málna projekt nem erről szól. Én is elhamarkodottnak érzem a kiadást, mind szoftver, mind hardver oldalról. Ha belegondolsz, a gpio ugyanaz már generációk óta, nem véletlenül. Ráadásul pont az usb-c-nél jön elő, ami elég rendesen le van dokumentálva hogyan is kellene az éhesebb fogyasztókat ellátnia szuflával.
- A hozzászóláshoz be kell jelentkezni
Az USB-C szerintem is elkúrás.
Inkább a kiegészítő boardokra gondoltam. Az egy dolog, hogy az interfész ugyanaz, de más hardver elemek jönnek utána. Biztos vagyok benne, hogy egy olyan eszköz, ami a GPIO-t adatok küldésére, mérésre, led villogtatásra, motor forgatásra használta, az továbbra is megy.
De mondjuk egy olyan board, ami bővítőkártyaként szolált és plusz ethernet csatlakozókat, vagy videokártyát, hangkártyát, ezt-azt adott a rendszerbe, az simán lehet, hogy nem csak a tüskék méretétől és helyétől függ, hanem valami olyasmitől, ami megváltozott. Pl. eddig USB volt, most meg direktbe kapcsolódik.
Persze nem tudom, hogy konkrétan melyik eszközök törtek el. Ha a villogó karácsonyfa ledek, az gáz. Ha egy lebegőpontos számoláshoz segédprocesszort tartalmazó board, az szerintem belefér.
- A hozzászóláshoz be kell jelentkezni
Azért siettek szerintem, mert a konkurens gyártok még a most kiadott RPI 4-nél is erősebb hardvert árulnak már jó régóta, 2-3-4-8 GB memóriával, stb.
Ha nem adják ki, elbukják a részesedésüket a jövőben még jobban.
Szerintem a legfontosabb nagy lépés az lenne, ha raknának elsőre 2 darab SATA3 csatlakozót, amely a leggyorsabb módon csatlakozik a CPU-hoz, és nem USB-n keresztül, stb.
Onnantól lehetne RAID1-et szoftveresen csinálni.
Sakk-matt,
KaTT :)
- A hozzászóláshoz be kell jelentkezni
És akinek nem kell SATA csatlakozó?
-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…
- A hozzászóláshoz be kell jelentkezni
Akinek nem kell SATA, annak lenne SATA nélküli változat is. Vagy a SATA lenne az extra változat teljesen misztikus kódnévvel: RPI 5 SATA
Sakk-matt,
KaTT :)
- A hozzászóláshoz be kell jelentkezni
usb3 mellett már nem szűkös a háttértár kezelés sem. UASP kompatibilis usb3-as házban már sata ssd-t is kihajt elég jó sebességgel.
Pcie 2.0 1x csatolón van az usb3 chip. CM modulon nem szoktak ilyen dolgok rajta lenni, hanem minden gyártó a maga igénye szerint azt köt rá, amit akar. Például egy sata vezérlőt.
Amúgy van egy olyan előérzetem, hogy ha kiadnak CM4 modult, esetleg az alapítványosok eleve kiadhatnak olyan io dev boardot, amin van pcie 1x slot. Sokan megvennék valsz sima haszálatra is, nem csak ipari területre. Még a vastagabb árazásukkal is.
De például az is érdekes kérdés, hogy lesz -e 4A model. Mert az A-kon nem szokott lenni extra lan és usb. A pi4 soc pedig továbbra is tartalmazza a saját usb2 portját - a 4b esetén a type-c re van kivezetve egyébként közvetlenül - usb gadget módot tud. Szóval akár az A is lehetne olyan, hogy egy tüskesor helyet hagynak pcie -nek, mégha slotot nem is kap. Most is vannak olyan boardok, ahol pcie tüskesoron van és fizikai adapter kell hozzá.
A lényeg, hogy a mostani soc-ban marha sok potenciál van. Sokféle kiegészítőt vagy spéci "ipari" megoldást el tudhatnak adni a jelenleg 4B-vel nem kiaknázható lehetőséggel. Ha felcsapunk rá egy pcie multiplexert és kompatibilis vele, akkor akár több slotos megoldás is lehet - persze osztorva az 1 lane 500-as tempóján.
Valami elvetemült már leforrasztotta az usb3 chipet és kikötötte a pi4-ről a pcie portot és egy adapterrel rákötött külső SAS kontrollert :D
https://blog.hackster.io/pci-express-on-the-raspberry-pi-4-9b03c59f7a04
http://mloduchowski.com/en/blog/raspberry-pi-4-b-pci-express/
- A hozzászóláshoz be kell jelentkezni
Ez nagyon joo! Mondjuk kell hozza tudni forrasztani, de az pont nem akadaly (nalam). Koszi a linket!
- A hozzászóláshoz be kell jelentkezni
Én eddig azt láttam, hogy mindig is voltak erősebb hw-t felvonultató gyártók a kategóriában, de
vagy kiforratlan volt a Linuxos támogatás
vagy kiegészítők terén nem vehette fel a versenyt a Pivel
vagy hozott ugyan extra ramot, cput és plusz hardverelemeket hozott a Pivel szemben de irreálisan drágábban.
Illetve ezek kombinációi.
Hasonló sikert eddig szerintem csak az Arduinok tudnak felmutatni, de az már kicsit más kategória.
A nyár egyébként is uborkaszezon szerintem. Mert ha mindez karácsony előtt történik még csak megértem a sietséget, de most nem nagyon.
- A hozzászóláshoz be kell jelentkezni
A vicc, hogy kb. egy hónapja olvastam, hogy mikor lesz Pi4? Akkor azt ígérték, hogy jövő nyár előtt nem...
A type-C-hez meg annyit, hogy épp ebben a cikkben írták, hogy nem annyira szeretnék, és max. a tápnál lesz használva, ott is azért, mert a 2.5 A kevés lesz, amit a micro még tud. És épp ezért lett type-C.
- A hozzászóláshoz be kell jelentkezni
Tudsz konkrét példát mutatni, amelyik pHat nem megy?
Meglepő lenne, mert teljesen azonos a kiosztásuk.
A pi ráadásul továbbra is videocore alapú, csak az újabb fejlesztésekből pár modult belepakoltak.
Az peresze látszik, hogy szoftveresen még nincs minden rendben. Máskor, ha az új képességek nem is feltétlen voltak még kiforrottak, de a régiek implementálva voltak. Most kissé trógerebbül sikerült. Lehet azért, mert picit szorongatták már őket - bár szerintem, ha kiteszik a 2018as pénzügyi jelentést, megint le fog esni az állunk. De simán lehet, hogy azért bátorkodtak erre, mert frissíthető flash-re került a boot rom - főleg abból vannak hiányosságok még.
- A hozzászóláshoz be kell jelentkezni
Ha jól emlékszem CAN busz adaptereknél, és audiophile HAT moduloknál láttam, hogy pirossal ki volt írva, hogy RPI4-hez nem való (az elmúlt 1-2 hétben sok helyen láttam, ha tudom, kigyűjtöm neked). Az is lehet, hogy bizonyos javítások után jó lesz, ahogy volt a 3B+ esetén is gond, hogy le kell butítani az Ethernetet max 100 mbites kapcsolatra, különben recseg a zene, mert ott USB-n van rákötve az Ethernet és bezavar, ha a zenét UTP-n olvasod és gigabit van + hangkártya.
Sakk-matt,
KaTT :)
- A hozzászóláshoz be kell jelentkezni
Jöhet a javított verzió.
--
robyboy
- A hozzászóláshoz be kell jelentkezni
Jól megszívta aki ilyet rendelt és pont olyan kábele van amivel nem kompatibilis az eszköz.
Szegény most vehet másik kábelt 1000-1500 Ft-ért. :)
Bakinak baki, de nem olyan vészes.
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox
- A hozzászóláshoz be kell jelentkezni
Azt mondjuk totál nem értem, ha ott van a szabvány, ami definiálja, hogy milyen körülmények között működnek az USB Type-C eszközök, kapcsolatok, akkor miért kell okosabbnak lenni és megmutatni, hogy de nem, az hülyeség. Aztán rádöbbenni, hogy nem hülyeség, okkal van kitalálva. Komolyan csapnám tarkón azt a fejlesztőt, aki eltér a szabványtól.
Ave, Saabi.
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
+1
"Komolyan csapnám tarkón azt a fejlesztőt, aki eltér a szabványtól"
Meg azokat a kretén barmokat akik bár már létezik szabvány, akkora királynak hiszik magukat hogy a kis(nagy) szemétdombjukon sajátot hoznak létre, persze szarul és nem létezik két olyan eszköz ami a sajátszart pont ugyanolyan elbaltázva implementálná.
az összes ilyen gyökérne pé{&/szív}lapát..
#telenyom
- A hozzászóláshoz be kell jelentkezni