A Red Hat bejelentést tett a RHEL forráskódjának elérhetőségéről, a downstream disztrók vizsgálják, hogy ez mennyiben érinti őket

AlmaLinux, CentOS, Fedora, Red Hat, Rocky Linux

A Red Hat a minap bejelentette, hogy szűkíti a Red Hat Enterprise Linux forráskódjának elérhetőségét:

CentOS Stream will now be the sole repository for public RHEL-related source code releases. For Red Hat customers and partners, source code will remain available via the Red Hat Customer Portal.

A Red Hat által kiadott RHEL forráskódokból építkező downstream disztribúciók, mint például az Alma Linux, jelenleg vizsgálják, hogy a Red Hat bejelentése miként hat ki a működésükre. Amint a kiértékelés megtörtént, tájékoztatást ígértek ...

 

( trey | 2023. 06. 22., cs – 09:21 )

No need to panic!

Debian/Ubuntu vonalon mozgóként stratégiai nyugalommal figyelem a fejleményeket ...

trey @ gépház

( _ventura_ v | 2023. 06. 22., cs – 09:23 )

Erre kíváncsi leszek, bár ahogy nézem, lehet visszamenni a gyökerekhez (Debian)  ...

Fedora 41, Thinkpad x280

( bennyh | 2023. 06. 22., cs – 09:26 )

Na akkor mit is csinál az IBM? :D 

NagyZ egy másik topikban védte a cég böcsületét, de valahogy megint egy RH balhé van szem előtt :D

Színes vászon, színes vászon, fúj!

Kérem a Fiátot..

( buga v | 2023. 06. 22., cs – 10:16 )

Ezzel kapcsolatban az az érzésem, hogy nem a Rocky/Alma, hanem sokkal inkább az Oracle "élősködése" váltotta ki ezt a lépést.  Gondolom úgy voltak vele, hogy játszani a CentOS Stream is elég, ahol meg az effektíve Red Hat által összerakott cucchoz (security) supportot akarnak, azt vegyék a Red Hattől.  A hosszú távú hatásaira kíváncsi leszek, hogy ezzel végülis ügyfeleket nyernek-e vagy veszítenek inkább.

A Red Hatnek van hozzáadott értéke, különben nem alapulnának rajta disztrók. Mint ahogy a Canonical is hozzátesz ahhoz, hogy a sok-sok opensource szoftverből legyen egy egységes rendszer. Ahogy a Debian is, ahogy az Arch is.

Az, hogy ennek a 10 éves támogatásáért a Red Hat pénzt kér, egy üzleti döntés. Nem muszáj használni a Red Hatet, de azt sem szabad elfelejteni, hogy nem azért fizetsz, mert fogják az opensource cuccokat, és becsomagolják. Sokkal több munka van mögötte.

Az Oracle ezt a munkát megspórolja, és a Red Hat support fölé ad egy újabb réteget, pénzért.

 

Olyan ez, mintha te újságíró lennél, aki sok-sok forrásanyagból dolgozva egységes cikkeket állít össze (ezt csinálja a Red Hat) és mások átírva a szerző nevét, leközölnék a munkádat (ezt csinálja az Oracle).

"A Red Hatnek van hozzáadott értéke, különben nem alapulnának rajta disztrók. Mint ahogy a Canonical is hozzátesz ahhoz, hogy a sok-sok opensource szoftverből legyen egy egységes rendszer. Ahogy a Debian is, ahogy az Arch is."

Most ezzel azt akarod bizonyítani, hogy aki GPL szerint jár el, az élősködő? Ha holnap a Debian dönt úgy, hogy paywall mögé teszi a forráskódot, hogy a Canonical ne "élősködjön" rajta, szerinted az is rendben van?

Akkor vállalja fel a Red Hat, hogy nem szeretne ebbe a szabad szoftver bizniszbe többet részt venni, zárja be azokat a kódokat (vagy tegye paywall mögé) amiket bezárhat (pl BSD) és kész. De ismered a mondást, egyszerre szűznek maradni....

LWN most azon megy a diskurzus, hogy vajon ez az EULA:

(g) Unauthorized Use of Subscription Services. Any unauthorized use of the Subscription Services is a material breach of the Agreement. Unauthorized use of the Subscription Services includes: (a) only purchasing or renewing Subscription Services based on some of the total number of Units, (b) splitting or applying one Software Subscription to two or more Units, (c) providing Subscription Services (in whole or in part) to third parties, (d) using Subscription Services in connection with any redistribution of Software....

nem ütközik-e GPL-el, ami pont ennek az ellenkezőjét állítja.

"Az Oracle ezt a munkát megspórolja, és a Red Hat support fölé ad egy újabb réteget, pénzért."

Nem adja pénzért. Supportot vehetsz pénzért, de a termék maga ingyen van.

A RedHat nagyon sok munkát tesz a cuccba azáltal hogy az általuk csomagolt alkalmazásokba visszaportol minden javítást, sőt a kernelbe nem csak javítást hanem feature-kat és akár teljesen új drivereket is. Az RHEL 8-ban lévő 4.18-as kernel simán nagyrészt az 5.14 szintjén van, de 4.18-as ABI-val. Ugyanez igaz sok alkalmazásra példásul az openssh-ra is, az RHEL-ben például a 7.4-es openssh azt jelenti hogy API szinten 7.4, valójában belülről a szoftver közel upstream. Így lehet az ezekre dependáló szoftvert sok évig futtatni úgy, hogy alatta közel naprakész marad a rendszer de mégsem törik el az API. Kompatibilitás tekintetében tehát az RHEL lényegében a Linuxok egyfajta fapados Windowsa. (fapados mert a főverziók között nincs kompatibilitás). Ehhez sok fejlesztő kell és nekik havonta kell bért fizetni, miközben nem csak az RHEL 8 támogatott hanem mellette még másik 2 is. Az RHEL pár száz dolláros "termék" ára csak 1x pénz, tehát havi szinten a RedHat is a supportból él.

RedHat support bevétel - support költség - fejlesztési költség = RedHat profit

Oracle RHEL support bevétel - support költség = Oracle profit

Ez a különbözet lehet a probléma forrása.

"Ehhez sok fejlesztő kell és nekik havonta kell bért fizetni,"

1. Érdekes a Canonical (illetve a Debian akin "élősködnek") meg tudja csinálni ezt, hogy ne kelljen rejtegetnie a source code-ot.

2. Az upstream fejlesztők bérét pedig ki fizeti? És ne gyere azzal, hogy a Red Hat upstream fejlesztőket is fizet, mert az Oracle ugyanúgy contributál pl. a Linux kernelbe. És sok más gyártó is, aki nem részesül a  Red Hat support díjból.

A kernel pedig azért is vicces példa, mert az Oracle Linux alapból saját UEK kernellel települ, aminek a kódja.... tadam a Githubon fent van és bárki számára elérhető.

Kicsit úgy érzem, hogy azt elfelejtitek, hogy azt a sok 10 gigányi RHEL-nek nevezett szoftvercsomag 9x%-át ők is a community-től kapták, majd a hozzáadott értéküket próbálják meg eldugni a világ elől. Ez ami a GPL szellemiségivel (és megkockáztatom a betűjével is) szembe megy.

Az élősködő szót én használtam, de idézőjelbe tettem, mert tisztában vagyok vele, hogy jogilag (és a GPL értelmében is) ezt az Oracle megcsinálhatja.  Én úgy látom, hogy a Red Hat piacát célozták meg azzal, hogy effektíve egy átcsomagolt RHEL-t kapsz olcsóbb supporttal.  Nyilvánvaló ha ez elér egy bizonyos szintet, az a Red Hatnek/IBM-nek nem tetszik, nekem sem tetszene.  Én személy szerint nem látom az Oracle hatalmas hozzáadott fejlesztését, ahol láttam Oracle Linuxot, ott az RHEL compatible kernellel futott, nem UEK-kel.

Amúgy az Oracle csak akkor "barátja" az open source szoftvereknek, ha abból hasznot húzhat.  A Solarist bezárták, miután a Sunt megvették, az open source projektjeik a lassú enyészeté lettek.  A fejlesztéseiket nem licenszelték újra a GPL-incompatible CDDL-ről.  Ez már csak szimpla spekuláció, de szerintem az Oracle Linux is jelenleg a "beetetős" időszaknál jár, amint elér egy bizonyos piaci részesedést, elő kell majd fizessél, legalább a security support csatornákért.  Szinte csalódnék az Oracle-ben, ha nem csinálnának mindenből pénzt, amint megtehetik :)

(g) Unauthorized Use of Subscription Services. Any unauthorized use of the Subscription Services is a material breach of the Agreement. Unauthorized use of the Subscription Services includes: (a) only purchasing or renewing Subscription Services based on some of the total number of Units, (b) splitting or applying one Software Subscription to two or more Units, (c) providing Subscription Services (in whole or in part) to third parties, (d) using Subscription Services in connection with any redistribution of Software....

nem ütközik-e GPL-el, ami pont ennek az ellenkezőjét állítja.

Igen, itt ez lesz a jó kérdés, kíváncsi vagyok, hogy egy ilyen eljut-e a bíróságig, és mit gondol arról, mikor az egyik szerződés olyan alapvető licenszt próbál felülbírálni, amit a szerződő félnek egyébként nincs joga megváltoztatni. 

Mert ha lehet, akkor azért szép nagy workaroundot ad mindenki kezébe, hogy hogyan kell bezárni a kódot, ha meg nem, akkor érdeklődve várom, hogy az RH kitalál-e majd valami mást, amivel kiszanálhatja ezeket az ügyfeleket.

Ugye a nagy kérdés itt az, hogy az SRPM-ek, amiket a Red Hat készít, azok milyen licencűek, miért öröklik meg annak a szoftvernek a licencét, amit becsomagolnak. Hiszen maga az SRPM a metaadatával, a telepítési információkkal, csomagfüggőségi gráffal az más szellemi termék, mint az a szoftver, amit becsomagol RPM-be.

Mert ha bíróság úgy dönt, hogy a Red Hat által előállított SRPM önálló szellemi termék, annak a copyrightja a Red Haté, amely kiadhatja azt nem-GPL licenc alatt is bármikor, hiszen a copyright holder dönti el, milyen licenc alatt terjeszhető a műve.

A Red Hat bármikor elérhetővé teheti az eredeti upstream .tgz-ket, amiből a szoftvert készítette, ez a kötelessége, nem más, a GPL azokra a forrásokra vonatkozik (meg amit patcheltek rajta), és nem az SRPM-re, az az ő saját szellemi termékük, nem terjed rá ki a becsomagolt szoftver licence (legyen az GPL, BSD, Apache vagy bármi).

Ja, ez is igaz, de szerintem ez egy másik szög. Szerintem ők úgy érzik nem derivative, volt is amikor csak a targizit adták. Még a patcheket sem kell külön, elég a megpatcheltet biztosítani. Bár aztán lehet ezzel azért hagytak fel, mert szóltak nekik, hogy mégse jó, mert az. Szerintem nehéz ügy, egyrészt ja, van benne független, másrészt az egész arról szól, hogy a kapott program működjön, szóval én azért hajlanék arra, hogy bizony az lesz az.

Ezzel együtt: azokat biztosan kell, és ettől még az az elméleti kérdés, hogy megtilthatja-e az EULAban, hogy az átadott forrást, aminek a licensze ezt egyébként kifejezetten megengedi, terjessze, áll. (Persze, abból dolgozni downstream sokkal nagyobb szopás) Szerintem józan belátás alapján nem, de hát ugye ez jog :)

Az SRPM-ek terjesztését bármikor megtilthatja, hiszen az az ő szellemi terméke. A Red Hat előfizetők megkapják az SRPM-eket, de nem terjeszthetik. Nem látok ebben semmi GPL-be ütközőt. Amit terjeszthetnek, azt kiadja .tar.gz-ben és kész.

Kiadja azokat a forrásokat, amik amúgy az SRPM-ben vannak (maguknak a szoftvereknek a forrása, amit csomagolnak), aztán hajrá, downstream projektek, lehet saját SRPM-et építeni. Vagy debet. Vagy Pacman csomagot. Vagy Alpine apk-t. Bármit.

Fel kell hozzá építeni a függőségi fát, a metaadatokat, mindent. Ez olyan melót, amit a Red Hat megcsinál, és ez nem az upstream szoftver része.

Ez szerintem attól függ, hogy az SRPM derivative work-e (és hogy a licence mit mond arról*) Értem, amit mondasz, hogy ez a saját szellemi terméke, de GPL pl nem csak arra vonatkozik, ami eredetileg ott volt, akkor kellenek a te ráépített dolgaid, és az én _személyes véleményem_ az, hogy mivel az SRPM az konkrétan az módosítás, ami azért keletkezett, hogy a Red Hat szállítani tudja a szoftvert, szóval szerintem derivative. De mondom, el tudom képzelni, hogy nem az.

*szóval pl az összes LGPLes, MITes, meg a még a tök tudja melyikek SRPMjét nyugodtan bezárhatja.

Ha ez így lenne, akkor az Ubuntu deb csomagoknak is GPL/MIT-nek stb, kéne lenniük, pedig nem az a licencük, hanem tartozik hozzá még ez is:
https://ubuntu.com/legal/intellectual-property-policy
 

Copyright

The disk, CD, installer and system images, together with Ubuntu packages and binary files, are in many cases copyright of Canonical (which copyright may be distinct from the copyright in the individual components therein) and can only be used in accordance with the copyright licences therein and this IPRights Policy.

Az előző kommentedre visszatérve: az SRPM nem módosítja az eredeti szoftvert. Akkor miért lenne derivative work? Az más, amikor a Red Hat belenyúl a forrásba is (lásd kernel patchek).

Mondok egy példát: ha te csinálsz egy olyan scriptet, ami automatikusan flatpakeket csinál egy alkalmazásból, az a script sem lesz az eredeti alkalmazás derivative work-je, az egy saját szellemi terméked. És ezáltal a flatpaket adhatok te pénzért, feltéve, hogy az eredeti alkalmazás forrását (a flatpaket készítő scriptek nélkül) átadod a felhasználóknak. Nem sértesz vele licencet. A te scriptedre te mondod meg, milyen licenc vonatkozzon, hiszen a copyrightja a tied, és nem módosítja az eredeti szoftvert semmilyen formában. Például ha a becsomagolni kívánt alkalmazás GPL volt, a te scripted még lehet zárt kódú. Az más kérdés, hogy magát az eredeti forráskódot elérhetővé kell tenned - de a flatpak építő scriptedet nem.

Másik példa: SQL Server Docker image. Maga Dockerfile, ami építi, publikus és MIT licenc alatt érhető el. De ettől még az alkalmazás zárt marad. A csomagolás az más licenc alatt megy, mint az eredeti alkalmazás.

Alapvetően a mi van, ha linkelni kell baszakodás mentén járt az agyam, de érveid elég erősek, kb meg is vettél. :) Látok azért némi különbséget, főleg az ügyben, hogy a forrást használod újra, vagy a kész izét csomagolod. De tényleg nem tudom megítélni, hogy ez számít-e valamit. Mindenesetre jó lenne, ha valami bíróság mondana ilyesmiről egyszer valóban véleményt, mert van az embernek az az érzése, hogy valahogy többnyire ez ilyen ködszurkálás minden oldalról. Van mindenkinek véleménye....

debianban is mas a license a debian konyvtarra:

orig php fajlok: https://salsa.debian.org/php-team/php/-/blob/debian/main/7.4/debian/cop…

a debian konyvar: https://salsa.debian.org/php-team/php/-/blob/debian/main/7.4/debian/cop…

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

A RedHat eleget tesz az openszopsz licensznek. Minden ott van a CentOS Stream-ben. Minden forrás. Minden tudás. Minden alkalmazott fejlesztése.

Jött egy sakk-matt a klónozó ingyenélőknek.

Mit csinál a RedHat? Időben és térben linkelve létrehoz egy stabil ágat magának a CentOS Stream-ből.

A forrás elérhető, senki ember nem mondhatja, hogy nem elérhető, mert az hazudna.

Le a (piros) kalappal hogy ilyet létre tudott hozni, és az ingyenélők pedig nyalogassák a sebeiket.

A RedHat eleget tesz az openszopsz licensznek. Minden ott van a CentOS Stream-ben. Minden forrás. Minden tudás. Minden alkalmazott fejlesztése.

Ez tényszerűen nem igaz. Eleget tesz, de nem így. A CentOS Streamben nincs ott minden, az nem a konkrét RHEL forrása, a GPL és hasonlók pedig azt írják elő, hogy annak a forrását kell adni, amit szállítasz. Éppen ezért van az, hogy ügyfeleknek és partnereknek továbbra is elérhető a customer portálon keresztül a konkrét forráskód, mert azt tesz eleget a licence feltételeinek. Amit nem ír elő a GPL, az az, hogy publikálni kellene a változtatásokat. Azoknak kell odaadni, akiknek adtad a programot, ha az nem publikusan elérhető, akkor nem kell a forrása mellé. Sőt, a gpl pl explicit megengedi, hogy "You may charge a fee for the physical act of transferring a copy", szóval még az se volna alapvetően ördögtől való, ha chargeolná az ügyfeleket a forráskód letöltéséért. Ezért lehet lelőni a git-et, mert az jogi szempontból csak jófejség. 

A történelem ismétli önmagát, anno asszem az volt, hogy pl a kernel patcheket adták egyben egy targiziben, hogy "akkor szopjatok".

Szerintem simán benne van az is, hogy játszani elég a stream, de ha nagyot akarsz üzemeltetni, akkor tessék szépen megvenni, akkor is (sőt, akkor különösen :D), ha hozzá se akarsz szólni a supporthoz.

Az érdekes kérdés, hogy mivel ugye a centos "helyett" lett ez a töcs tudja, 20 gépig ingyenes cucc, akkor customer vagy-e, mert akkor ugye jár rendesen az a kód, ami fut nálad (ez ugye benne is van a bejelentésben, nyilván nem véletlen). Na most ha mondjuk almáék ebből építenek releaset, akkor bezáródik-e végül ez a kiskapu is, vagy csak szopóágra teszik vissza a communityt? 

( dejo v | 2023. 06. 22., cs – 10:36 )

"Repül a nehéz kő: ki tudja, hol áll meg?
Ki tudja, hol áll meg s kit hogyan talál meg?"

Ok most szűkítik a hozzáférhetőséget és lehet, hogy ettől az Alma, Rocky, stb. tovább tud működni. 
De azért egy hajszálon lóg az a pallos ami bármikor lesújthat!
Szóval menekülő utat kell találni, ami a Debian, BSD mellett nem tudom, hogy még  mi lehet?
Én szerencsére munka szempontjából nem vagyok érintett. Csak a nem rég újra felfedezett otthoni asztali gépen és laptopon használt Fedorától is kezd elmenni a kedvem.
 

Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

Olvastam itt egmonttól ezzel kapcsolatban valamit korábban.

Ez a két hozzászólás lett meg ugyanabból a nehány éves szálból. Érdekelne, hogy az az ő véleménye változott-e, illetve hogy technikailag hogy áll a dpkg + apt vs rpm + yum/dnf (vagy akár rpm + apt4rpm) mára.

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

( csabka v | 2023. 06. 22., cs – 21:41 )

Oracle is tesz bele energiát, lefordította a Redhat által készített forráskódot :D illetve itt-ott módosít rajta ezt-azt. No meg a fantasztikus unbreakable kernelt is csinálja mellé :D

Amúgy meg ha a forráskód alapvetően GPL és Redhat developer licencel hozzá lehet férni legálisan a forráshoz is akkor újrafordítása a GPL kódnak és annak redisztribúciója nem lehet jogi akadály, így valószínű nem változik semmi sem... egyszerűen jelzés értékű volt a lépés, hogy azért ácsi és vegyél anyagilag is részt csúnya Oracle, hogyha piaci előnyöd származik belőle.

Ezt olvastam én is, sőt, állítólag a developer licenc ingyenes. Csűrhetik, a GPL miatt nem zárhatják be a kódját, elérhető kell maradjon, különben licenc-sértésért perelhetik. Eddig sem jófejségből volt a kód elérhető. Pedig megértem a Red Hat-ot, mindenki az Alma, Rocky, Oracle változatot használja az övéké helyett, plusz néhány ember az ingyenes RHEL-t 16 gépig. Így gondolom nem veszik elegen az RHEL-t. Csak hát ez Linux, nem lehet érte zsarolópénzt kérni. Főleg, hogy van egy rakat másik jó disztró is, amik kis hozzértéssel ugyanolyan jól vagy még jobban működnek.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

"Főleg, hogy van egy rakat másik jó disztró is, amik kis hozzértéssel ugyanolyan jól vagy még jobban működnek."

Ezt már nem először írtad le a RedHat kapcsán. Egyet szerintem nem értesz: vannak helyek, ahol a működik-e és a van-e rá support az egymástól teljesen független fontos paraméter. Ráadásul van néhány nagyvállalati pénzes termék, ami explicit meghatározza, hogy neki márpedig milyen szoftverkörnyezet kell. És ha ott nem az szerepel, hogy "some random Linux distro with minimum glibc-x.y.z", hanem az, hogy minimum RHEL 7.13 maximum RHEL  7.26, akkor téged nagyon seggbe fognak kúrni, amikor feltornászod az Arch-ra, de beszarik valami (pl. tényleg van egy hiba a szoftverben, tehát te nem tudod kijavítani) és elmégy az alkalmazás support oldalára a szerződésedet lobogtatva, ők meg jól elhajtanak a halál -ba.

Gondolj ilyen felejthető marhaságra mondjuk, hogy SAP. És ha a vállalatirányítási rendszer hibájával nincs mit kezdeni, mert te meg akartad spórolni a RHEL költségét az Arch terjesztéseddel, akkor nem, nem lesz olyan jó vagy még jobban működő az a Linux. (El tudom képzelni, hogy valahol vesznek SAP-ot RHELre, és mondjuk a tesztkörnyezethez már csak Rocky/Alma jut spórolásból, de normális helyen nem fognak egy kurva jó Debianra ráéhakkolni egy teszt SAP-t. (Illetve de, a vérgőzös rencergarázda az otthoni gépére, és örül neki. De a nagyvállalati környezetbe már az Alma, Rocky se igazán fér bele.)

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

De a nagyvállalati környezetbe már az Alma, Rocky se igazán fér bele.

Hát annó a CentOS-t pont ezért ölték meg mert egyre több nagyvállalat migrálta a sok ezer szerverét RHEL-ről CentOS-re. A Toyota sok ezer szerverének a CentOS-re migrációja volt tán az utolsó csepp a pohárban.

https://www.zdnet.com/google-amp/article/why-red-hat-dumped-centos-for-…

Do you know who uses CentOS? A shortlist includes Disney, GoDaddy, Rackspace, Toyota, and Verizon. Still, dozens of other companies build products around CentOS. These include GE, Riverbed, F5, Juniper, and Fortinet.

Nem pont Arch, van egy rakat másik. Önsupportálni is lehet akármit, akarás kérdése.

Közben egy másik videón azt mondják, hogy nem lehet használni az RHEL forrását. Ha valaki elő is fizet, vagy kivált ingyenes egyéni dev licencet, akkor ugyan hozzáfér a forráshoz, de nem terjesztheti tovább. Ha ez tényleg igaz, az is GPL sértés. Plusz a RH-nak reszeltek.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Önsupportálni? :) Van az a szint, de ha számit az SLA, akkor subscription nélkül elég bátor vállalkozás az OS-t vagy bármi HW/SW-t üzemeltetni. Hová mész ha belefutsz egy bugba vagy ha a lyukas OS-re nem adtak még ki updatet? irsz egy levelet a communitynek? mit mondasz az ügyfélnek? hogy épp nyaral a csomag karbantartója? :)

Van az a szint, de ha számit az SLA, akkor subscription nélkül elég bátor vállalkozás az OS-t vagy bármi HW/SW-t üzemeltetni

Dehogyis! Tök bátran lehet azt, meg kell nézni, hogy mennyi jön be havi díjban, mennyi az SLA sértés esetén fizetendő kötbér, osztani-szorzni, ha az jön ki, hogy ha SLA-sértés miatt kevesebbet kell fizetni, mint amennyi bejön + még a support díjat is megspóroltad ...

Beszélgess kereskedőkkel, levezetik neked! :D :D :D

trey @ gépház

RHEL-essel semmilyen, nalunk volt mindenfele konstrukcio.

Valojaban unsupported kornyezetben is kiment a mernok, csak hat az oradijunk ot eve volt annyi, mint most egy kozepesen jo contractor napidija. Nyilvan aki kulon vett supportot, ott nem neztunk ilyeneket. A beepitett supporttal persze nagyon gyorsan rovidre lehetett zarni egy incidenst, kb. azzal ekvivalens, mint amikor leszeded a garis plombat a gepekrol.

Network/firewall device/sw supporttal vannak tapasztalataim. Gyártót nem írok, több naggyal is...

Legalább 4 emberen kell keresztülmenni mire olyan jön aki tényleg ért hozzá miközben órák/napok/hetek telnek el (szerződéstől SLA-tól stb függően),

Az első előre gyártott kérdéssort tud felolvasni..., illetve ha nem a legutolsó sw főverzión akkor upgradelj ezt mantrázza, ha egyébként a fenn lévő SW verzió latest supportált patchén vagy akkor is.

A második már be tudja tölteni a legyűjtött debug bundle-t valami gyártói tool-ba és ha kiköp valamit fel tudja olvasni....

A harmadik az kb azon a szinten van a termékkel ahol te és jól elbeszélgettek ,de a megoldáshoz nem juttok közelebb,de legalább ő már egy valódi SW/HW fejlesztőnek tudja továbbítani a hibát aki tényleg az adott SW-n/HW-n dolgozik.

Egyszercsak megfixálják a bugot a latest főverzión (vagy releng-et adnak ki hozzá) (amin te nem vagy hiába magyarázod hogy supportált! verzión vagy.)

Mindeközben már rég kikerülted az egész bugot valami workaround-al (amit sokszor egy community forumon javasoltak ahol kínodban feltetted a kérdést),  mert a business nem állhat meg.

Beütemezed a főverzió frissítést és megcsinálod. A bug megjavul ellenben 3 eddig működő dolog romlik el.

 

:)

egy másik videón azt mondják, hogy nem lehet használni az RHEL forrását. Ha valaki elő is fizet, vagy kivált ingyenes egyéni dev licencet, akkor ugyan hozzáfér a forráshoz, de nem terjesztheti tovább. Ha ez tényleg igaz, az is GPL sértés.

A pánikkeltés és a féknyúz az nagyon megy. Olvasd el a Red Hat szerződést és licencet és rájössz hogy nem érdemes hülyeségekkel félrevezetni az embereket.

Dehogy olvasom. Én nem használom. Az ezzel kapcsolatos értekezésekben viszont mindenki leírja, hogy ez így van. Igazából meg én azt mondom, hogy NINCS így, akármit is mond a RH-es szerződés, a csomagok eredeti licencét nem írhatja felül.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Értem, hogy zárójelben volt, de azért éppen feltűnhetett volna, hogy ezt is leírtam: (pl. tényleg van egy hiba a szoftverben, tehát te nem tudod kijavítani)

Erre azt válaszollni, hogy

Nem pont Arch, van egy rakat másik. Önsupportálni is lehet akármit, akarás kérdése.

Ez enyhén nevetséges válasz, és azt mutatja, hogy nem érted, hogy miről írtam.

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?