> No więc ja też otwieram kilkadziesiąt tysięcy plików w kilkudziesięciu
> projektach jednocześnie i nie mam problem z kontrolą wersji, pracą w
> zespole, poprawianiem tych samych miejsc itd itp. Co specyficznego w tym
> zagadnieniu żesię nie da?

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

> Pochwal się co to za soft. Jestem ciekaw jak wyglada flow zespołowy na
> wspólnych plikach.

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

> PS2. Gdzie te gigabity które wymagały wymiany NASa na jakiś hiper
> prędki? Przecież, jesli dobrze rozumiem, nie otwieracie tych
> terabajtowych projektów na raz wszystkich wszedzie.

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.

do góry

> No trochę inaczej, byli informatycy i byli programiści. Konserwatorów i
> operatorów też nikt informatykami nie nazywał.
>

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.

do góry

On 30/03/2021 22:01, Irek.N. wrote:
>> No więc ja też otwieram kilkadziesiąt tysięcy plików w kilkudziesięciu
>> projektach jednocześnie i nie mam problem z kontrolą wersji, pracą w
>> zespole, poprawianiem tych samych miejsc itd itp. Co specyficznego w
>> tym zagadnieniu żesię nie da?
> "Margowalne" piszesz? No to moje pewnie nie są.

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

>> Pochwal się co to za soft. Jestem ciekaw jak wyglada flow zespołowy na
>> wspólnych plikach.
> Ani myślę, za daleko się nie posunę :)

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.

>> PS2. Gdzie te gigabity które wymagały wymiany NASa na jakiś hiper
>> prędki? Przecież, jesli dobrze rozumiem, nie otwieracie tych
>> terabajtowych projektów na raz wszystkich wszedzie.
> Przeginasz. Nigdy nic takiego nie było pisane.

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.

> Wymiana NAS-a na WS
> podyktowana była czasem otwierania projektu. Nie wszystkich projektów,
> tylko projektu - JEDNEGO na ten przykład.

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.

> 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 serweraNAS
> zastosował tak mulił.

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

> 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?

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.

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

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...

[1] To nie jest prawda, ClearCase ma tryb "wszyscy widzą to samo" ale on
nie polega plikach na sieci, tylko na synchronizacji lokalnych plików
automatycznie. Dzięki temu jest najbardziej znienawidzonym przez
programistów i ulubionym przez managerów kawałkiem software do
utrudniania programowania i rysowania ślicznych wykresów do prezentacji
co poniedziałek.

do góry

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

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.

> 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?

Tak, to tego typu oprogramowanie.

> 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.

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ę.

> 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?

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" :)

> 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.

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?

> 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.

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 ;)

>> Wymiana NAS-a na WS podyktowana była czasem otwierania projektu. Nie
>> wszystkich projektów, tylko projektu - JEDNEGO na ten przykład.
>
> Programista pracuje na loklanych danych aby nie uszkadzać pracy innym,
> aby były stabilne stany repozytorium dla innych i aby było *szybko*.

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.

> 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.

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

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

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?

> 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?

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ż.

> 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.

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.

> 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.

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

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

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.

> 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...

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?

do góry

On Tue, 30 Mar 2021 23:15:28 +0200, heby <h...@p...onet.pl> wrote:
> Skoro większosci projektów nie otwieracie, a wiele otwieracie w RO
> to
>

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....

--
Marek

do góry

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

> On Tue, 30 Mar 2021 23:15:28 +0200, heby <h...@p...onet.pl> wrote:
>> Skoro większosci projektów nie otwieracie, a wiele otwieracie w RO
>> to
>>
>
> 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

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.

> 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....

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?


--
Pozdrawiam.

Adam

do góry

Hello Cezary,

Tuesday, March 30, 2021, 9:56:21 PM, you wrote:

>> Mgliście pamiętam tamte dzieje, ale przypominam sobie, że wysyłano
>> informatyków (tak się wtedy o wszystkich mających cokolwiek z
>> komputerami wspólnego mówiło) na kursy...

> No trochę inaczej, byli informatycy i byli programiści. Konserwatorów i
> operatorów też nikt informatykami nie nazywał.

Informatyk to ten od wymieniania taśm w drukarkach i uczenia pani
Krysi (50+, 20+ lat pracy na komputerze) jak się dodaje zawartość
dwóch komórek w Excelu?

--
Best regards,
RoMan
Nowa strona: http://www.elektronika.squadack.com (w budowie!)

do góry

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

>>> Mgliście pamiętam tamte dzieje, ale przypominam sobie, że wysyłano
>>> informatyków (tak się wtedy o wszystkich mających cokolwiek z
>>> komputerami wspólnego mówiło) na kursy...
>
>> No trochę inaczej, byli informatycy i byli programiści. Konserwatorów i
>> operatorów też nikt informatykami nie nazywał.
>
> Informatyk to ten od wymieniania taśm w drukarkach i uczenia pani
> Krysi (50+, 20+ lat pracy na komputerze) jak się dodaje zawartość
> dwóch komórek w Excelu?
>
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 :)


--
LordBluzg(R)
<<<Pasek Grozy TVPiS>>>
NASZE KŁAMSTWA SĄ PRAWDĄ

do góry

On 30/03/2021 23:58, Irek.N. wrote:
>> A co powoduje, że się nie da :D?
> 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.

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

>> 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ładkipod śrubkę. Żeby nie było: to samo dotyczy większości
>> programów do PCB iwielu innych CADów. To ogólnie problem tego
>> środowiska chyba.
> Wiesz, jak ktoś rysuje śrubkę, to niby jak ma mu pomóc w tym większe
> środowisko - w sensie więcej ludu?

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
*ważne*. W przypadku innych branż otwiera się projekty z jakiejś
konkretnej chwili czasowej, ale na pewno nie *dokładnie* te nad którymi
pracuje stolik obok.

> Projekt na którym robiłem testy miał chyba 300MB

To na waciki.

>, 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" :)

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

> niewiele wolniej niż z sieci 1G na "ponadprzeciętnym". Po cholerę
> kombinować więc?

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?

> 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 ;)

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

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

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

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

https://pclab.pl/art72561-2.html

Ogólnie w przypadku iditycznego oprogramowania które nie potrafi
sensownie otwierać plików, NVMe jest wybawieniem ponieważ on działą
szybko czy oprogramowanie normalne, czy pisane przez miszczuf CADów. I
tu i tu sobie poradzi.

>> No to trzeba było reklamować jak nie osiągał obiecanych prędkości.
> Ale co, NAS-a? Osiąga przecież. Jak ma "skopiować, pobrać, zapisać" to
> osiąga.

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?

> Ty dalej nie załapałeś. NIE MAM PROBLEMU

To Ci sie tylko tak wydaje ;)

> Wygodnie jest mi przez sieci, bo zapisane jest tylko jeden raz, więcnie
> 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ż.

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.

> 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.

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 :)

>> 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.
> Dlaczego wiec uważasz, że ja powinienem pracować z lokalnego?

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

>> Opowiedz coś więcej, temat mnie bardzo zainteresował.
> 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.

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.

> ps. nie uważasz, że to już NTG^3? Kończymy?

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.

do góry

On 31/03/2021 01:04, Marek wrote:
> On Tue, 30 Mar 2021 23:15:28 +0200, heby <h...@p...onet.pl> wrote:
>> Skoro większosci projektów nie otwieracie, a wiele otwieracie w RO to
> 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.

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.

do góry