> Tak, i ten gruby kawał kodu lub symulacja może być o rzędy wielkości
> bardziej skomplikowana niż projekt samolotu.
>
> Przypuszczalnie masz podejście niszowe: CADy są najbardzej zaawansowanym
> oprogramowaniem na świecie bo z nimi pracujesz, kompletnie ignorując
> multum innych dziedzin które ten poziom komplikacji CADów zjadają na
> śniadanie i popija Fotoszopem.

Oczywiście, że kod może być potwornie skomplikowany,a nakład pracy
znacznie większy niż przy projektowaniu modelu samolotu.
Masz słuszność w 100%. Nie wyobrażam sobie, jak zakodowany jest zwykły
google, a co dopiero jakieś szachy, czy algorytmy pogodowe. Kosmos w
zakresie programowania i zapewne wymaga to ponadprzeciętnych
kompilatorów i maszyn (że o programistach nie wspomnę). Tak jak
napisałeś - nie znam się na tym, ale i tak jestem przekonany, że linux
sprawdzi się tam znacznie lepiej niż widnows.
Pisałem przecież, że gruby kawałek kodu to nie problem dla linuxa.

Jest też raczej oczywiste, że do przykładu wybrałem coś, na czym choć
odrobinę się znam. Ciężki program, to np: Catia, ale i zwykły SolidWorks
potrafi zaleźć za skórę wymaganiami. Wyobraź sobie, że do Solida są
nawet specjalne, dedykowane drivery do kart grafiki (które zresztą W10
tak fajnie potrafi podmienić przy aktualizacjach na lepsze - nowsze -
własne). Kiedyś były też zalecane konfiguracje sprzętowe dla
konkretnych wersji SW, ale nie wiem czy nadal jest to praktykowane.

Miłego.
Irek.N.

do góry

2021-04-06 o 13:37 +0200, Irek.N. napisał:
> A co się dzieje, gdy 2 gości poprawi tą samą część niezależnie i bez
> wzajemnej świadomości dzieła?

Następuje kolizja. W przypadku zwyczajnego kodu VCS zazwyczaj jest w
stanie wykonać merge (chyba że goście zmienili dokładnie te same
linijki), ale w przypadku blobów nic z tego: VCS tylko zapyta, czyja
wersja jest ta "dobra", a tę kolizyjną nadpisze - wówczas obie wersje
będą dostępne w historii, ale "aktualna" (tzw. trunk lub head) będzie
tylko jedna, tego kto ostatni nadpisał.

Mateusz

do góry

Pan Irek.N. napisał:

> Nie wyobrażam sobie, jak zakodowany jest zwykły google,
> a co dopiero jakieś szachy

"Zwykły google"! Mało jest takich, którzy sobie tego "zwykłego" gugla
potrafią dokładnie wyobrazić. Choć z drugiej strony ja też kiedyś nie
wyobrażałem sobie (nie tylko ja), jak komputer może grać w szachy.
Aż mnie ograł taki, co miał 16kB RAM. Patrz literatura uzupełniająca:
paradoks Moraveca.

--
Jarek

do góry

On 06/04/2021 13:37, Irek.N. wrote:
>> 2. użytkownicy muszą pamiętać o tym, by regularnie odświeżać swoje
>> lokalne wersje (svn up) aby zaciągnąć ewentualne zmiany, oraz wysyłać
>> swoje własne zmiany kiedy tylko są gotowe do użytku (svn commit).
> Użytkownicy muszą pamiętać. Pani od j.polskiego mówiła coś o czymś
> takim... jak to się nazywało... oksykort..... wiem! oksymoron :)

To nie jest prawda. Tego sie nie robi w normalnej pracyz VCS. Podczas
prawidłowej pracy masz do czynienia ze *stabilnym* stanem projektów nad
którymi *nie* pracujesz. Są jakimś rodzajem snapshotu z jakiejś chwili
czasowej i są stabilne, koledzy którzy nad nimi pracują są w innych
"branchach" i ich praca nie wpływa na twoją, nie widzisz ich zmian.

Jedyny moment kiedy taka synchronizacja jest potrzebnam to sytuacja:
"Andrzej, faktycznie nie było tutaj otworu, już dodałem, ściągnij sobie
nowszą wersję tej obejmy".

Ale nawet wtedy pobieranie poprzez "synchronizajce/odświeżanie" jest
zazwyczaj niepoprawne. Poprawnie przenosi się na nowszą wersję źródeł i
merguje zmiany ze starego brancha. Ma się pod kontrolą dokładnie co się
zmienia, w jakiej wersji, jakie zmiany. Cała magia VCSa polega własnie
na tym że punkty synchronizacji są *kontrolowane* a nie chotyczne, jak
przy pracy na jednym NASie.

Praca w VCS wymaga samodyscypliny, inaczej kończy się bałaganem i pracą
wszystkich na jednym trunku gdzie opisana sytuacja z synchronizacją ma
miejsce i niewiele się to rózni od Twoejgo NASu. Dlatego w firmie jest
lider który ma słowo decydujące w organizacji pracy i tępi zachowania
niezgodne ze sztuką. Taki lider to ktoś z doświadczeniem, jesli nie ma u
was takiej osoby to VCS nie da wam żadnych zalet bo będziecie go używać
i tak jak upierdliwego NASa. Tak się kończą wszystkie eksperymenty,
nawet u programistów, bez nadzoru osoby która wie jak tego używać. VCS
jest silnie logiczny a to wbrew lenistwu i na pęczki widuje przykładów
złego użycia które powoduje tylko idityczne problemy, nic nie
rozwiązując. Generuje też często zachowania "not-invented-here" czyli
utrzymywane przez lata błedne wzroce, generujące tylko wiecej problemów,
ale za to obrobione masą workaroundów (jak ten katalog z datą i "backup").

> A co się dzieje, gdy 2 gości poprawi tą samą część niezależnie i bez
> wzajemnej świadomości dzieła?

Jest konflikt. I wtedy własnie okazuje się jakie CADy są dziadowskie.
Nie potrafią trzymać swoich danych w plikach tekstowych więc
uniemożliwiają merge. Ogólnie esencją systemów kontroli wersji bez
locka, jest właśnie to merge, bazujące na jakimś formacie pliku i
znajomości kontekstu (nie musi być tekstowy, ale nietekstowych nie
widuje). Innymi słowy, jeśli masz do czynienia z plikami binarnymi,
jedyną mozliwością rozwiązaniu konfliktu jest wybranie albo rybki albo
akwarium. Programiści mogą wybrać rybki w akwarium bo ich źródło jest
plikiem mergowalnym, tutaj tekstowym.

Zaznaczam jednak, że taka sytuacja "na jednym NASie" powodowała by takie
same konsekwencje. Przypuszczma więc że te "konflikty" u was nie
wytępują bo pracujecie z blokowaniem zapisu przez innych. Nie
doświadczacie konfliktów bo likwidujecie je "otwarciem jednego w R/W i
wyjściem na papierosa".

VCS jest raczej utopią w przypadku CADów, musiano by zakopać kilka
pokoleń ludzi od tych narzędzi i napisać wszystko na nowo, aby był choć
cień szansy na zrobienei tego dobrze.

Choć VCS może się przydać w jakiejś okrojonej wersji do innych tasków
lub jako wspomaganie produkcji.

do góry

On 2021-03-27 12:52, Adam wrote:

> _Uwaga:_
> Po instalacji systemu (bez względu, czy to windows czy linux) na
> uruchomionej maszynie wirtualnej z belki maszyny wirtualnej wybierasz menu
> [urządzenia/Zamontuj obraz płyty z dodatkami gościa].
> Następnie instalujesz te dodatki - są to sterowniki do środowiska
> wirtualnego. Bez tego maszyna wirtualna może chodzić bardzo wolno, ze
> softwarowym rysowaniem ekranu, bez dostępu do peryferiów.
> Jest to ważne, aby zainstalować.

a czy guest additions przypadkiem nie są free tylko do użytku
niekomercyjnego?

--
Pozdr.
Michał

do góry

2021-04-06 o 15:53 +0200, heby napisał:
> Ale nawet wtedy pobieranie poprzez "synchronizajce/odświeżanie" jest
> zazwyczaj niepoprawne. Poprawnie przenosi się na nowszą wersję źródeł
> i merguje zmiany ze starego brancha.

Wszystko ok, ale tutaj mowa o plikach binarnych, stąd moje założenie
pracy w uproszczonym trybie "wszyscy na jednym trunku", bo żadne merge
nie wchodzą w grę.

> Praca w VCS wymaga samodyscypliny, inaczej kończy się bałaganem i
> pracą wszystkich na jednym trunku gdzie opisana sytuacja z
> synchronizacją ma miejsce i niewiele się to rózni od Twoejgo NASu.

Różni się o tyle, że użytkownik nie zdoła wykasować czegoś innym,
wszyscy mogą sobie oglądać projektu lokalnie (czyli szybko), a wszelkie
zmiany są zapisane w historii i można bez problemu pobrać wersję
projektu XYZ z października 1999, jeśli tylko jest taka potrzeba.

> Dlatego w firmie jest lider który ma słowo decydujące w organizacji
> pracy i tępi zachowania niezgodne ze sztuką. Taki lider to ktoś z
> doświadczeniem, jesli nie ma u was takiej osoby to VCS nie da wam
> żadnych zalet bo będziecie go używać i tak jak upierdliwego NASa.

Tu też nie mogę się do końca zgodzić - doświadczenie nie jest
niezbędne, jeśli człowiek jest poważny, z głową i zada sobie kilka
podstawowych pytań dot. workflow pracy przed ustaleniem firmowych
reguł. Irek wydaje mi się spełniać te kryteria z nawiązką.

> Choć VCS może się przydać w jakiejś okrojonej wersji do innych tasków
> lub jako wspomaganie produkcji.

Moja nieśmiała sugestia rozpatrzenia pracy z VCS była ukierunkowana
właśnie na "wspomaganie produkcji" - tj. zastąpienie NASa rozwiązaniem
NASopodobnym, w którym ludzie pracują wyłącznie lokalnie i mają dostęp
do historii projektów.

Mateusz

do góry

On 06/04/2021 16:15, Mateusz Viste wrote:
>> Ale nawet wtedy pobieranie poprzez "synchronizajce/odświeżanie" jest
>> zazwyczaj niepoprawne. Poprawnie przenosi się na nowszą wersję źródeł
>> i merguje zmiany ze starego brancha.
> Wszystko ok, ale tutaj mowa o plikach binarnych, stąd moje założenie
> pracy w uproszczonym trybie "wszyscy na jednym trunku", bo żadne merge
> nie wchodzą w grę.

Wiec oni to teraz mają. W postaci NASa. Jesli VCS miałby w czymkolwiek
pomóc, to w tym aby można było miec własne kopie lokalne i jakąs
automatyzację kopiowania.

>> Praca w VCS wymaga samodyscypliny, inaczej kończy się bałaganem i
>> pracą wszystkich na jednym trunku gdzie opisana sytuacja z
>> synchronizacją ma miejsce i niewiele się to rózni od Twoejgo NASu.
> Różni się o tyle, że użytkownik nie zdoła wykasować czegoś innym,
> wszyscy mogą sobie oglądać projektu lokalnie (czyli szybko), a wszelkie
> zmiany są zapisane w historii i można bez problemu pobrać wersję
> projektu XYZ z października 1999, jeśli tylko jest taka potrzeba.

Mam wrażenie że mnie j wiecej podobne argumenty padną w przypadku NASu ;)

>> Dlatego w firmie jest lider który ma słowo decydujące w organizacji
>> pracy i tępi zachowania niezgodne ze sztuką. Taki lider to ktoś z
>> doświadczeniem, jesli nie ma u was takiej osoby to VCS nie da wam
>> żadnych zalet bo będziecie go używać i tak jak upierdliwego NASa.
> Tu też nie mogę się do końca zgodzić - doświadczenie nie jest
> niezbędne, jeśli człowiek jest poważny, z głową i zada sobie kilka
> podstawowych pytań dot. workflow pracy przed ustaleniem firmowych
> reguł. Irek wydaje mi się spełniać te kryteria z nawiązką.

No wiec widywałem kilka firm gdzie wdrażano subversion czy git. Zawsze
wychodziło to źle. Inzynierowie (programiści w szczególności) maja
tendencję do nie czytania instrukcji i do "not-invented-here" a
najbardziej do przenoszenia starych zwyczajów na nowe rozwiązania. Bez
lidera od VCS ani rusz. Jedna z firm przez dobre dwa lata nie wytworzyła
ani jednego brancha w repo svn. "Za dużo roboty i potem sa tylko
problemy z konfliktami" jak się dowiedziałem on jednego z tamtejszych
hackerów (wypinającego pierś do orderu za optymalizację produkcji).
Utknęli w swoim minimum lokalnym, a tradycja rzecz święta. A metodyka
używania była dokładnie odwrotna od zaleceń wieć i efekty odwrotne od
optymalnych.

Nie, absolutnie nie dotykać VCS bez kogoś kto ma o tym pojęcie...

do góry

W dniu 06.04.2021 o 15:53, heby pisze:
>> A co się dzieje, gdy 2 gości poprawi tą samą część niezależnie i bez
>> wzajemnej świadomości dzieła?
>
> Jest konflikt. I wtedy własnie okazuje się jakie CADy są dziadowskie.
> Nie potrafią trzymać swoich danych w plikach tekstowych więc
> uniemożliwiają merge. Ogólnie esencją systemów kontroli wersji bez
> locka, jest właśnie to merge, bazujące na jakimś formacie pliku i
> znajomości kontekstu (nie musi być tekstowy, ale nietekstowych nie
> widuje). Innymi słowy, jeśli masz do czynienia z plikami binarnymi,
> jedyną mozliwością rozwiązaniu konfliktu jest wybranie albo rybki albo
> akwarium. Programiści mogą wybrać rybki w akwarium bo ich źródło jest
> plikiem mergowalnym, tutaj tekstowym.

I tutaj "NAS" jak Ty to piszesz rozwiązuje problem. Jak ktoś otworzył i
pracuje nad detalem, to nikt inny nie otworzy tego detalu inaczej jak
RO. Nie ma więc sytuacji, w której oboje coś poprawili niezależnie.

>
> Zaznaczam jednak, że taka sytuacja "na jednym NASie" powodowała by takie
> same konsekwencje. Przypuszczma więc że te "konflikty" u was nie
> wytępują bo pracujecie z blokowaniem zapisu przez innych. Nie
> doświadczacie konfliktów bo likwidujecie je "otwarciem jednego w R/W i
> wyjściem na papierosa".

Nie opłaca się, czasami z krzesła się nie wstanie w czasie gdy z WS2019
projekt się otwiera :) Ale metodę podałeś dobrą, tak z grubsza to
działa. Dobrze działa, ale wymaga aby było jasno powiedziane kto za co
odpowiada.

> VCS jest raczej utopią w przypadku CADów, musiano by zakopać kilka
> pokoleń ludzi od tych narzędzi i napisać wszystko na nowo, aby był choć
> cień szansy na zrobienei tego dobrze.
>
> Choć VCS może się przydać w jakiejś okrojonej wersji do innych tasków
> lub jako wspomaganie produkcji.

Chyba nie skorzystam na tym. Nie widzę korzyści.
Miłego.
Irek.N.

do góry

> "Zwykły google"! Mało jest takich, którzy sobie tego "zwykłego" gugla
> potrafią dokładnie wyobrazić. Choć z drugiej strony ja też kiedyś nie
> wyobrażałem sobie (nie tylko ja), jak komputer może grać w szachy.
> Aż mnie ograł taki, co miał 16kB RAM. Patrz literatura uzupełniająca:
> paradoks Moraveca.
>

Patrząc na ten paradox, oraz na to, że "zwykłe google" nie ma żadnej
motoryki, za ile będziemy mówili do niego wujku? Za 5 lat?

A co do szachów, to w czasach gdy komunikację międzyludzką rozwiązywało
się stawiając modulowaną nośną na... powiedzmy 73MHz, grywało się w
szachy. Z tym, że ja nigdy nie grałem, ale miałem C-128, a ono grało
nieźle! :)

Miłego.
Irek.N.

do góry

Pan Irek.N. napisał:

>> "Zwykły google"! Mało jest takich, którzy sobie tego "zwykłego" gugla
>> potrafią dokładnie wyobrazić. Choć z drugiej strony ja też kiedyś nie
>> wyobrażałem sobie (nie tylko ja), jak komputer może grać w szachy.
>> Aż mnie ograł taki, co miał 16kB RAM. Patrz literatura uzupełniająca:
>> paradoks Moraveca.
>
> Patrząc na ten paradox, oraz na to, że "zwykłe google" nie ma żadnej
> motoryki, za ile będziemy mówili do niego wujku? Za 5 lat?

Już niektórzy mówią o nim wujek. A o motoryce (w kontekscie paradoksu
Moraveca) pisze ciocia Wiki. To uproszczony opis, z tą motoryką.

W połowie lat 70 prognozowano, że jednym z zadań, które komputery opanują
najszybciej, będzie tłumaczenie tekstów. No bo słownik to taka niezbyt
gruba książka, podręcznik do gramatyki też -- co tu więcej trzeba, usiąść
i natrzaskać trochę kodu w fortranie. Dawano na to kilka lat, że niby koło
roku 1980 wszyscy tłumacze pójdą z torbami. Nie poszli. Za to przyszedł
Moravec i powiedzał swoje.

Jarek

PS:
Mamy rok 2021. Wujek coś tam próbuje tłumaczyć, ale zwykle bełkocze tak,
jakby się schlał na imieninach u cioci.

--
Gdzie ojca nie ma, tam Pismo mówi: wuja słuchał będziesz. Jest to jakby
rodzicielska władza, której grzech, Rochu, się sprzeciwić... Bo nawet
i to zauważ, że kto się ożeni, ten snadnie ojcem być może; ale w wuju
płynie ta sama krew, co w matce.

do góry