On 31-Mar-21 08:22, heby wrote:
>
> 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.
>

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ć
*.inne_nie_mniej_debilne_rozszerzenie ;-)

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

do góry

On 31/03/2021 09:34, Piotrek wrote:
> 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 ...

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:
1) nie da się inaczej, mimo testów, bo to cady czyli typowe dziadostwo z
lat 60
2) ludzie pracujący z cadami na komputerach się nie znają i nie chcą
znać, traktując innowacje jako zagrożenie dla ich pracy
3) są powody poza konkursem, których nie poznamy w tym wątku (np.
własciciel - hacker)
4) brak woli zmian

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

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

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

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

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

do góry

On Wed, 31 Mar 2021 01:46:21 +0200, Adam <a...@p...onet.pl> wrote:
> Chyba, że masz na myśli pliki danych, jako takie (czyli *.dat i
> *.k??).

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



> A czy przypadkiem ten Netware nie był na RG58, a samba na RJ45?

To było na pewno na rj45

--
Marek

do góry

On Wed, 31 Mar 2021 08:24:22 +0200, heby <h...@p...onet.pl> wrote:
> 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

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

--
Marek

do góry

On 31/03/2021 10:24, Marek wrote:
>> 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
> No przecież pisałem, że lokalny lepszy, dlaczego miałby być gorszy??

U Irka gorszy. Zastanawia mnie dlaczego ;)

do góry

On Tue, 30 Mar 2021 17:28:17 +0200, heby <h...@p...onet.pl> wrote:
> Monolityczny kernel nie będzie nigdy w stanie uruchamiać
> bezpiecznie
> *obcych*, binarnych sterowników.

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

--
Marek

do góry

On 31/03/2021 10:43, Marek wrote:
> 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ę.

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.

> Ale widzę, że szybciej  możnaby z tego
> zrobić  w pełni sprawny mikrokernel niż monolit....

Może nie warto robić...

https://en.wikipedia.org/wiki/L4_microkernel_family

do góry

On 31-Mar-21 09:57, heby wrote:
> Ale ja wiem o tym, mnie zastanawia geneza początku takich problemów z
> CADami i wybór takigo rozwiązania.

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

>
> 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:
> 1) nie da się inaczej, mimo testów, bo to cady czyli typowe dziadostwo z
> lat 60

Ototo!

> 2) ludzie pracujący z cadami na komputerach się nie znają i nie chcą
> znać, traktując innowacje jako zagrożenie dla ich pracy

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

> 3) są powody poza konkursem, których nie poznamy w tym wątku (np.
> własciciel - hacker)
> 4) brak woli zmian

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

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

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

do góry

On Wed, 31 Mar 2021 11:13:22 +0200, heby <h...@p...onet.pl> wrote:
> Może nie warto robić...
> https://en.wikipedia.org/wiki/L4_microkernel_family

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

--
Marek

do góry

On 31/03/2021 11:34, Marek wrote:
>> Może nie warto robić...
>> https://en.wikipedia.org/wiki/L4_microkernel_family
> Tak wiem... ale tutaj chodzi tylko o taką dziecięcą fascynację zrobienia
> własnej zabawki ;).

Doskonale to rozumiem ;)

do góry