Elektroda.pl
Elektroda.pl
X
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

Metodologia projektowania sprzętu jest błędna, co szkodzi branży

ghost666 06 Jun 2023 07:06 1689 23
  • Metodologia projektowania sprzętu jest błędna, co szkodzi branży
    Był czas — nie tak dawno temu — kiedy projektowanie urządzeń było szczytem technologicznego świata. Podczas gdy startupy sprzętowe były na rynku liczne i chętnie lokowano w nie środki, by mogły rozpocząć, tak teraz fundusze inwestycyjne nie chcą ponosić podwyższonego ryzyka i przenoszą uwagę gdzie indziej. Branża oprogramowania cieszy się obecnie znacznie większym zainteresowaniem, dokładnie takim, jakie kiedyś istniało wokół sprzętu — i słusznie. W porównaniu ze startupami software'owymi, te sprzętowe stały się znacznie droższe, bardziej czasochłonne i ryzykowne w budowie. Oprogramowanie nie jest z natury ani łatwe, ani tanie w tworzeniu. Mimo to branża ta doświadczyła ogromnego wzrostu w ciągu ostatnich 20 lat. Duża część tego skoku wynika z pojawienia się sporej ilości nowoczesnych narzędzi, które zostały opracowane w celu wspierania programistów w miarę rozwoju dziedziny. Kiedy jednak spojrzysz na sektor inżynierii elektronicznej, zauważysz, że instrumenty są przestarzałe, a także to, że ich brakuje. Gdzie są więc te nowoczesne i wydajne narzędzia dla przestrzeni sprzętowej?

    Firma Flux jest zdeterminowana, aby naprawić ten zepsuty paradygmat tworzenia urządzeń, jako że branża ta jest aktualnie nękana wieloma rażącymi problemami.

    Pierwszym z nich jest znaczna ilość czasu potrzebna do rozpoczęcia projektowania. Każdy inżynier, który zaczynał koncept od zera, może potwierdzić, że najbardziej frustrującą i czasochłonną częścią jest okres startu. W przypadku nowego zamysłu sprzętowego obejmuje to okres poświęcony na tworzenie modeli, footprintów i symboli, zasad projektowych i całą szeroką gamę innych zadań związanych z konfigurowaniem całości. Zamiast spędzać czas na opracowywaniu i wprowadzaniu produktu na rynek, inżynierowie są zmuszeni zajmować się drobiazgami. Porównując to z branżą oprogramowania, gdzie wszystko, czego potrzeba, aby zacząć to fork w repozytorium i wykorzystanie wykonanej już dotychczas pracy, co powoduje istotne skrócenie procesu.

    Innym poważnym wyzwaniem jest trudność w efektywnej współpracy przy projektach sprzętowych. W przeszłości oprogramowanie do tworzenia urządzeń elektronicznych uruchamiane było tylko lokalnie, co oznacza, że za każdym razem, gdy wprowadzane są zmiany w koncepcie, nie są one udostępniane kompletnemu zespołowi. Zamiast tego, w celu przeglądu całości, grupy te mają tendencję do przekazywania aktualizacji tylko za pośrednictwem oprogramowania do kontroli wersji (często dedykowanego, a nie ogólnie dostępnego) lub wręcz plików ZIP przesyłanych pocztą elektroniczną. Jest to szczególnie uciążliwe, gdy dąży się do współpracy interdyscyplinarnej, w której projekty elektroniczne są udostępniane zespołom mechanicznym i innym osobom niedysponującym znajomością lub akcesem do standardowych narzędzi EDA. Stosowane obecnie podejście stanowi istotną przeszkodę w całym procesie, czyniąc go asynchronicznym, powolnym i uciążliwym. W rezultacie projektowanie sprzętu stało się znacznie trudniejsze niż powinno. Jako że jest wyhamowywane przez niepotrzebne przeszkody związane z kooperacją i terminem powoływania nowych konceptów. Skutkuje to dłuższym czasem wprowadzania na rynek, wyższymi kosztami rozwoju i ostatecznie większym ryzykiem skorelowanym z uruchomieniem sprzętu.

    Podejście do poprawki

    „Nowoczesne projekty wymagają nowatorskich narzędzi, aby popchnąć branżę do przodu i właśnie to staramy się osiągnąć za pomocą Flux” — piszą twórcy tego oprogramowania EDA. „Zmieniamy instrumenty EDA z czegoś, co jest używane lokalnie, w coś, co jest hostowane w chmurze. [...] Uważamy, że koncepty nigdy nie powinny zaczynać się od zera, więc nasi użytkownicy mogą wykorzystać podejście oparte na społeczności internetowej, gdzie inżynierowie udostępniają projekty, układy ścieżek, biblioteki elementów etc. Wszystko jest hostowane w chmurze. To oznacza, że każdy inżynier, który opracuje coś za pomocą Flux, ma natychmiastowy dostęp do bibliotek komponentów oraz projektów obwodów do ponownego użytku”. Podobnie jak w kwestii tworzenia oprogramowania, użytkownicy mogą od razu przystąpić do działania, pobierając części od społeczności. W rezultacie rozpoczęcie projektowania płytek drukowanych jest łatwiejsze i szybsze niż w przypadku istniejących narzędzi EDA.

    Twórcy Flux dążą również do umożliwienia lepszej kooperacji między inżynierami. Oparte na przeglądarce narzędzie do przygotowywania PCB pozwala na współpracę w taki sam sposób, jak wykorzystuje się Dokumenty Google itp. Gdzie inżynierowie mogą wykonywać szereg operacji względem jednakiego, aktywnego pliku w danym czasie. Przyspiesza to proces tworzenia, umożliwiając bardziej usprawnione i intuicyjne udostępnianie projektów i recenzje. Dzięki czemu zespoły mogą dodawać komentarze i opinie bezpośrednio w dokumencie. Aby pójść jeszcze dalej, przyszykowano dodatkowe narzędzia, takie jak Flux Copilot, asystent projektowania sprzętu oparty na sztucznej inteligencji. Ten jest zintegrowany bezpośrednio z instrumentem do opracowywania PCB. Flux Copilot to wytrenowany, duży model językowy (LLM, tak samo jak ChatGPT), który rozumie wprowadzane schematy oraz listy materiałowe. A więc może pomóc w wyborze części, dobraniu alternatyw, przekazaniu informacji zwrotnych na temat projektu, a nawet analizie kosztów. To tak, jakby mieć przyjaznego i kompetentnego współpracownika bezpośrednio zintegrowanego w narzędziu do projektowania.

    Odzyskanie przemysłu

    Aby sprzęt ponownie osiadł na swoim zasłużonym miejscu, trzeba na nowo wyobrazić sobie sposób, w jaki podchodzi się do jego tworzenia. Istniejące instrumenty do projektowania są przestarzałe i powodują niepotrzebne utrudnienia w procesie inżynieryjnym. Skutkuje to wolniejszym, bardziej kosztownym aranżowaniem urządzeń elektronicznych. Zdaniem twórców Fluxa, ich narzędzie i podejście sprawią, że projektowanie elektroniki znów stanie się intuicyjne i szybkie. Podsumowują to sami, mówiąc, że ich cel to: „z powrotem tchnąć życie w branżę sprzętową”.

    Źródło: https://www.eetimes.com/hardware-design-is-broken-and-its-hurting-the-industry/

    Cool? Ranking DIY
    About Author
    ghost666
    Translator, editor
    Offline 
    Fizyk z wykształcenia. Po zrobieniu doktoratu i dwóch latach pracy na uczelni, przeszedł do sektora prywatnego, gdzie zajmuje się projektowaniem urządzeń elektronicznych i programowaniem. Od 2003 roku na forum Elektroda.pl, od 2008 roku członek zespołu redakcyjnego.
    ghost666 wrote 11809 posts with rating 9944, helped 157 times. Live in city Warszawa. Been with us since 2003 year.
  • #2
    CosteC
    Level 38  
    Wow!
    Kolejny artykuł dowodzący inwalidztwa językowego u autora. Pytanie czy autor nie umie pisać po polsku czy jest kłamcą a artykuł napisał tłumacz automatyczny? Pozwolę sobie zacytować tylko jeden kwiatuszek:
    ghost666 wrote:
    W przypadku nowego zamysłu sprzętowego obejmuje to period poświęcony na tworzenie modeli, footprintów i symboli,

    Piękna reklama, szkoda, że dowodzi braku zrozumienia czym jest projektowanie sprzętu. Pomysł kopiowania metod z branży IT gdzie ponad 95% projektów w IT się nie udaje - jest po terminie i poza budżetem, również wydaje się nierozsądny. Czy to właśnie kopiowanie chorych metod z branży IT nie pogrąży projektowania sprzętu?

    Firma Flux chce sprzedać jako nowość coś co występuje chociażby w popularnym w Polsce pakiecie Altium Designer.
    ghost666 wrote:
    projektowanie elektroniki znów stanie się intuicyjne i szybkie.
    "Projektanci nienawidzą Flux! bo odkrył ich sekret: nie musisz nic umieć i wiedzieć, po prostu kup ich kolorowy soft!"
    Dobre projektowanie nigdy nie było intuicyjne i szybkie...
  • #3
    khoam
    Level 42  
    Ten artykuł został popełniony przez współzałożyciela Flux i wyraźnie oznaczony w EE jako "opinia" chociaż bardziej odpowiedni termin byłby "sponsorowany".
    @gulson proponuję, aby takie reklamówki nie były "tłumaczone" z innych portali chyba, że na tym forum też artykuł jest "sponsorowany".
  • #4
    CosteC
    Level 38  
    khoam wrote:
    @gulson proponuję, aby takie reklamówki nie były "tłumaczone" z innych portali chyba, że na tym forum też artykuł jest "sponsorowany".

    "Sponsorowany"
    "Zeszmacona polszczyzna"
    "Czytanie u osób o IQ powyżej 100 może powodować nudności i wymioty"

    Jaki sens ma przeklejanie artykułu z innego portalu przetłumaczonego automatycznie? Każdy może sam sobie przetłumaczyć swoim ulubionym narzędziem. Nie nazywajmy tylko tego "tłumaczeniem" ani "artykułem".

    P.S. Polecam VREF podłączone do GND. Od razu chcę kupić to kolorowe rozwiązanie "wszystkich problemów projektowania", od razu na APPLE i z zintegrowanym TikTokiem :D
  • #6
    CosteC
    Level 38  
    acctr wrote:
    Masz jakieś źródło tych rewelacji? Czy wyssałeś to z palca?

    Nie mam tego akurat, z pamięci 95% jest poza budżetem LUB za późno. Oczywiście zależy jak liczysz i kogo pytasz. Np czy bierzesz pierwotne szacunki kosztu/czasu, czy już z kontraktu z poprawkami. Czy liczysz tylko duże projekty, czy mniejsze też. Ani zleceniodawcy ani zleceniobiorcy nie chcą też o tym mówić :)
    Na szybko:
    https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/achieving-success-in-large-complex-software-projects
    66% przekroczony budżet, 33 przekroczony czas, 17% prawie zabiło wykonawcę.
    Tutaj https://www.zdnet.com/article/only-39-percent-of-it-projects-successful-thats-a-good-start/
    "Tylko" 61%
    https://www.theserverside.com/opinion/Dont-contribute-to-the-high-IT-project-failure-rate#:~:text=IT%20project%20failure%20isn%27t%20completely%20pervasive%2C%20but%20it,better%20outcome%3A%2064%25%20of%20projects%20meet%20their%20goals.
    66% po czasie, 58% poza budżetem, 70% firm co roku ma co najmniej jeden totalnie nieudany projekt.

    https://teamstage.io/project-management-statistics/ - nowe bo z 2023, ale nit tylko o IT.
    70% się nie udaje,
    55% poza budżetem.

    Nawet jeśli weźmiesz najbardziej optymistyczne dane, to nie jest optymistyczne...
  • #7
    gulson
    System Administrator
    khoam wrote:
    @gulson proponuję, aby takie reklamówki nie były "tłumaczone" z innych portali chyba, że na tym forum też artykuł jest "sponsorowany".

    Artykuł to jest opinia / felieton autora. Nie jest oznakowany, jako sponsorowany na portalu źródłowym.
    Jak zauważyłeś, dział Newsy zniknął z strony głównej, a sama liczba tłumaczeń została od czerwca bardzo mocno ograniczona z powodów, o których informowaliście = każdy przy obecnych AI może sobie już poszukać i przeczytać obcojęzyczne informacje.

    Według mnie artykuł niskiej jakości, stąd przenoszę do zamykanego obecnie działu Newsy.

    Dodano po 5 [minuty]:

    Przy okazji bawiłem się tym Flux CoPilot i tam siedzi po prostu Chat GPT3.5, któremu wstrzykują informacje o komponentach, wyprowadzeniach a także położenie X Y na schemacie.
    Nic ciekawego, tylko fajnie opakowane.
  • #8
    CosteC
    Level 38  
    gulson wrote:
    Flux CoPilot i tam siedzi po prostu Chat GPT3.5, któremu wstrzykują informacje o komponentach, wyprowadzeniach a także położenie X Y na schemacie.
    Nic ciekawego, tylko fajnie opakowane.


    Wow. Czyli gorzej niż myślałem. Chat GPT w sprawach technicznym myli się w zaskakujących miejscach a tworzenie footprintów dzisiaj to przyjemność ( np Altium ma dobry generator). Z kolei tworzenie dobrych symboli to sztuka... Bez mózgu i pojęcia o projekcie się nie da dobrze tego zrobić. Oczywiście dla elementu typu procesor a nie op-amp.
  • #9
    RitterX
    Level 39  
    ghost666 wrote:
    Zdaniem twórców Fluxa, ich narzędzie i podejście sprawią, że projektowanie elektroniki znów stanie się intuicyjne i szybkie. Podsumowują to sami, mówiąc, że ich cel to: „z powrotem tchnąć życie w branżę sprzętową”.

    "Dobrymi chęciami to jest piekło wybrukowane".
    To czego pragną nie koniecznie posiada jakikolwiek element wykonalności. Model projektowania w chmurze, pomijając jego szczelność, ma sporo wad, których nie udało się do końca wyeliminować. Pomimo, jakże nowatorskiemu podejściu do pracy, często projekty tego typu legną z powodu np. wkurzenia kilku kluczowych pracowników choćby z powodu π-nia inwestorów albo CEO żądających nierealnych terminów. I zapewniających, że dzięki wspaniałym, innowacyjnym rozwiązaniom można skrócić czas projektowania przynajmniej o 25% jak nie połowę :D .
    Nie tak dawno za kratki trafiła w USA pewna pani, której start-up miał zrewolucjonizować branżę analityczną. Magiczne urządzenia ustawione w amerykańskich aptekach z kropli krwi miały wydedukować na co jest korzystający z ich usługi chory? Sprzętowo była to dramatyczna porażka i nic nie pomogło, że start-up pochodził z Krzemowej Doliny, był innowacyjny i w ogóle.
    Branży z całą pewnością szkodzą fantaści bez pojęcia i inni tego typu id.joci. Czasy odcinania kuponów od dywidendy pokoleniowej, przyzwoicie wykształconych ludzi stąpających po ziemi, już się skończyły i żadne magiczne rozwiązania tego nie skompensują. Dowód jest bardzo prosty, wystarczy w ostatnim numerze The Economist zerknąć na krzywą zjazdową innowacyjności, w tym wiele zmieniających na rynku rozwiązań/projektów.
  • #10
    JacekCz
    Level 40  
    Jak policzek w zestawieniu z notką biograficzną rzekomego tłumacza artykułu, rzekomo specjalisty

    Lepiej milczeć i być podejrzewanym o bycie durniem, niż się odezwać i rozwiać wszelkie wątpliwości
  • #11
    CosteC
    Level 38  
    RitterX wrote:
    Branży z całą pewnością szkodzą fantaści bez pojęcia i inni tego typu id.joci.

    Oj to nie id.joci. To ludzie wykorzystujący chciwość i ignorancję inwestorów. Dosyć cynicznie. A w tym tygodniu modne jest AI oraz "Chat GPT"... wpychają więc gdzie mogą.
  • #13
    gulson
    System Administrator
    CosteC wrote:
    Chat GPT w sprawach technicznym myli się w zaskakujących miejscach a tworzenie footprintów dzisiaj to przyjemność ( np Altium ma dobry generator).

    Teoretycznie używają Chat GPT, ewentualnie trochę wytrenowanego DaVinci od OpenAI, do zbudowania przyjaznej odpowiedzi na podstawie danych, które mu wcześniej wstrzyknęli.
    Stąd powinienem się mylić trochę mniej.
    Ale tak, jak pisałem, pięknie wygląda w artykule, a pod spodem:
    Metodologia projektowania sprzętu jest błędna, co szkodzi branży
    Z drugiej strony czego oczekujemy, że stworzą własne AI, które poznało wszystkie układy, elementy i zasady projektowania?
    Tak, ale jeszcze nie teraz.
  • #14
    khoam
    Level 42  
    gulson wrote:
    Z drugiej strony czego oczekujemy, że stworzą własne AI, które poznało wszystkie układy, elementy i zasady projektowania? Tak, ale jeszcze nie teraz.

    Ale gdy to się stanie, to żadna super "przyjazna" aplikacja dla użytkownika nie będzie chyba potrzebna. Wystarczy prosty wsad tekstowy, kilka komend głosowych i już.
  • #15
    gulson
    System Administrator
    Nie będzie potrzebny człowiek, bo maszyna, zaprojektuje sama siebie, czyli kolejną maszynę. Ale to w końcowej iteracji, będąc po 40stce, nie wiem, czy dożyję :)
    Na razie przydałby się z boku po prostu mądry i wyedukowany elektronik z dostępem do wszystkich elementów elektronicznych i zasad projektowania.
  • #16
    RitterX
    Level 39  
    CosteC wrote:
    Oj to nie id.joci. To ludzie wykorzystujący chciwość i ignorancję inwestorów. Dosyć cynicznie. A w tym tygodniu modne jest AI oraz "Chat GPT"... wpychają więc gdzie mogą.

    Taka jest mądrość obecnego etapu.
  • #17
    CosteC
    Level 38  
    RitterX wrote:
    CosteC wrote:
    Oj to nie id.joci. To ludzie wykorzystujący chciwość i ignorancję inwestorów. Dosyć cynicznie. A w tym tygodniu modne jest AI oraz "Chat GPT"... wpychają więc gdzie mogą.

    Taka jest mądrość obecnego etapu.

    Nic nowego. Ludzi naciągano na złoto na Alasce, w Kalifornii, na cudowne preparaty radioaktywne, na kosmitów a krach na giełdzie cebulek kwiatowych przyczynił się do rewolucji francuskiej, bo ludzie kupowali opcje na przyszłe cebulki tulipanów (czy jakoś tak, dawno czytałem o tym)
  • #18
    RitterX
    Level 39  
    CosteC wrote:
    Nic nowego. Ludzi naciągano na złoto na Alasce, w Kalifornii, na cudowne preparaty radioaktywne, na kosmitów a krach na giełdzie cebulek kwiatowych przyczynił się do rewolucji francuskiej, bo ludzie kupowali opcje na przyszłe cebulki tulipanów (czy jakoś tak, dawno czytałem o tym)

    Obecnie działa to tak samo ale zdecydowanie inaczej, mądrość etapu :) . Ludzie chcą uwierzyć, że AI rozwiąże ich wszystkie problemy i będzie pracowała za nich. Do tego stopnia, że nawet nie będą musieli samodzielnie myśleć. Przewał na cebulkach tulipanów jest fraszką bo w tamtej bajce byli wygrani i przegrani a świat dosyć szybko wrócił do normy za sprawą sporej populacyjnie normalnych ludzi. Obecnie ta grupa już nie jest taka silna populacyjnie i o to może rozbić się problem powrotu do normalności. Narzędzia, które w założeniu mają ułatwiać projektowanie są symptomem tego, że nie dzieje się dobrze i ludzie bardziej polegają na przypadkowym projektowaniu i symulacjach jak na doświadczeniu. Dobrym przykładem szybkiego i efektywnego projektowania jest katastrofa termiczna nowych Ryzen-ów gdzie uszkodzeniu ulegają nie tylko procesory ale i podstawki na płycie głównej. Tego nie zrobiono od tak, w przypadkowy sposób. Policzono, zasymulowano i co może się nie udać? No właśnie! Następna generacja już czeka na swój debiut i nie ma czasu zrobić tego po staremu.
  • #19
    _lazor_
    Moderator of Designing
    RitterX wrote:
    Narzędzia, które w założeniu mają ułatwiać projektowanie są symptomem tego, że nie dzieje się dobrze i ludzie bardziej polegają na przypadkowym projektowaniu i symulacjach jak na doświadczeniu.


    Kiedyś miałem krótką przygodę w diehl w charakterze build to print. Projekt i obliczenia to jest jedno i z nimi może nie być nic złego, gorzej jak się potem dostaje na produkcji nie to co się zamówiło. Taki problem pamiętam z produkcji - zamówili element x i upakowali go dość gęsto - element x przyszedł i miał obudowę większą niż tolerancja producenta zakładała przez co się nie mieściły :D

    Duże skale czy to tworzenia oprogramowania czy hardware (lub jedno i drugie) to są bardzo ciekawe zagadnienia, dalece odbiegające od robienia sobie czegoś w zaciszu domowym a ilość etapów na którym może się coś wysypać jak tak duża że mnie powiem szczerze sama myśl przytłacza często, a jednocześnie powstaje mnóstwo udanych produktów.

    RitterX wrote:
    Dobrym przykładem szybkiego i efektywnego projektowania jest katastrofa termiczna nowych Ryzen-ów gdzie uszkodzeniu ulegają nie tylko procesory ale i podstawki na płycie głównej.


    Taki tekst pokazuje że jesteś trochę jednak ignorantem. Zaprojektowanie sprzętu, który ma współpracować z naprawdę dużą ilością sprzętu innych producentów czy ludzi którzy od razu zmieniają ustawienia fabryczne płyt głównych jest szalonym poziomem.
    Problemem okazało się że SoC nie może pracować powyżej 1.3V, a niektóre płyty główne na to pozwalały. Użytkownik znów musi być traktowany jak idiota, bo fixem jest... zablokowanie możliwości zmiany napięcia powyżej 1.3V. Tak więc takie projekty muszą też zakładać idiotoodporność, co dodaje kolejną warstwę gdzie może pójść coś nie tak.
  • #20
    RitterX
    Level 39  
    _lazor_ wrote:
    Projekt i obliczenia to jest jedno i z nimi może nie być nic złego, gorzej jak się potem dostaje na produkcji nie to co się zamówiło.

    Problemy pojawiają się gdy te obliczenia nie są w żaden sensowny sposób interpretowane. Tak jakby programy do wspomagania projektowania wypluwały prawdę objawioną a nie był jedynie programem do wspomagania projektowania.
    _lazor_ wrote:
    Taki tekst pokazuje że jesteś trochę jednak ignorantem. Zaprojektowanie sprzętu, który ma współpracować z naprawdę dużą ilością sprzętu innych producentów czy ludzi którzy od razu zmieniają ustawienia fabryczne płyt głównych jest szalonym poziomem.

    Doceniam krytykę. Problemem nie jest w tym przypadku zmiana ustawień gdyż od ponad dekady rozwiązanie jest stosowane na szeroką skalę z rdzeniami generującymi znacznie więcej ciepła. Nie jest żadną tajemnicą, że zabezpieczenie termiczne we wnętrzu rdzenia jest ustawione arbitralnie na pewną wartość i to nie mechanizm przegrzania uszkadza zbyt wysokim napięciem zasilania strukturę.Porównując ewolucję rozwiązań jakie są stosowane w elektronice przemysłowej: serwery, czujniki, sterowniki,... mam coraz bardziej rosnące przekonanie, że ktoś mocno przekombinował z liczbą dostawców i kontraktorów projektowych. Wychodzą ulepy, które nie tworzą trwałej, sprawnej całości. O ile można w elektronice konsumenckiej położyć patyk na zbyt dużą trwałość to są miejsca gdzie od elektroniki naprawdę wiele, namacalnie zależy. Gdy tymczasem to coraz bardziej zmierza ku rozwiązaniom elektroniki konsumenckiej.
    Nie tak dawno struktury GPU nowych kart były seryjnie niszczone poprzez... aktualizację oprogramowania, sterowników.
    I znowu użytkownicy okazali się ß-testerami.
  • #21
    _lazor_
    Moderator of Designing
    Jak pisałem wcześniej, obliczenia będą najczęściej poprawne, ale już wykonanie może być różne. Ogólnie aktualnie więcej kasy poświęca się na quality niż na sam development, a nie oznacza że na development jest przeznaczane za mało.

    W przypadku ryzenów uważam, że to nie za bardzo ich wina bo po co mają coś testować po za zakresem z noty? Czujnik temperatury też nie zadziała w takim wypadku bo tutaj najwyraźniej dochodziło do klasycznego zwarcia, a że moc w impulsie jest tam znaczna to niech nie myli człowieka te 1.3V

    Jak napisałeś już o hali to na wiki można przeczytać:
    "Faktyczny projektant hali nie posiadał stosownych uprawnień, dlatego projekt został podpisany przez innego konstruktora. Według Grzegorza Buczka ze Stowarzyszenia Architektów Polskich takie nielegalne praktyki budowlane są w Polsce powszechne[2]."

    Tak więc pisanie o druciarstwie podpartymi uprawnieniami i tytułami jest połowicznie prawdziwe, bo jeden nie miał a drugi pazerny.

    oraz

    "W raporcie przekazanym prokuraturze na początku maja 2006 powołani przez nią biegli podali jako powód katastrofy zmiany dokonane w projekcie wykonawczym w porównaniu do projektu budowlanego."

    Tak jak pisałem nie koniecznie projekt musi być zły, może być źle zrealizowany. W przypadku hali, poszły dwie rzeczy jednocześnie.
  • #22
    RitterX
    Level 39  
    _lazor_ wrote:
    ak więc pisanie o druciarstwie podpartymi uprawnieniami i tytułami jest połowicznie prawdziwe, bo jeden nie miał a drugi pazerny.

    Projekt był zrobiony za pomocą programu "na pałę" dla założeń klimatycznych Włoch. Gdyby to koleś liczył na piechotę, potrafił to ryzyko byłoby, o ironio mniejsze. Dlatego, że musiałby to policzyć a ktoś inny sprawdzić.

    Wracając do skuteczności zarządzania dużymi projektami za pomocą magicznego oprogramowania, niech jądro Linux-a będzie dobrym przykładem jak to należy robić w rozproszonym środowisku. Okazuje się, nie tylko w tym przykładzie, że suma nawet nieźle wykonanych części nie gwarantuje sukcesu o ile ktoś a nie oprogramowanie nie decyduje, w którą stronę projekt ma zmierzać. Nie koniecznie kierując się aktualnymi modami i fiksacjami jego współtwórców. Innym przykładem jest choćby biblioteka boost. To dwa przykłady spośród bardzo wielu, z których można się wiele nauczyć. Także w odniesieniu do nauki poprawnego programowania. Z projektami sprzętowymi jest tak samo. To nie zrobi się samo za pomocą czarodziejskich rozwiązań ułatwiających projektowanie ani też na spontanie. Ktoś musi wiedzieć co ma wyjść na końcu.

    W przypadku Ryzen-ów problemem jest sposób osadzenia struktur na podłożu. Kryształy bardzo dobrze przewodzą ciepło w obie strony, zarówno do podłoża jak i przede wszystkim, metalowego IHS-a. Powstanie w jednym, powtarzającym się miejscu zwęglenia laminatu to nie jest typowy objaw uszkodzenia termicznego struktury. Gdyby przyczyną było przegrzanie to struktura krzemowa wypalałaby dosyć równo podłoże.
  • #23
    _lazor_
    Moderator of Designing
    Nie wiem czy zaglądałeś do implementacji boosta, ja niestety musiałem. Nic przyjemnego w tym nie było.

    W sumie byłem teraz trochę przymuszony do rozpoczęcia pracy na linuksie desktopowym i powiem szczerze, że żart o tym że linux i klimatyzacja nie działają najlepiej przy otwartym oknie nadal jest aktualny. Jednak CMD to poezja. Samo jądro linuksa może i jest dobrze prowadzone, ale czytanie guideline do pisania kodu w jajku linusa to niezły kabaret, taki przykład:
    "Tabs are 8 characters, and thus indentations are also 8 characters. There are heretic movements that try to make indentations 4 (or even 2!) characters deep, and that is akin to trying to define the value of PI to be 3."
    https://www.kernel.org/doc/html/v4.10/process/coding-style.html

    Samo dostarczanie kodu i proces review to inny kabaret, i zdecydowanie nie mówiłbym że jest to coś godnego naśladowania.
  • #24
    khoam
    Level 42  
    _lazor_ wrote:
    "Tabs are 8 characters, and thus indentations are also 8 characters. There are heretic movements that try to make indentations 4 (or even 2!) characters deep, and that is akin to trying to define the value of PI to be 3."

    Takie rulez :) Lepsze takie, niż żadne.

    _lazor_ wrote:
    Nie wiem czy zaglądałeś do implementacji boosta, ja niestety musiałem. Nic przyjemnego w tym nie było.

    To jest perfidne i intencjonalne ze strony deweloperów Boost. Dla przyjemności, to są inne portale ;)