Pytanie NTG niestety - Notebook wielosystemowy.

"Margowalne" piszesz? No to moje pewnie nie są.

Ani myślę, za daleko się nie posunę :)

Przeginasz. Nigdy nic takiego nie było pisane. Wymiana NAS-a na WS podyktowana była czasem otwierania projektu. Nie wszystkich projektów, tylko projektu - JEDNEGO na ten przykład. Dla mnie ma znaczenie, czy projekt otwiera się 1.5 minuty, czy 25 minut. Miałem tak, że konstruktor otwierał projekt i szedł sobie zapalić i zrobić kawę. Czasami jak wrócił, nadal nie był projekt otwarty. To nie GB danych, tylko gówniany linux w wersji jaką producent serwera NAS zastosował tak mulił.

Przypomnę Ci: > W temacie wydajności, to chyba jest trochę jak heby pisał - o firmie z pierdylionem małych pliczków. > Otwieranie projektu (mój przypadek) to w zasadzie czytanie bardzo dużej liczby małych plików i pewnie tutaj jest pies pogrzebany.

Odpowiedziałeś: Dlaczgo czytasz ja z NASu a nie lokalnego dysku?

Zaraz, jak pracujesz z dysku lokalnego we współdzielonym środowisku?

Miłego. Irek.N.

Może w zakładach, w których główna produkcja miała coś wspólnego z komputerami i wszyscy ogarniali temat. W zakładach pracy, elektrociepłowni, w hurtowni w której też dane było mi pracować - byli informatycy. Nikt nie mówił do mnie administratorze, programisto, konserwatorze :)

To były dziwne czasy. Jak sie gdzieś taki pojawiał, to zawsze było pytanie o kawę, może ciasteczko? Nie, no to może herbatkę chociaż? Aż mi głupio było. Zaproszono mnie nawet na spotkanie kadry dyrektorskiej... a ja tam wojsko tylko odrabiałem jako informatyk.

Miłego. Irek.N.

A co powoduje, że się nie da :D?

No właśnie tak się zastanawiam. Czy to nie aby ten profesjonalny Autocad który mentalnie dalej nie zauważył że lata 60-te słusznie minęły? Prawie każdy stawia mi go jako pierwszy przykład profesjonalizmu nieosiągalnego w systemach dla pryszczatych nastolatków a ja bezustannie słyszę takie właśnie opowieści po których zbiera mi się na wymioty kiedy wyobrażam sobie z nim pracę trudniejszą niż projekt podkładki pod śrubkę. Żeby nie było: to samo dotyczy większości programów do PCB i wielu innych CADów. To ogólnie problem tego środowiska chyba.

No nie było, ale przeciez nie trudno się domyślic, że samba klękała pod wpływem ogromnego obciążenia. Oczami wyobraźni widze, jak w te i nazad latają po 10gbit jakieś terabajty danych per projekt. To nie latają? To co tam lata że profesjonalny NAS klękał i trzeba było nadprofesjonalnego?

Na marginesie: lokalny dysk NVMe jest nieporównywalnie szybszy pod każdym możliwym względem niż jakiekolwiek NASy sieciowe, choćby na samym Windowsie 14. Tym bardziej jestem zdumiony że ktoś to ciągnie po sieci i ma takie czasy otwierania projektu.

Skoro większosci projektów nie otwieracie, a wiele otwieracie w RO to jest to wręcz dokłanie to samo co robią programiści podczas codziennej udręki. Nie wiem dlaczego ta analogia nie działa w przypadku CADa i to musi działać z NASa.

Tyle danych? Tyle plików?

Nie zrozum mnie źle, ja jestem najzwyczajniej ciekawy. Programiści rozwiązali to dziesiątki lat temu (co nie znaczy że dalej nie ma problemów, ale ... ogarniamy to lepiej niż na początku). Jestem ciekaw jakie sa przeszkody w innych branżach, że się nie da i trzeba stosować jakieś workaroundy typu praca na wspólnym wysypisku śmieci, jak NAS.

Programista pracuje na loklanych danych aby nie uszkadzać pracy innym, aby były stabilne stany repozytorium dla innych i aby było *szybko*.

Zakładając że nie możecie mergować danych, bo format do dupy, dalej nie pojmuje po co męczyć się z sieciowymi dyskami, skoro NVMe za kilka stówek zjada je na śniadanie? I w dodatku wymusza pracę na stabilnej kopii, czyli bezpiecznie, lokalnie, nie psując innym.

No to trzeba było reklamować jak nie osiągał obiecanych prędkości.

No własnie, pytanie dalej aktualne. Skoro masz problem w wydajnością wspólnego katalogu JEDNOCZEŚNIE otwierajac jeden projekt w RW a drugi w RO, to czym to się różni od otwierania lokalnie w trybie RO z własnych plików? Te pliki, jeśli będa zarządzane przez głupi subversion, nigdy nie nie rozsynchronizują, popsują, zawsze można będzie wszystko wyprostować i naprawić. Czy akurat subversion, to nie wiem, ale chodzi tylko o to że Twoje "problemy z synchronizacją plików" są problemamy VCS a nie jednostki białkowej i są dawno rozwiazane w sposób całkiem przyzwoity.

Ktoś pracuje nad śrubą. Drugi nad nakrętką. Ten od śruby zrobił łeb. Ten od nakrętku MUSI natychmiast to widzieć, czy sa inne powody otwierania wspólnych plików? Systemy kontroli wersji robią to na życzenie, jeśli koniecznie potrzebujesz.

Czekaj, bo się pogubiłem, to pytanie do mnie?

Nikt nie pracuje na wspólnym dysku w ogólnie pojętym tworzeniu oprogramowania [1]. Pracuje się na wspólnym repozytorium i lokalnych kopiach, ogarnianych przez system kontroli wersji. Zakładam że nie możesz go użyć u siebie, a ja jestem naprawdę ciekawy dlaczego. Zawsze interesowały mnie zagadnienia z gatunku inżynierii [o]programowania, a to jest prawie to samo.

Opowiedz coś więcej, temat mnie bardzo zainteresował.

Kiedyś byłem na prezentacji oprogramowania do współdzielenia plików przy tworzeniu map. Nie pamiętam już co to było, ale pamiętam głównie kwadratowe koła, a najbardziej koncepcje "tu zaznaczamy, blokujemy i już możemy pracować i nikt nam tego nie popsuje". Śmiesznie, ale też straszno. Biedni ludzie którzy z tym g... musieli pracować. Potem usłyszałem anegdotkę jak ściągali kogoś z urlopu bo zablokował mapę i nie odblokował i żeby uważać. Wszyscy na sali kiwali głowami ze zrozumieniem. Tak, dokładnie tak trzeba uważać. Połowę tej prezentacji to był facepalm w moim wykonaniu, szczególnie po zobaczeniu ceny z okolic nowego samochodu per stanowisko. Do dziś nie wiem za co, choć przyznam że mieli jakieś certyfikacje...

A to już nie mnie pytaj. Dla mnie te pliki to binarki. Jest soft pozwalający tym zarządzać, ale jak pisałem wcześniej, drogi i nie wnoszący dla mnie nic istotnego, wręcz odwrotnie.

Tak, to tego typu oprogramowanie.

Wiesz, jak ktoś rysuje śrubkę, to niby jak ma mu pomóc w tym większe środowisko - w sensie więcej ludu? Kto będzie odpowiadał za gwint, a kto poprawił wybieg, kto za długość, a czy naniesiono klasę wytrzymałości? Śrubkę rysuje jedna osoba i za nią odpowiada, co najwyżej z tych "śrubek" zespół składa coś tam większego. Tak ja to widzę.

To jest właśnie to pytanie, na które w zasadzie nikt nie potrafi odpowiedzieć poza producentem, który mówi "taką mamy sambę i odwal się". Projekt na którym robiłem testy miał chyba 300MB, nie pamiętam ile plików, ale nie jakieś wypaśne tysiące, a mimo wszystko były znaczące różnice w otwieraniu pomiędzy przeciętnym, a ponad przeciętnym jak Ty to nazwałeś. Być może jest tak, że oprogramowanie otwiera, zamyka, otwiera i tak pierdylion razy na każdym pliku, no i samba mówi "będzie tego" :)

Ale wiesz, teraz mam bardzo akceptowalne czasy ciągnąc po sieci 1G. Robiłem próby na sieci 10G i różnice były symboliczne. Sieć nie jest problemem - sieć jako taka. Mało tego, z lokalnego dysku SSD otwiera się niewiele wolniej niż z sieci 1G na "ponadprzeciętnym". Po cholerę kombinować więc?

Poradziliśmy sobie jeszcze inaczej, ale aby prace projektowe szły szybko, otwieranie RW (bo tylko w tym trybie powstaje przecież coś nowego) musi być szybkie - o to walczyliśmy i to wygraliśmy ;)

Ja tam się nie znam. Mam to ogarnięte wystarczająco dobrze moim zdaniem. Zresztą był audyt w tym temacie i nie potrafiono zaproponować nic znacząco lepszego.

Nie znam się, googlowanie skrótu NVMe daje wyniki trochę dziwne w stosunku do tego czego się spodziewam.

Ale co, NAS-a? Osiąga przecież. Jak ma "skopiować, pobrać, zapisać" to osiąga. Oprogramowanie reklamować? Przecież otwiera się szybko z HDD i nawet "ponadprzeciętnej" sieci. Co reklamować, komu?

Ty dalej nie załapałeś. NIE MAM PROBLEMU, już nie mam, wywaliłem serwer na linuxie i NIE MAM PROBLEMU. :) Wygodnie jest mi przez sieci, bo zapisane jest tylko jeden raz, więc nie mam wersji, mają dostęp wszyscy którzy powinni. Jeden coś zmieni, wszyscy widzą. Po to wymyślono sieć, a nie bieganie z dyskietkami przecież.

I tak z grubsza jest. Nie pracują na wspólnym pliku. Śrubka ma swój plik, nakrętka ma swój plik. W złożeniu które może ogarniać jeszcze ktoś inny są oba elementy. Nic w złożeniu nie zmienia się od razu. Wyobrażasz sobie, że coś rysujesz, a tu Ci nagle na ekranie element się przesuwa, bo ktoś go zmienia? :) To działa trochę inaczej w tej branży.

Dlaczego wiec uważasz, że ja powinienem pracować z lokalnego?

Ale co chcesz wiedzieć? Nie opowiem Ci jak ja to mam zorganizowane, bo to wyłącznie moja sprawa i nie mam zamiaru publicznie opowiadać szczegółów o firmie i zarządzaniu nią. Pisałem już Ci o tym.

To co ja używam nie jest drogie, ale i tak pojawiają się rozwiązania w stylu M$ office. Nie mają już co wymyślić, to zaczynają na siłę udoskonalać interfejs. W efekcie pracuje się gorzej na nowych wersjach niż na starych. Taki chyba znak czasów po prostu. Żeby było jeszcze śmieszniej. Jak zaprojektujesz coś, to jest dedykowana (płatna i to nie mało) przeglądarka do plików (viewer po prostu) która... nie pokazuje wszystkiego co narysowałeś! A co, jeszcze miał byś za łatwo.

Miłego. Irek.N. ps. nie uważasz, że to już NTG^3? Kończymy?

IMHO problem leży w definicji "otwieranie projektu". Ty to rozumiesz (ja też) jako proste fopen(), takie otwieranie nie ma prawa być wolne na dowolnie współczesnym sprzęcie na nawet tysiącu plików. Ale obawiam się, że to "otwieranie" to jakiś proces czytania z jednego pliku (lub wielu) i jednoczesne tworzenie wiele tymczasowych i to w jakiś idiotyczny mało wydajny sposób. Proces "otwarcia" mieli po FS/IO, być może na lokalnym dysku trwa to szybko, ale na "sieciowym" pewne opóźnienia się sumują i wychodzi 25min (co i tak jest jakimś absurdem). Założę się, że to jest do naprawienia.

Pamiętam 20 lat temu wymieniłem znajomemu serwer z NetWare 5.0, używał to jako serwer plików do aplikacji sprzedażowo-kasowej (FPP CDNu), aplikacja dosowa, oparta na Clarionie (coś analogicznego do dBase). Przy starcie otwierała kilkadziesiąt plików, nawet było takie okienko w którym pisała "otwieram nazwa.roz..." przy czym "nazwa.roz" szybko zmieniało się za każdym otwartym plikiem. Takie info startowe aplikacji. Po zamianie serwera na sambę z Linuxem otwieranie było tak szybkie, że to okienko tylko mignelo przez chwilę, nie dało przeczytać poszczególnych nazw....

Dnia Wed, 31 Mar 2021 01:04:00 +0200, Marek napisał(a):

Bardziej Clipper niż dBase. Chyba, że masz na myśli pliki danych, jako takie (czyli *.dat i *.k??). Ale i tutaj pliki clarionowe były o generację do przodu względem dbase, bo m.in. miały klucze.

Coś sobie przypominam, że Netware 5.0 miał problem. Szybciej chodził już nawet stary 3.12, poprawka była w 5.1. Ale i do 5.0 coś się dogrywało albo zmieniało w standardowych ustawieniach i już działało ok. Ewentualnie można było postawić FPP c/s, ale to już był Pervasive SQL. Przynajmniej backup szedł kilka razy krócej niż z bazami clarionowymi.

A czy przypadkiem ten Netware nie był na RG58, a samba na RJ45? Czyli bus kontra gwiazda?

W dniu 31.03.2021 o 02:32, RoMan Mandziejewicz pisze:

Oni pisali o +/- 15 lat temu. Dzisiaj informatyk, to taka osoba, że jak jej nie ma to coś się pierdoli 3x w tygodniu. Jak jest informatyk to wszystko działa 24/7 i nikt go nie widzi :) co prawda pierdolą o pobieraniu kasy ale wystarczy zwykłe L4 na 2 tygodnie i zmieniają zdanie. Oporni tłumaczą, że to spisek i sabotaż. Potem są problemy z przekazaniem haseł (bo każdemu może się zdarzyć zapomnieć) a już byli admini mają sklerozę detektowaną na poziomie DNA :)

Cos mi się wydaje że to świadome działanie producenta. Vendor-lockin.

Pytam na tami mikro przykładzie bo jestem ciekaw po co otwierasz projekty nad którymi pracują inni w tym samym momencie i to jest

To na waciki.

I tu wchodzi dysk lokalny, cały na biało.

Ponieważ jestem zafascynowany tą metodyką pracy z gatunku "otwieram swoje i jeszcze 4x sasiadów". Szukam przyczyny która powoduje że właśnie tak się pracuje.

Sąsiad zmienia otwór z Fi7 na Fi8. Musisz to *natychmiast* widzieć u siebie? A jeśli nie musisz, to po co otwieradz te same pliki co on, do pracy? Tylko dlatego żeby było w jednym miejscu?

Nie neguje że wypracowaliście jakiś workaround ;)

I nie twierdze że ja coś wymyslę przeciez, mnie po prostu fascynuje zagadnienie.

Nie, przypuszczam że prodcent chwailił się detalami typu transfery, ilosc otwieranych/zamykanych plików na sek itd itp. W końcu to nie był biedaNAS, prawda?

To Ci sie tylko tak wydaje ;)

Jak bym słyszał tego kolesia który pękał z dumy że wymyślili zgrywanie po południu wszystkich plików do katalogu z datą ;)

"Nikt tak nie robi" ponieważ wymyśliliśmy sensowniejsze metody radzenia sobie podczas pracy w team, i myslę że część z tych metod ma zastosowanie nawet w tak toksyczym środowisku jak CADy z plikami binarnymi.

Czyli otwieranie przez kilka osób tego samego projektu nie ma na selu ogladanie na zywo ich pracy? Myślałem że to podstawowy argument "musimy mieć to w jednym miejscu". Jesli tak nie jest to pęka ostatnia linia obrony tej metodyki :)

Z tych samych powodów z jakich programisci nie pracują ze wspólnego.

Dla bezpieczeństwa Bo mają piaskownicę Bo mogą zarządzać wersjami Bo mogą wycofywać Bo nie psują przypadkiem pracy innym I jeszcze kilka innych

No trudno, mimo to jestem tego bardzo ciekaw. Nie trafia mi się często tak popsuty koncept, który działa. Tak sobie myślałem kiedyś, są duże firmy zajmujące sie projektowaniem. W tych firmach pracują ludzie któzy posługują się jakimiś koncepcjami pracy zespołowej. Jeśli to programiści

- wiadomo - kontrola wersji. Ale jesli to CADowcy, to niezmiennie, od 20 lat, widzę zawsze coś komplenie niezrozumiałego, czego nie potrafie pojąć. Mam wrażenie że dziadowskośc oprogramowania CAD powoduje wymyślanie kwadratowych kół w miejscu gdzie już od dziesięcioleci znamy lepsze rozwiązania.

Teraz? Kiedy na horyzoncie widać już jakieś konkluzje? O nie!

A reszta grupowiczów pewnie siedzi z popcornem, wreszcie jakaś odmiana, a i CADy nie są tak daleko od elektroniki.

I w czym szybki dysk lokalny o pomijalnych czasach dostepu względme sieci, miałby być w tym znacząco gorszy? To mnie zastanawia. Wymieniasz technologie na taką gdzie jest kolizyjnośc i latency i wielodostęp i ... działa szybciej. Zastanawiające.

A pomyślałeś o tym, że są stabilne procesy (jakkolwiek byłyby debilne) u klientów i ruszenie czegokolwiek może spowodować konieczność reorganizacji pracy / recertfikacji? Co globalnie przekłada się na grube M$ + trudne do wycenienia wqurwienie klientów ...

No bo do czego to podobne, żeby klient który od lat o 15:01 kopiuje pliki *.debilne_rozszerzenie miał nagle zacząć kopiować

A przypominam, że poruszamy się w środowisku inżynierów co to (słusznie?) uważają, że jak coś działa to nie ruszać ...

Piotrek

Ale ja wiem o tym, mnie zastanawia geneza początku takich problemów z CADami i wybór takigo rozwiązania.

W przykładowej anegdocie kopiowania po południu plików do katalogu z datą, genezę znam: właściciel firmy jest typowym, zarizumiałym hackerem, który założył że on wymyslił najlepiej. Większosć energii poświęcił w udowadnianiu że inne rozwiązania są błedne. Więc tutaj sprawa jest jasna, własciciel uparty i reszta świata się myli.

Teraz, w przypadku CADów, jestem ciekaw.

Widzę kilka opcji:

Żeby nie było: uczesniczyłem w procesie wprowadzania systemu kontroli wersji w pewnej firmie *programistycznej*. Był niesamowity ból dupy, wycie po nocach, rzucanie kurwami, walenie głową w mur, przez "programatorów" z tamtejszej firmy. Upłyneło 10 lat i nie wyobrażają sobie pracy inacze a o epizodzie z FTP, którego używali przed rewolucją, starają się mówić szeptem, bo wstyd.

Innymi słowy wydotanie się ze swojego minimum loklalnego bywa kłopotliwe i czasami wymaga popchnięcia przez kogoś z zewnątrz bo sami mogą nie mieć dośc energii/woli.

Na szczęscie systemy kontroli wersji robią to same i raczej w sposób pewny ;) Ty tylko mówisz kiedy.

Wiem, ale grupa inzynierów programistów, a to przecież też inzyniery, jakoś nie ma problemu ze sprawdzaniem wielu róznych środowisk produkcyjnych i wyborem bliskich optymalnym. A jak optymalnośc stanie sie optymalniejsza, to często się przenoszą z kamotrami w środku procesu produkcji na inną metodykę i dalej bangla. Inercja w przypadku CADów tak wielka że każda zmiana powoduje że firma staje? Ja bym w tym widział zagrożenie...

Dokładnie, Clarion bo pamiętam potrzebne były narzędzia do modyfikacji .*dat lub do szybszej odbudowy kluczy (fpp robił to wolniej).

To było na pewno na rj45

No przecież pisałem, że lokalny lepszy, dlaczego miałby być gorszy??

U Irka gorszy. Zastanawia mnie dlaczego ;)

Tak trochę podwójnie zainspirowany tym wątkiem zacząłem czytać dokumentację MINIXA 3 (który oprócz tego, że ma mikrokernel ma ciekawą funkcję reinkarnacji). Nie wszedłem jeszcze głęboko ale wygląda na to, że taki 'user space' driver musi w jakiś sposób zgłosić do czego może mieć dostęp. Oczywiście jądro i tak mu nie pozwoli na dostęp do zasobów zastrzeżonych przez inne drivery ale nadal krótkowzrocznie widzę "moment rejestracji i ustalenia zasobów" jako potencjalną dziurę. Oczywiście tak jest o wiele bezpieczniej bo driver jest odseparowany w przeciwieństwie do monolitu. Napisałem "podwójnie zainspirowany" bo dwa lata temu tak dla gimnastyki umysłu i nauki MIPSa napisałem taki prosty kernel z wywłaszczeniem, pamięcią wirtualną, separacją procesów itp., nie robiło toto na razie nic więcej niż uruchamianie procesów piszących A B C na uart. Z zamierzenia miał być monolityczny, przez co utknąłem na implementacji (dużo) syscalli... Ale widzę, że szybciej możnaby z tego zrobić w pełni sprawny mikrokernel niż monolit....

To chyba działa tak: hardware PCI[e] określa zakres IO/DMA. Kernel bierze ten zakres i taktuje jako ograniczenie dla sterownika. Sterownik, jesli chce coś wiecej, to prosi kernel o udostepnienie, np. na jakiś bufor w pamieci. Ale ogólnie to kernel musi się na to zgodzić.

Ostatnio z ciekawostek, to np. włamano się do PS4 poprzez fake urządzenie PCI. Kernel nie sprawdzał czy hardware jest oryginalne i udało się zrobić hardwareowy atak MItM. Wiec mikrokernel nie chroni przez takimi rzeczami, podobnie jak bugami w CPU, ale i tak ładowanie takiego sterowanika nVidi w działajacy kernel uważam za grube przegięcie, nie wiadomo co w nim jest, więc lepiej coby był ograniczony do określonego zakresu IO i shared memory z jakimś procesem po stronie usera.

Może nie warto robić...

Ja to jeszcze pamiętam czasy pracy wsadowej na R32 :-) i później czasy PDP11/SM-coś-tam ... A przecież pierwsze CADy to właśnie te klimaty.

Tak więc trzeba było kombinować (z formatami binarnymi), żeby było szybko i oszczędnie. Dodatkowo własny format danych utrudniał migrację do konkurencji, etc

A później to już IMHO poleciało na zasadzie "jak coś działa to nie ruszać ..."

Ototo!

A po co mają się znać na komputerach jak się znają na CAD-ach ...

Jak jest za wolno to się kupuje szybszy komputer a nie kopie z dostawcą narzędzi, żeby może coś grzebnął w kodzie. Przecież to oczywiste ;-)

Jak roboty jest tyle, że nie ma kiedy taczek załadować to nikt nie będzie się bawił w zmiany. Chyba, że "księgowemu" wyliczysz, że przez to zaoszczędzi ileś tam $$$$

Przede wszystkim to słaby przykład bo dziedzina w której obracali się rzeczeni programiści jakoś tam korespondowała z zakresem wdrożenia.

A na ogół to jest tak, że zmiany w backoffice są czarną magią do biura projektowego czy innej przychodni. I pojawiają się karteczki w rodzaju "Przepraszamy za opóźnienia - nowy SYSTEM INFORMATYCZNY".

W przychodnie to jeszcze suweren poczeka. Ale jak deadline goni deadline a kary umowne są konkretne to taniej jest postawić lepszy sprzęt, zatrudnić więcej ludzi, niż pieprzyć się z wdrożeniem/migracją do nowej wersji. Albo co gorsza nowego super-duper-optymalnego software co to otwiera projekt w ułamku sekundy ale za to wysypuje się pięć minut później ... bo dostawca musiał zdążyć przed konkurencją.

A "jak software ciepły to wiadomo, że może się wywrócić" ...

IMHO tak to działa.

Piotrek

Tak wiem... ale tutaj chodzi tylko o taką dziecięcą fascynację zrobienia własnej zabawki ;).

Doskonale to rozumiem ;)