težave z deployem na linux distribucije

Večina "vendorjev" (Oracle, IBM in podobni) svoje reči stlači v /opt.

Bistvo Linux distribucij je, da uporabniki svobodno odločajo o tem, kaj se na njihovih računalnikih dogaja, zato je prav, da tisti, ki pred uporabniki skrivajo izvorno kodo in s tem onemogočajo izboljšave, tudi malce trpijo. Če izdaš izvorno kodo, bo vsaka resna distribucija bodisi sama poskrbela za vključitev, bodisi se bo našel prostovoljec, ki bo to počel, ker ceni tvoje delo.

Jaz najraje vidim, da je navaden tar paketek, ki ga extractaš kamor hočeš in zaženeš.
Tako kot ima Mozilla Firefox na uradni strani.

win64 je 7. okt 2018 ob 22:10 izjavil:

Me zanima bolj podrobno tvoj usecase. Ker če ne ravno upravljaš s sistemskimi stvarmi si lahko precej dela olajšaš s statičnim linkanjem knjižnic ali pa uporabljene knjižice distribuiraš zraven programa.
Še celo Linus je bolj naklonjen takemu načinu(če ga prav razumem).

Recimo, da sta ta dva načina ekvivalentna, ker aplikacija s seboj vleče vse knjižnice, ki jih potrebuje za svoje delovanje.

Aplikacija je odposlana, stranke jo imajo nameščene, potem pa ...

Nekdo mora spremljati razvoj vseh teh knjižnic, da lahko opazi, če ima katera izmed njih hrošča, ki vpliva na delovanje aplikacije.

Sistem upravljanja s kodo moraš imeti dovolj dobro dorečen in dosledno izvajan, da boš lahko ponovno prevedel in povezal aplikacijo X v natančno tisti verziji, ki je bila razposlana ven in ne 10 verzij in 5 dodatkov (featurjev) kasneje, ker je to pač trenutna verzija kode. Tudi za to mora nekdo skrbeti.

Razvojno okolje moraš imeti takšno, da lahko narediš t.i. "repeatable build", ker ne želiš ustvarjati novih napak. To seveda vključuje vse od prevajalnika naprej, če se koda prevaja in seveda takratne verzije vseh tistih knjižnic, ki jih ni potrebno ali pa dovoljeno spremeniti.

Ker pri vsakem prevajanju sprememb dobiš nov paket, ki se morda tudi drugače obnaša (pa ne samo v delu, kjer je bila odpravljena ena napaka), je dobro imeti za to kodo teste. Unit in end-to-end, sicer ne veš če je kaj drugega odpovedalo.

Statično povezovanje je odlično iz vidika zagotavljanja ponovljivosti delovanja. Ni pa zastonj ali rešitev vseh težav, še zlasti ne, kadar pride do varnostnih napak. Recimo knjižnica, ki je potrebna za prikaz JPEG slik, je statično povezana v tvojo aplikacijo. Torej bo tvoja aplikacija na sistemu tudi potem, ko bodo nameščeni popravki za knjižnico, še vedno potencialno nevarna.

Jupi.

Za ekipe, ki jim manjka zgoraj opisane delovne discipline, je bolje, da ostanejo pri dinamičnem povezovanju, kjer za nameščanje vseh njihovih odvisnosti skrbijo večje ekipe ljudi, ki jih tiste odvisnosti bolj zanimajo. Cena, ki jo plačajo za to "lenobo", je sicer ta, da jim bo aplikacija pri nekaterih strankah "odletela", ko se bo namestilo posodobitve, bo pa njihova programska oprema še vedno bolj varna, kot pa Ford Pinto.

Kar se tiče mojega pavšalnega komentarja o "IT" podjetjih ... me prav zanima kolikšen delež podjetij v Sloveniji ima te osnove proizvodnje programske opreme vsaj koliko toliko urejene. Ko sem pred leti odhajal, je bilo meni znano stanje bolj bogo.