Vlákno názorů k článku
ChromeOS opouští čisté linuxové jádro
od dustin - Divím se, že přechod ChromeOS na androidí framework...
-
Divím se, že přechod ChromeOS na androidí framework už neudělali dříve. Nedává mi smysl pro jednu firmu udržovat dva oddělené stacky. S rozvojem AI budou mít spoustu práce v androidu a je pro ně neefektivní duplikovat totéž do neandroidího stacku. Samozřejmě s tím souvisí přechod i jádra na androidí verzi, ale to bych viděl jako důsledek přechodu na user-space android.
Navíc tím automaticky získají lepší podporu od výrobců ARM SoCů, kteří všichni nejdříve dělají podporu do androidího kernelu a až pak se pár z nich pokouší submitnout patche do mainline. Snaha nebývá extra veliká, protože většina odběratelů jejich SoCů potřebuje hlavně androidí kernel.
-
Ale musím dodať, že rôzny boilerplate kód to robí dobre, prípadne vie to vyriešiť nejaké štandardné problémy. Na prvú dobrú to nedá, treba trochu pobuzerovať, prípadne manuálne doupraviť. Nebyť právnych problémov s týmito generatívnymi AI, tak je to dobrý pomocník.
Dobré skúsenosti mám s GPT-4. GPT-3.5 je hlúpy a GPT-4o robí bonusové úpravy v kóde, programuje ako junior.Čo by som s tým ale nerobil určite, je systémové programovanie a písanie modulov do kernelu, to je na GPT trošku low level, mno :)
-
Na boiler-plate sú snippety, knižnice a frameworky.
Primitívne funkcie napíšem s intellisense rýchlejšie než prompt do ChatGPT s 10 úpravami (ako hovoríš na prvý pokus to zvyčajne nedá) kým to vypluje čo chcem aj to v hroznej kvalite so skrytými bugmi.
LLMká sú na programovanie nepoužiteľné.14. 6. 2024, 23:10 editováno autorem komentáře
-
Heh, zrovna vcera, mam postgres tabulku s 34 sloupci, potrebuju pro ni udelat Hibenate entity bean. Tedy bean s atributy stejného nazvu a typu jako sloupce. Manualne otrocina na pul hodiny nachylna na chyby. GPT, vyjelo z fleku podle create table vypisu.
Dale, prototyp kafka klienta ve Spring Boot, GPT vystup MNOHEM lepsi nez oficialni "Getting started", vcetne vysvetleni, proc danou konfiguraci pouziva.
Dneska nepouziva GPT jenom hlupak.
-
Heh, zrovna vcera, mam postgres tabulku s 34 sloupci, potrebuju pro ni udelat Hibenate entity bean. Tedy bean s atributy stejného nazvu a typu jako sloupce. Manualne otrocina na pul hodiny nachylna na chyby. GPT, vyjelo z fleku podle create table vypisu.
Jenže zrovna na tohle existuje už asi 13.7 mld let řešení v podobě systému, který z jednoho předpisu vygeneruje DB schéma, classy nebo structury apod. pro různé prog. jazyky a dokonce i dokumentaci.
Nebo poněkud horší varianta, i když stále lepší než dnešní AI, že se nějaký framework podívá do DB, zjistí "sloupečky", a podle toho automaticky vygeneruje příslušné API.
Tohle se od počátku IT píše prostě jenom jednou.
-
Nicméně reakce vzešla z názoru, že Google bude mít spoustu práce s integrací AI funkcí do androidu. Implementace konkrétních požadavků vyžaduje detailní znalost příslušných struktur androidu, jeho programátorských best practices, zapracování do posledního detailu. Tedy žádný prototyp na zelené louce, který může vycházet z nějakých načtených tutoriálů.
-
stejně jako se programuje rychleji, díky použití již hotových knihoven a nástrojů. Když jsme v 90. letech potřebovali replikovat databázi, stálo to rok vývoje a dnes to je věcí konfigurace u většiny databází.
Množství zakázek na SW vývoj ale roste rychleji než probíhá úspora času vývojářů, SW je už všude kam se podíváš. AI je zase jen nástrojem, příliš se neliší od těch ostatních, to jen v marketing má výraznější.
Reálná úspora času vývojářů (že bych jim třeba mohl zkrátit pracovní týden o den, protože nemají práci) není, naopak tlak se zvyšuje, protože těch poptávek/zakázek je enormní množství.
