AJenbo skrev:Det handler ikke om hvor dan Apache eller Nginx rammer OS'et, men om Apache og Nginx rammes af udateret 3 part biblioteker (openssl) fra OS'et. Det hjælper sandkasser ikke en døjt, det er næsten omvendt. Desuden er AppArmor allerede i brug i Ubuntu i dag. Forskellen med Snappy er at det bliver nemmere at fjerne software og rulle systemet tilbage til et tidligere stadie, men det hjælper jo ikke i mit eksempel hvor der er brug for at komme frem og ikke tilbage.
Det afhænger vel af om den nyeste pakke ikke fungere korrekt, så er det da rart at man nemt kan hoppe baglæns
AJenbo skrev:Der med er det nok ikke godt at losse ansvaret for at opdatere 3 parts biblioteker over på dem, det resultere nok ikke i en støre strøm af pakker hvis de ikke er i stand til at klare det med .deb i dag, hvis Snappy kræver mere arbejde fra deres side, og slet ikke hvis de nu skal lave både .deb og Snappy pakker for at undersøtte både Debian og Ubuntu.
Det afhænger vel af hvordan man laver snappy pakker.. og om .deb kan konverteres til snappy eller hvorledes det fungere..
* Linux Ubuntu 16.04 64 bit - I3, 4 GB DDR3 1600Mhz, intel 7260AC dual band wifi, Samsung EVO 850 250 GB SSD. - Abook Z510 * Asustor nas: AS-202T, AS-202TE & AS-604T https://linuxviden.dk
Blueeyez skrev:Det afhænger vel af om den nyeste pakke ikke fungere korrekt, så er det da rart at man nemt kan hoppe baglæns
Ja det er fint, men det er ikke den problem stilling vi snakker om.
Blueeyez skrev:
AJenbo skrev:Der med er det nok ikke godt at losse ansvaret for at opdatere 3 parts biblioteker over på dem, det resultere nok ikke i en støre strøm af pakker hvis de ikke er i stand til at klare det med .deb i dag, hvis Snappy kræver mere arbejde fra deres side, og slet ikke hvis de nu skal lave både .deb og Snappy pakker for at undersøtte både Debian og Ubuntu.
Det afhænger vel af hvordan man laver snappy pakker.. og om .deb kan konverteres til snappy eller hvorledes det fungere..
Hvad mener du om hvordan man laver snappy pakker? At skulle lave 2 pakker må nødvendigvis være mere arbejde end kun at skulle lave 1, også selv om den ene kan konvateres til den anden, hvilket jeg ikke regner med da princippet i hvad der pakkes med snappy nettop adskilder sig fra .deb.
AJenbo skrev:Der med er det nok ikke godt at losse ansvaret for at opdatere 3 parts biblioteker over på dem, det resultere nok ikke i en støre strøm af pakker hvis de ikke er i stand til at klare det med .deb i dag, hvis Snappy kræver mere arbejde fra deres side, og slet ikke hvis de nu skal lave både .deb og Snappy pakker for at undersøtte både Debian og Ubuntu.
Det afhænger vel af hvordan man laver snappy pakker.. og om .deb kan konverteres til snappy eller hvorledes det fungere..
Hvad mener du om hvordan man laver snappy pakker? At skulle lave 2 pakker må nødvendigvis være mere arbejde end kun at skulle lave 1, også selv om den ene kan konvateres til den anden, hvilket jeg ikke regner med da princippet i hvad der pakkes med snappy nettop adskilder sig fra .deb.
Der kommer et program der hedder deb2snappy - det skulle være meget nemt at få et program i deb pakke-format med rekursive afhængigheder til en snappy pakke uden afhængigheder (eller meget få snappy afhængigheder, såsom GTK+ 3, kde-libs, OpenSSL etc). Snappy afhængigheder skal såvidt jeg forstå ikke kunne være rekursive.
Jeg har også læst at Canonical vil lave fuld-automatisk/maskinel oversætning af alle deb programmer i Debian arkiverne, så vi får ikke færre programmer med snappy pakkerne. En bunke high-performance build-computere er billig i drift i forhold til bare 1 programmør.
/Lars
Jeg er Software ingeniør (Diplomingeniør) i Informationsteknologi og indlejede systemer, hvor indlejrede systemer er computer (microcontroller) + elektronik i for eksempel et TV, en router, en vaskemaskine og den slags
