Miért szállít az Ubuntu ma is ősrégi csomagokat?

Ubuntu Linux

Csak egy példa:

Maven 3.0, kiadás dátuma: 2010-10-08 ( https://maven.apache.org/docs/history.html )

Akkor haladjunk visszafelé az időben:

http://packages.ubuntu.com/vivid/maven
http://packages.ubuntu.com/utopic/maven
http://packages.ubuntu.com/trusty/maven
http://packages.ubuntu.com/precise/maven

De nézzük minden probléma gyökerét:

https://packages.debian.org/jessie/maven
https://packages.debian.org/wheezy/maven

Szóval elmondhatjuk hogy mavenből aminek a 3.0-s verziója majdnem 5 évvel ezelőtt jött ki, 4 ma is támogatott ubuntu verzióban és 2 debian verzióban érhető el mint legfrisebb csomag.
Pénteken egy kollegának segítettem mavent telepíteni a legfrisebb Ubuntun (tudjátok, a systemd -es). Hát még PPA sem volt hozzá. És így magyarázzam el neki miért olyan klafa a Linux.

Mindeközben: https://maven.apache.org/docs/history.html
https://www.archlinux.org/packages/community/any/maven/

Kérem kapcsolja ki.

  • 4417 megtekintés

( Hevi v | 2015. 05. 18., h – 00:16 )

Ubuntu HQ, napjainkban:

- Te, nem kene frissiteni a Maven-t újabbra?
- Mé'? Van?

Es arrol tudsz, hogy hanyan hasznalnak meg mindig windows xp-t, azert, mert amire hasznaljak, "jo az ugy" statuszu?

Akinek a maven fontos, az ugysem fogja a gyarit hasznalni, mindenki masnak meg... Ne hasznaljon ubuntut, vagy rakja fel kezzel.

Amugy, nekem olyan aranyos egy os-el kapcsolatban a "ma sem valtok" kijelentes. Minek valtana az ember operacios rendszert, ha az, amit pont hasznal, kielegiti az elvarasait? Foleg a windows-windows, linux-linux vonalon belul maradva?

"mindenki masnak meg... Ne hasznaljon ubuntut, vagy rakja fel kezzel."

Ertem a problemadat, meg ugy ahogy meg is ertem (bar szerintem picsogas, de "irigylem a szabadidod", de kerlek, probald meg az erto olvasast. Nem csak 3-4 szo tavolsagig ertelmezz egy mondatot.
Vagy! Ted azt. Ahogy gondolod. Es ahogy jobbnak erzed.

Én a Go-t a honlapjukról letöltött csomagból telepítettem. A popularity-contest által készített listában nincs is benne, gondolom csak a csomagkezelőkkel feltelepített csomagokat nézi. Vagyis ez a felmérés nem (mindig) valós adatokat ad: hiszen ha régi egy csomag, akkor egyesek feltelepítik hozzám hasonló módon, ami nem látszik a listában.

Egyébként kösz az infót, eddig nem tudtam, hogy van ilyen listájuk.

( locsemege v | 2015. 05. 18., h – 00:36 )

Ubuntu != Linux. És most nem a szűkebb, kernel értelemben, hanem mint disztribúció, mint GNU/Linux értem. Megnéztem, szégyenszemre a másfél hét múlva megjelenő Fedora 22 is csak 3.2.5-öst szállít, de ez mégsem olyan régi, mint a panaszod tárgya.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( haspokember | 2015. 05. 18., h – 11:33 )

A Maven egy Java program. Egy csomo JAR fajlbol all, es nehany shell szkriptbol, amelyek megfeleloen parameterezve elinditjak a JVM-en a megfelelo JAR-t.

A JVM egy mikrokornyezet, ami nem fugg az operacios rendszer tobbi osszetevojetol. Vagyis teljesen mindegy, milyen libc-d, X-ed, GTK-d stb. van, ha a JVM verzioja megfelel, a JAR fajljaid mukodni fognak (termeszetesen van kivetel).

Innentol teljesen mindegy, mi van az Ubuntu repoban, ugyis kezzel vagy a helyi rendszergazda / devops altal biztositott modon fogja mindenki telepiteni a JVM alapu programjait.

Ui: amugy ha egy tar.gz fajl kicsomagolasahoz es a PATH frissitesehez segitsegre van szukseg, az mar regen rossz...

"ha a JVM verzioja megfelel" ott kezdődik, hogy az esetek többségében az sem felel meg, de jelentkezzen, aki mondjuk éles rendszert üzemeltet OpenJDK-val. A Java a legtöbb operációs rendszeren eléggé alul támogatott dolog, szerintem semmi meglepődni való nincs ebben.
Linux: inkább csak ártanak a csomagokkal
*BSD: nincs tapasztalatom, de nem tudom elképzelni, hogy rózsás a helyzet
OSX: na hagyjuk, talán a legrosszabb
Windows: nincs

Egyébként ezeknek a problémáknak keltették életre a gvm, jenv és egyéb hasonló projekteket.

-
Konténerezett Hadoop és Cassandra cluster konfigurálása - első rész

Az OpenJDK 7 és 8 a referencia implementáció*, semmiféle veszélyt nem érzek benne hogy éles rendszert telepítsek rá AMENNYIBEN a fejlesztés és tesztelés is ugyanezen a verzión ment.

*még a verziója is csont ugyanaz mint az oracle jdk, az utóbbit úgy buildelik hogy fogják a megfelelő openjdk -t és hozzáteszik a browser plugint, a java web start implementációt, néhány fontot és egyéb dolgokat. szerver oldalon nem tudok olyasmiről, ami bármiben is különbözne.

--
arch,debian,openelec,android

„ az utóbbit úgy buildelik hogy fogják a megfelelő openjdk -t és hozzáteszik a browser plugint, a java web start implementációt, néhány fontot és egyéb dolgokat. ”

Erre tudsz forrást mutatni?
Vagy bármi hivatalosat, hogy miben más az Oracle féle implementáció, mint az OpenJDK.
Vagy, hogy mit is jelent, hogy „referencia implementáció”?

Néhány hónapja utána akartam olvasni ennek, de néhány ködös humbugon kívül nem sokat találtam. Hálás lennék!
Üdv,
--
blogom

"It is very close - our build process for Oracle JDK releases builds on OpenJDK 7 by adding just a couple of pieces, like the deployment code, which includes Oracle's implementation of the Java Plugin and Java WebStart, as well as some closed source third party components like a graphics rasterizer, some open source third party components, like Rhino, and a few bits and pieces here and there, like additional documentation or third party fonts. Moving forward, our intent is to open source all pieces of the Oracle JDK except those that we consider commercial features such as JRockit Mission Control (not yet available in Oracle JDK), and replace encumbered third party components with open source alternatives to achieve closer parity between the code bases."

https://blogs.oracle.com/henrik/entry/java_7_questions_answers

--
arch,debian,openelec,android

( laja | 2015. 05. 18., h – 12:05 )

Ha problémát okoz egy friss maven telepítése, akkor tényleg nem érdemes linuxot használni. Meg úgy egyáltalán IT területen dolgozni :)

Hint: nincs mit installalni. Nincs hova installalni. Nincs msi, ahogy nincs kulon windowsos / unixos valtozat.

Teljesen rad van bizva, hogy a home konyvtaradbol, a /usr/local/bin-bol, a /opt-bol, vagy akarhonnan mashonnan futtatod a shell szkriptet. Vagy csinalhatod ugy, mint a Leiningen: bemasolod a szkriptet valami PATH-ban levo helyre, es a JAR-okat meg a home konyvtaradba letoltod kulon (a Leiningen automatikusan megcsinalja ezt neked).

Sot, meg a shell szkript sem kotelezo, csak kenyelmi funkcio. Ha valamiert neked ugy jobban tetszik, kidobhatod a gyari szkriptet es irhatsz masikat. Vagy felparameterezheted kezzel a JVM-et.

Olyan ez, amikor jpegPhoto AD attribútumot akarok az AD-ba, hogy egyes alkalmazottak képei jelenjenek meg az outlookban/akárhol, és nem lehet, mert nincs az AD grafikus felületre kivezetve, nem lehet kitallózni, csak powershellben lehet bűvészkedni, de legalább ott se triviális, mert még az ldapmodify-hoz sincs sok köze.
Ellenben legalább az AD browserben ezután sem látszik, csak az outlookban... :D
--
PtY - www.onlinedemo.hu, www.westeros.hu

A sírva röhögés és a felháborodás közül nem választom egyiket se: az a probléma hogy az ubuntu szállít egy 5 éves mavent "hogy megoldjon egy problémát" -> ezt a problémát rosszul oldja meg, ezért úgyis kézzel rakod fel. Így inkább ne is legyen maven benne.
hint: rendes distrok ebből is képesek normális verziót szállítani.

--
arch,debian,openelec,android

A gond az, hogy az Ubuntut a mezei felhasználók mindennapos szükségleteihez igazítják (netezés, netezés, netezés), így ne várd el, hogy a fejlesztői környezetek topon legyenek. A Maven csak egy a sok elmaradott csomag közül. Viszont a Firefox legalább naprakész. ;)

--
Coding for fun. ;)

( janoszen v | 2015. 05. 18., h – 12:12 )

Tudom, hogy ez nem oldja meg az eredeti problemat, de egy Javat rendszeresen bizgeralo ismerosom szerint az a legjobb, ha sajat Java telepitest (+ hozza valo cuccok) szallitasz a szoftvereid melle, ugyanis a csomagos verzional erdekes dolgok tudnak eloallni ha ne adj Isten ket szoftver van a gepen amihez kulonbozo verzioju Java kell. Nem megoldhatatlan problemak, de foglalkozni-kell-vele problemak. Ez persze megfoszt a security updatektol, szoval valaszthatsz, melyik citromba szeretnel harapni. :(

--
Pásztor János
Üzemeltető Macik

( szabi2k v | 2015. 05. 18., h – 12:43 )

Amikor a precise megjelent (12.04), akkor a legujabbat adtak hozza 3.0.4, ami megjelent: 2012-01-20.
Amikor a trusty megjelent (14.04), akkor adtak hozza a 3.0.5-ot, ami megjelent 2013-02-23, tehat 1 eves volt csak.

S azota senkit se erdekelt, hogy frissitse, tehat a precise-t leszamitva ma kb 2 eves maven van az ubuntu repo-kban.

Regebbi kiadasok (tobbnyire) csak biztonsagi frissiteseket kapnak, ugyhogy ha a kiadasig nem kerul bele friss verzio, akkor mar kesobb se fog.

De akkor is az az 5 az inkabb max 2. :)

A tamogatott az azt jelenti, hogy jonnek hozza biztonsagi frissitesek. S azok is tobbnyire csak backport formajaban, uj verziok nem kerulnek fel. (tudtommal az egyeduli kivetel ez alol a firefox, valamint az lts-ek megkapjak az xorg+kernel-t)

Amugy itt egy friss ppa:
https://launchpad.net/~timothy-downey/+archive/ubuntu/maven3

(nem tudom, hogy mukodik-e, de hirtelen ez kerult)

szerk: igaz, hogy csak trusty+precise-hez talal a ppa... na mindegy :)

( PtY | 2015. 05. 18., h – 12:57 )

Mavenék aztán frissek... 2014.dec: java 6 -> Java 7 - pont időben.
Érdemes lenne azt is megnézni, hogy milyen ismert sérülékenységek vannak 3.0 fölött, amik nincsenek javítva, hátha ez a kerékkötője az update-nek.
--
PtY - www.onlinedemo.hu, www.westeros.hu

( Gregor | 2015. 05. 18., h – 18:45 )

Még két példa: a GHC 5 , a Go "csak" 3 verzióval van lemaradva.

( arpi_esp v | 2015. 05. 18., h – 19:03 )

az semmi, de a 12.04 lts ubuntuban a clamav-bol is valami tobb eves van meg mindig :(
nesze neked security updates

( uid_720 | 2015. 05. 18., h – 20:40 )

vivid (cli-mono): complete Mono runtime, development tools and all libraries [universe]
3.2.8+dfsg-4ubuntu4: amd64 i386

Ma a 4.0.1.34-nél jár a tudomány.

Fuszenecker Róbert

( KoGa v | 2015. 05. 19., k – 14:27 )

Tipikusan olyan csomag (de szerintem rengeteg ilyen van) aminek semmi keresnivalója a disztribben, simán ki lehetne venni, az ember úgyis olyan verziót rak fel magának, amit akar.
(Lásd még: Java, Tomcat, stb.)

( uid_19334 | 2015. 05. 19., k – 16:09 )

mert sok a csomag és kevés a karbantartó

Akkor ismétlem, talán nem volt érthetp:

Ha nem tartják karban, és egy ősrégi verzió van fent, ami még bugos is lehet, és minden itteni szakértő azt mondja, hogy inkább tegyem fel külső forrásból, akkor egyáltalán miért van becsomagolva, minek van egy olyan verzió, amit épeszű ember, aki használni is akarja, úgyis lecserél?

Most már elegem van abból a mentalitásukból, hogy "milyen szuperek vagyunk, mindenhez van csomag", miközben ezer éves, karbantartatlan, nem hivatalos, stb. verzióik vannak. A snappys-unitys-mires marháskodásuk helyett/mellett kicsit takaríthatnának is végre.

Bocs, kikívánkozott, ekkora értetlenkedéssel ritkán találkoztam még itt.

És ezzel nem is mondtál hülyeséget. Ha kertre van szükséged, vegyél kertes házat, bár próbálkozhatsz azzal, hogy panelban a nyolcadikon az egyik szobában kertészkedsz.

Arról nem is beszélve, hogy a Linux disztribúciók nagyjából ugyanazon alkalmazás bázison és kernelen épülnek fel. Éppen az ilyen dolgokban különböznek, mint például csomag verzió. Akkor miért is ne éljünk a lehetőséggel, ha van megoldás? Vagy csak a szokásos, csináljunk problémát abból, ami nem probléma?

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

"És ezzel nem is mondtál hülyeséget." Veled ellentétben? :)
Ha van 1000 ok arra, hogy panelban lakj, de kell kert, akkor 1 ok vs. 1000 ok szerinted merre billenti a mérleg nyelvét?
Ha Fedora kellene neki, azt használna, és nem lenne ez a thread.
--
PtY - www.onlinedemo.hu, www.westeros.hu

Akkor eldöntöd, hogy a kerttel kapcsolatban mennyire fontos, hogy az a közvetlen közeledben legyen, hogy az épület, miben élsz, az a kerttel egy telken legyen-e, vagy sem, és ezt követően eldöntöd, hogy jó neked a panel+hobbikert x kilométerre, vagy mindenképp kertes házra van igényed.
Kertes ház és belvárosi bulinegyed legyen öt percre otthonról az nem fog menni. Vagy csak nagyon kemény kompromisszumok árán.

Megmondom, miért.

TF, telepítettél anno egy 8.04 LTS-t, és használod is a csomagot, ám az adott verzió pont elegendő, upgrade-elni nem akarod.
A szállítónak (Ubuntu) nincs érdekében - oka most irreleváns - karbantartani a csomagot, mert az igény rá minimális.
Jogos a kérdés: eltávolíthatná.

Ám, mivel egy újabb repoban már nem lenne benne, upgrade-kor törlődne az a csomag, amit X ember még talán(!) használ.
Azaz, amikor szépen mész fel a létrán ->10.04 ->12.04 ->14.04, egyszer csak eltűnne az alkalmazás.

Ok, azt is aláírom, hogy nem mindenki frissít állandóan. Nem hiszem, hogy indok lenne az, hogy kevesen használják arra, hogy töröljék, ám arra igen, hogy ne frissítsék.

--
PtY - www.onlinedemo.hu, www.westeros.hu

Nem tudom, az adott csomagot sem ismerem, de azt elképzelhetőnek tartom, hogy azon alkalmazások/daemonok, amikre kisebb az igény, de van támogatottabb alternatívájuk, az upgrade esetén lecserélődik, akár egy ütköző csomag - és még az is lehet, hogy a régi konfigot felparse-olják, átalakítják az új csomagnak megfelelőre, majd mentik, így kb. fel sem tűnik (pl. rsyslog->syslog-ng csere).
Csak megpróbálok ésszerű ideológiát találni rá, hogy mi miatt lehet ez így - amúgy az igazi okát persze nem ismerem :)
--
PtY - www.onlinedemo.hu, www.westeros.hu

1. Ubunturól van szó.
2. A lucid után távolították el, még jóval a Debianosok döntése előtt
3. http://oprofile.sourceforge.net/news/ - nem halott.

De próbálkozásnak nem volt rossz. Amúgy meg nem igazán sikerült megfognod a lényeget: az oprofile arra volt példa, hogy bizony, távolítanak el csomagokat az ubuntusok, ezzel az erővel az ősrégi, szakadt mavenjüket is kidobhatnák, nem érv, amit fentebb írtak.

1.: Talán hasonló okból mint a Debiánék.
2.: ...vagy a Debiánék hasonló okból mint az Ubuntuék
3.: Nem írták hogy halott, csak hogy rég volt belőle új maintainer upload, a maintainer nem reagált a hibajegyekre, kevesen használják, elavult(?) libektől függ, és ráadásul az új kernelekkel sem működik - mármint a csomagban lévő verzió, a 2009-es, kb.

Azaz a maintainer magára hagyta, a szárnysegédjét se izgatja nagyon hogy mi lesz a csomaggal. Őszintén szólva nem csodálom hogy eltávolították, mert az eltávolítással kevesebb baj van, mint megtartani az amúgy használhatatlan és nem karbantartott csomagot. Pláne ha van helyette más(*) és nem is nagyon függ tőle semmi.

Nem tudom hogy a Maven milyen, gondolom ha hasonlóak lesznek a körülmények, hasonlóan járnak el azzal is.

*) Bár ez a van helyette más nálam már kiverte a biztosítékot az lxc - openvz kapcsán.

"Ha nem tartják karban, és egy ősrégi verzió van fent, ami még bugos is lehet, és minden itteni szakértő azt mondja, hogy inkább tegyem fel külső forrásból, akkor egyáltalán miért van becsomagolva, minek van egy olyan verzió, amit épeszű ember, aki használni is akarja, úgyis lecserél?"

http://giphy.com/gifs/the-office-thank-you-michael-scott-1Z02vuppxP1Pa

--
arch,debian,openelec,android

( linelord | 2015. 05. 19., k – 20:45 )

a java platform fuggetlen, csak meg sajat magaval sem kompatibilis... :D