Bekend idd en de (ham)vraag is of je dit soort BigTechs zo wilt supporteren.
Ik niet iig.
Het kan echt wel beroerder dan UbuntuâŠ
Het gaat dan niet om Ubuntu - als balans in de stroom van het bestaan - maar dat een
Oracle op deze wijze faciliteert zonder dat zij zicht geeft op (de) redenen. Het is als de eendenfuik die er lieflijk uitziet.
De term voor âaltijdâ is omkleed met allerlei valkuilen en opties die geen zekerheid bieden voor een vrij(elijk) gebruik. OCFT is prima om eens mee te âexperimenterenâ en jezelf te openbaren aan Orcale maar ik zou onder geen beding iets van (eigen)waarde of betrouwbaarheid daar neerzetten.
Ik geef toe dat Oracle het meeste biedt voor de gewillige onderwerping.
Ook is er een âcatchâ dat de set-up na een maand wort afgesloten en de gebruiker dan wat ingewikkeld moet doen om die weer (klonerend) in de lucht te krijgen. Ook het feit dat je een Creditcard moet tonen om gratis gebruik te maken van hun diensten, doet mij fronsen.
Er zijn verder wel meer vergelijkbare âoffersâ:
Allemaal veel van hetzelfde waar je voortdurend over je schouder moet kijken of je niet wordt bekeken om bestolen te worden van je ingebrachte energie.
Zowel bij de naam Oracle als Ubuntu als xrdp gaan mijn nekharen recht overeind staan, die titel is voor mij een soort worst-case scenario 
Inhoudelijk kan ik niets over de video zeggen omdat ik youtube geblokkeerd heb.
De grote vraag is of je hier de klant of het product bent âŠ
Waarom (tegen) xrdp ?
Inzake video, mis je niets en vertelt kritiekloos hoe iemand klikkerdeklik, de boel aan de gang kan krijgen en remote de grafische desktop kan openen. Technisch niet heel spannend.
//â//
Met Ubuntu kan ik mij voorstellen dat de visie en religie van Canonical inmiddels gaat neigen als een Bigtech. Kan mij inmiddels ook wel ergeren hoe zij (Canonical) steeds weer de bakens verzet om haar commerciële (support)belangen te voorzien van kansen.
Het moge verder duidelijk zijn dat je met zg free-for-(n)ever, per definitie het product bent. Al was het maar dat gebruikers van die faciliteiten geheel âbelangeloosâ, die omgevingen testen en het bedrijf zo voorzien van gratis (test)data en aandacht.
Met wat moeite kan je natuurlij de boel wel uitnutten en dan wordt het de vraag wat het doel dan daarmee is. Of is dat het bedrijf - lekker pûh - dwarszitten of geeft het daadwerkelijk een meerwaarde ?
Doe mij wat denken aan moeizaam âkrakenâ van streams die inhoudelijk niet veel meer bieden dan opgeleukte ârommelâ en de autonnomie/creativiteit van mensen zelf ongeveer uitschakelt.
Bedankt voor de omschrijving van de video.
Omdat het een implementatie is op basis van reverse engineering van een proprietary protocol. X2go kent bijvoorbeeld soortgelijke functionaliteit en is gebaseerd op linux-native protocollen.
Specifiek in de context van dit topic: Een ssh sessie is vele malen efficiënter dan een complete desktop krijgen daar een terminal in openen.
Mijn antipathie tegen ubuntu zit hem in het elke keer doorduwen van controversiële keuzes. Denk aan de spyware amazon lens, sowieso hun hele unity desktop, recent weer snaps, enz.
Op een desktop heeft het misschien af en toe nog een use case, naar mijn mening is het totaal ongeschikt voor server gebruik doordat zelfs support op hun LTS versies niet zo lang is als de naam suggereert.
1 like
Hmmm xrdp is meer dan reverse engineering en is/geldt inmiddels op Linux als voorportaal om remote desktop te doen. Op Linux is poort 3389 simpel een poort wat dan ook gebruik kan worden om andere communicatie zoals VNC doorheen te tunnelen. Handig omdat veel âorganisatiesâ de rdp poort doorlaten. Zelf tunnel ik remote-sessies door poort 22, is ook een stuk handiger en van nature - encryptie - veiliger.
Ik ben met je eens dat het RDP protocol zelf omgeven is met mist en waanzin van een partij die zich de communicatie wil toe-eigenen.
Die âsnapâ-technofie is idd ook iets waar ik mij boos over maak. âSnapâ - containers voor functies - technologie is voor mij niets anders dan dat partijen weer proberen te forceren dat dingen weer hun eigen blackboxen (kunnen) worden.
Dat bv FireFox op Ubuntu 22.04 als SNAP-container draait, is wmb onbegrijpelijk en geen goed nieuws hoe de Ubuntu toekomst eruit ziet.
In toenemende mate zul je zien dat applicaties met bijbehorende libraries als container samen beschikbaar gesteld worden.
omdat dit onderlinge afhankelijkheden verminderd, waar die er strict genomen ook niet zijn.
Snap/OpenShift/andere containers zorgen voor meer stabiele diensten. Ondanks de nadelenâŠ
Als een applicatie container A lib X v 1.0 bevat, en de volgende container B lib X v1.1 de volgende (C) lib X v1.3 heeft dan komt lib X dus 3 keer voor op je systeem.
Die kunnen allen op een systeem werken terwijl de applicatie in A niet met lib X v1.1 overrweg kan, terwijl App C niet met lib X v1.0 overweg kan. Zonder de containers kunnen app A, B en C niet op een systeem draaien.
En wat Oracle met Ubuntu te maken heeft weet ik niet, maar Oracle (een andere leverancier van diensten a la AWS, en data opslag, en databases) heeft een compleet eigen distro die aardig lijkt op RedHat naast Solaris (ex Sun). Terwijl Ubunto een merk van Canonical is.
Op het lijstje van overnames door Oracle staat ook geen Canonical, wel allerlei bedrijven in het advertentie brokerage spectrum.
(Daar is Oracle een veel meer op de achtergrond optredende grootmacht).
1 like
Het idee achter de opzet van snaps is op zich ook niet heel verkeerd (al hoewel ik het download-een-binary-van-random-plek-en-draai-in-een-container gedrag wat je bij veel containerplatformen ziet zeer dubieus), het is meer dat ubuntu weer een eigen oplossing knutselt voor iets waar al andere oplossingen voor bestaan en dat ze (voor zover ik het ken) het alleenrecht op de distributie van snaps willen hebben ⊠en tadaaa, daar is je vendor lock-in.
1 like
De reden voor containers zijn evident maar zorgen wel voor afgesloten units die een eigen leven gaan vertonen.
Je zult je dan eerst moeten verdiepen in die specifieke deelomgeving voordat er enig inzicht ontstaat hoe het daar(in) is opgebouwd, laat staan dat je als buitenstaander makkelijk in staat bent dat te vermaken.
Voor ontwikkeling van âLinuxâ vindt ik het een slechte zaak omdat het zorgt voor rotzooi omdat makers hun eigen wereld gaan (ver)maken met daaruit voortvloeiende eisen.
Dat dan bv een Chromium of FireFox beter draait - en sneller zonder overleg veranderd kan worden - in een eigen container, is vooral omdat de browserbouwer dan zichzelf de handen vrij heeft gemaakt ipv hun product te laten werken op de basis.
Een Firefox âvraagtâ dan aan Canonical om in Ubuntu voortaan in een dichtgetimmerde SNAP-container te mogen draaien en Canonical vindt dat dan OK.
Containers, blokkenbouw en virtualisatie komt ook weer met een prijs dat het als totaal, meer resources vraagt dan het stabiel (moeten ver)delen van een eco systeem.
Dat grootmachten zich gaan bemoeien met vercommercialiseren van Linux is niet omdat ze âonsâ goed willen doen maar omdat het hun meeliftend een platform geeft om hun missie aan âonsâ op te leggen.
Idem met een Canonical die imo vooral lijkt te gaan kijken naar uitnutten van Debian en zich dan geroepen voelt om elke 6 maanden met een release te komen.
Daarmee ook zorgend dat discussies over backward compatability, zinloos zijn en idd de behoefte voedt om voortdurend te moeten upgraden.
Hierbij moet ik zeggen dat door de invloed van grootmachten ook mooie dingen zijn ontstaan om OpenSource ook qua tooling, een boost geven.
Probleem dat ik hierbij heb dat het individu geen zeggenschap (of inzicht meer) heeft op het eindreaultaat.
De zg opensource-broncode is vaak vakkundig ontdaan van elk inzichtgevend commentaar waarmee de inhoudelijke discussie over werking wat zinloos wordt.
In het beste geval is er een PCM systeem dat verteld dat iets is gedaan zonder dat gebruikers daar nog in- of bij betrokken (konden) zijn.
Welke van de 200+ basissen?.. RHEL, Gentoo, Debian, Ubuntu, Arch, Slitaz⊠met verschillende versies etc. etc. etc.
En sommigen zijn rolling versions waar uberhaupt alleen een dynamisch profiel bestaat.
Virtualisatie komt met aardig wat overhead, maar containers zijn meer een âchrootâ op anabolen.
( er is geen aparte kernel, libraries worden voor zover mogelijk gedeeld met de host etc.).
Alle omgevingen moeten updaten, ook gentoo, ook arch, ook debian⊠dat heeft niets met grootmachten te maken.
Open source was de norm tot ongeveer 1978 toen er in er een paar garageondernemers Microsoft begonnen en dat hele uitwisselen van broncode een gevaar voor de vercommercialisering van de software vormde.
In de begin/medio jaren 80 is daarop GNU & Free Software Foundation opgezet om een licentie die OpenSource beschikbaar & mogelijk maakte in een door CopyRights en Patenten afgeschermde wereld.
Doel oa. een eigen OS (GNU Hurd). Maar om te beginnen Compilers, Libraries etc. En toen kwam Linux als kernel beschikbaar voordat GNU Hurd maar iets kon betekenen.
Ik wil je niet teleurstellen maar bij Closed source is het vaak niet beter gesteld. Dat is meer een discipline van de schrijver van de code.
Daarnaast de code zelf is (mits goed neer gepend) ook vaak documentatie.
Bij Open-source code kun je veelal zelf contact opnemen met de bouwer⊠en je verbeteringen aanmelden.
Vaak wordt gevraagd om een âpatchâ en source code aanpassing compleet aan te leveren.
(YMMV, het is afhaneklijk van de project eigenaar).
1 like
Updaten is wat anders dan dingen niet meer doen en dan als bepalende instantie - hier Canoncal - dwangmarig toepassen. En ja daar zijn die garagisten mee begonnen.
Dat hoeft niet altijd het geval te zijn. Ik maak zelf containers op maat door simpelweg een regulier geĂŻnstalleerde versie van een pakket te nemen en met tools als ldd dependencies te vinden en die met zân allen in een container te zetten. Ik doe dat zelf op gentoo maar dat zou met iedere distro moeten kunnen. Zeker met wat complexere software is dat in het begin een uitzoekwerk, als je dat eenmaal goed automatiseert heb je er daarna weinig omkijken meer naar.
Sowieso is het probleem van specifieke libraries nodig hebben een probleem wat veroorzaakt is door binaries te distribueren. Door zelf te compilen/linken tegen de libraries op jouw systeem verdwijnt het probleem vanzelf. Het enige wat dan nog overblijft is dat er soms updates van libraries zijn waar dusdanig grote veranderingen in zitten dat ze niet compatible zijn, maar over het algemeen kunnen die ook gelijktijdig op een systeem bestaan.
Als ik naar gedrochten als systemd en pulseaudio kijk vraag ik me ook af of de âgrote distroâsâ het beste voor hebben met gebruikers, beiden staan volgens mij haaks op de best practices in de open source/linux/unix gemeenschap.
Dat is dan ook een belangrijk voordeel (en soms een uitdaging) van Gentoo. 
Nogmaals, vanuit de leverende ontwikkelaar is het evident dat die (graag) containert, ook qua eigen beheersbaarheid en dan minder hoeft te âkijkenâ naar comptabiliteit omdat die zelf grotendeels de eigen omgeving managed. Been there en have my T-shorts high & lowlevelâŠ
EĂ©n van de redenen dat FireFox zogenaamd aan Canonical âvroegâ om hun product voortaan te mogen containeren dat âzeâ sneller aanpassingen konden doen. Dat dit dan weer in SNAP-modus is, en (niet zo) toevallig ook van Canonical en past in een lucratief shopmodel, is ook een discussie waard.
Ook vanwege tegenstrijdige belangen die imo geen goed doen. De openheid, ook als het niet goed past in andersmans rommelarij, is wmb er niet mee gediend omdat er geen generieke discussie meer is (en dus hoeft te zijn) over wat beter of anders kan.
Maar goed, jij en ik zullen daar niets aan veranderen omdat Canonical dat als BigTech bepaalt. Ik probeer zelf zoveel mogelijk dat snap-gebruik in mijn omgeving(en) tegen te gaan o.a. door af te stappen van Ubuntu aan haar derivaten. Ik wil in staat blijven om actief zicht te houden op de source.
Dan moet je naar een source based distro zoals Gentoo.
altijd vana de source bouwen.
1 like
Oeps, door een vakantie tussendoor komt mân reactie wat aan de late kant. Maar ja, beter laat dan niet
Ik snap de voordelen voor de ontwikkelaar best. Het leveren van een complete container geeft dan ook direct de verantwoordelijkheid bij die ontwikkelaar om zân dependencies up-to-date te houden. Dat zal bij grote jongens als mozilla wel goed zitten (denk ik), maar bij de ontwikkelaar drie-hoog-achter heb ik er een stuk minder vertrouwen dat die ook gedurende jaren na de laatste release van zijn eigen programma de dependencies nog bijhoudt.
Doet die ontwikkelaar dat niet goed dan komt het probleem terecht bij de (eind)gebruiker: Die denkt up-to-date te zijn en heeft nog steeds potentieel kwetsbare software in gebruik. Sowieso is het container-model een stuk minder transparant naar de gebruiker, wie geeft aan welke versies van welke dependencies allemaal in de container meegebakken zijn?
En dan deze situatie: Stel je weet dat van een bepaalde library een specifieke versie kwetsbaar is, hoe ga je bepalen in welke containers die allemaal zit?
Containers zijn leuke dingen, maar dit zijn naar mijn mening nadelen die maar te gemakkelijk vergeten worden onder het mom van gemak.
2 likes