Ubuntu krijgt nieuwe installer gemaakt met Google Flutter

Canonical gaat de installer voor Ubuntu vervangen. De huidige desktop-installer Ubiquity wordt vervangen door een installer die samen met Google wordt ontwikkeld. Daarvoor wordt de Flutter-toolkit van Google gebruikt.

De ontwikkelaars achter Ubuntu willen de standaard Ubiquity-installer vervangen door een nieuwe, schrijven ze op het Ubuntu-forum. De huidige installer bestaat al sinds 2006. Die werkt nog steeds, maar de makers zeggen dat er al lange tijd geen functionaliteit aan is toegevoegd en dat de code vanwege de leeftijd lastig te onderhouden is.

De code achter de nieuwe installer moet hetzelfde zijn als die van de pas vernieuwde installer van Ubuntu Server. Die heet Subiquity. De makers willen een 'consistente robuuste installatieweergave' voor heel Ubuntu maken, waarbij maar een enkele codebase onderhouden hoeft te worden.

Voor de nieuwe installer wordt gebruikgemaakt van Flutter, Googles toolkit om applicaties te bouwen. Sinds de zomer van vorig jaar is er Linux-ondersteuning beschikbaar voor Flutter, al bevindt dat zich nog wel in de testfase. Canonical zegt dat het samenwerkt met ontwikkelaars bij Google om dat verder uit te bouwen. "We laten dat werk aan de desktop-frontend samenvallen met het werk aan de nieuwe installer", schrijven de ontwikkelaars.

Details over de nieuwe interface voor de tool zijn er nog niet. Voorlopig zijn er alleen nog twee screenshots beschikbaar, die wat functionaliteit betreft hetzelfde tonen als wat de huidige installer doet. De nieuwe desktop-installer moet in de 21.10-release van Ubuntu verschijnen. Die komt in oktober van dit jaar uit. Het gaat dan nog om een testversie. Een definitieve versie voor de lts-releases moet vanaf april 2022 met Ubuntu 22.04 in het OS zitten.

Reacties (64)

[- peter -]

Flutter is een interessante techniek, en ik verwacht er veel van op mobiel. Maar op desktop? En Linux? Zit Flutter niet vast aan Dart? Lijkt me nogal een stap om een installer voor Ubuntu in Dart te gaan schrijven. Al hebben ze t ook over bestaande code, dus ik vraag me af hoe dat gaat werken.

[YopY]

Ik weet het zo niet, het concurreert met meerdere andere libraries (denk dat de grootste React Native is). Het grootste probleem van Flutter is dat het de native UI elementen van iOS en Android nabootst / reproduceert, en ze daarom bij elke update van die native elementen zelf ook moeten uitvogelen wat het doet. Zaken als accessibility, performance, etc komen dan in gevaar.

React Native doet dat anders, die gebruikt wel de native UI componenten. Nadeel daarvan is weer (tenzij dat recent veranderd is) dat de logica in Javascript draait, dat niet dezelfde prioriteit of snelheid heeft als echt native code.

Daarnaast is Dart een vreemde; het was origineel bedacht als een vervanger voor Javascript, met de intentie dat ze een Dart interpreter / runtime in de browser zouden bouwen naast Javascript. De voornaamste reden was volgens mij dat Dart beter te optimaliseren is (runtime) dan Javascript. Maar dat is nooit echt van de grond gekomen, en het alternatief, Dart transpilen naar Javascript, is ook niet echt populair geworden; Typescript is daar veel groter in. Zelfs Angular, een ander project van Google, heeft gekozen voor Typescript ipv Dart (ook nadat ze eerst hun eigen taal gingen bouwen, AtScript oid, omdat Typescript geen annotations ondersteunde).

Lang verhaal kort, het lijkt er op (in mijn beperkte wereldbeeld) dat Dart alleen gebruikt wordt door en voor Flutter op het moment. Zowel Flutter als Dart hebben daarmee volgens mij geen kritieke massa, en modderen al jarenlang wat aan.

Ik vraag me af hoeveel geld of resources Google aan Canonical heeft toegezegd om dit er doorheen te drukken. Strategisch gezien wil je nooit een nieuwe technologie aan je stack toevoegen, want nu moet je om deze installer bij te werken of te onderhouden weer developers hebben die toevallig Dart / Flutter kennen, ipv de UI library / techniek die ze normaliter gebruiken. Toegegeven, die bestaande UI techniek is waarschijnlijk onhandig en niet meer van deze tijd, maar beter dat dan meerdere technologieën proberen te mengen.

[KingFox]

Vooral dat eerste, alle UI componenten zijn inderdaad fake. Om bijvoorbeeld lijsten te renderen, ga je een Flutter-component gebruiken, in plaats van de native iOS/Android component. Goed om te weten is dat deze native componenten vaak performantie-improvements voorzien, zoals bijvoorbeeld cell reusage voor lijsten. Een soort "frame" dat wordt gerendered en de input veranderd, zo kan je heel vlot door grote lijsten scrollen.

Voor elke UI-component, ben je dus afhankelijk van de implementatie van Google. Brengt iOS of Android een nieuwe modal uit in een specifieke OS-versie? Helaas, je bent afhankelijk van Google. Stottert je lijst door een slechte List-implementatie? Google. Voor mezelf is dit echt een belangrijk argument om niet helemaal mee te gaan in dit verhaal. Ondanks dat React Native vaak wel met native components werkt, heerst daar ook een algemene trend om UI-componenten te faken. Wat mij betreft een spijtige zaak. Appcelerator als X-platform tool was op dat vlak wel makkelijker, leunde meer aan bij het native-verhaal, maar had dan weer af te rekenen met een kleine community en vereiste nog veel maatwerk per OS.

Qua performance lijkt Flutter echter wel te winnen van React Native, omwille van de directe rendering engine. Bij React Native wordt je JS-code uitgevoerd, waarbij inperformante reactive code ook de nodige overhead met zich mee kan brengen (Te veel rerenders van componenten bijvoorbeeld).

Andere redenen waarom het gevaarlijk is om voor Flutter te gaan, is omwille van Google. Ook het feit dat je Dart enkel voor Flutter gebruikt op korte termijn, lijkt me niet zo'n heel strak plan.

[2green]

Beetje eenzijdig verhaal.

Je noemt dat het grootste probleem van Flutter is dat het de native UI elementen van iOS en Android nabootst. Maar is juist de grootste kracht waardoor je de nieuwste gui elementen en animaties ook kunt tonen op devices die niet de laatst operating system draaien (dat zijn bijna alle devices trouwens).

De code draait ook niet in een runtime, maar compiled ahead-of-time naar native code, draait erg vlot.

Strategisch gezien introduceren bedrijven trouwens regelmatig (understatement) nieuwe technieken om voordelen t.o.v. concurrenten te verkrijgen. Django/Python zag ik bijvoorbeeld al in grote projecten langskomen toen het maar een paar jaar oud was en flutter inmiddels ook.

Ben zelf trouwens nog niet overtuigd van Flutter en vind het jammer dat ze een taal als Dart hebben gekozen. Maar potentie heeft het zeker wel.

[Reactie gewijzigd door 2green op 22 juli 2024 16:20]

[84hannes]

Strategisch gezien wil je nooit een nieuwe technologie aan je stack toevoegen,

Nooit is een groot woord, maar ik snap je punt. Echter: is de GUI van de installer echt een deel van de stack? Als hij niet (meer) werkt kun je waarschijnlijk nog op een basale cli-versie terugvallen.

[tinustate]

Voor mobiel dev is dart een prima taaltje, het is net java maar wat korter te coderen en zonder reflectie.
Het verwonderd mij ook dat flutter nu op de desktop gaat, had er nog erg weinig over gehoord.
Hier is een link:
https://flutter.dev/desktop
Is schijnbaar alpha, wel gedurfd van ubuntu !

[edit]
Ah! slim van ubuntu, bij installatie is natuurlijk geen GUI kit beschikbaar, voordeel van flutter is dat het geen gebruik maakt van standaard GUI kits, maar er zelf eentje heeft die in het programma mee gecompileerd word. Slim

[Reactie gewijzigd door tinustate op 22 juli 2024 16:20]

[- peter -]

De installer is toch gewoon op de live CD environment? Dus GTK heb je gewoon.

[TheVivaldi]

Bovendien gaat het hier om Ubuntu 21.10 en dat is toch maar een kort ondersteunde uitgave, dus dat de toolkit alpha is maakt niet zo veel uit. En tegen de tijd van de volgende LTS, 22.04, zitten we alweer een jaar verder (even van de feature freeze uitgaande) en dan is Flutter vast al veel verder gevorderd.

[Reactie gewijzigd door TheVivaldi op 22 juli 2024 16:20]

[Glup]

Het wordt geïntroduceerd met Ubuntu 21.10:

Users can expect to try the new installer by the time Ubuntu 21.10 arrives. This should give developers ample time to test the tech “in production” and decide whether it’s robust enough to feature it in the next long-term support (LTS) release.

[TheVivaldi]

Je hebt gelijk, ik heb het gewijzigd. Dank!

[Byron010]

Flutter gebruikt inderdaad Dart, maar ondersteund juist cross/multi platform.

[Apache]

T'is jammer dat ze niet voor kotlin gegaan zijn ipv dart ... daar hebben ze een beetje terug moeten opgraven terwijl kotlin nog volop in de groei zit.

[Mavamaarten]

Klopt, helemaal mee eens. Maar de reden dat ze ervoor kozen is dat het zowel JIT als AOT kan gecompiled worden en compileert naar iets heel low-level. Op zich zou kotlin-multiplatform dat misschien ooit ook kunnen, maar Dart was al zo ver.

[stefanhendriks]

Kotlin wordt toch uiteindelijk bytecode en runt in de jvm? Met alle voordelen van dien? (Jit , etc)

[2green]

Flutter compiled ahead-of-time naar native code, dat blijft een stuk vlotter.

Dit is belangrijk is omdat Flutter de OS specifieke GUI vervangt voor eigen binairies. Kotlin zou minder vlot aanvoelen qua GUI/animaties.

[stefanhendriks]

Java/Kotlin kan je ook AOT'n dus in die zin is het niet speciaal.

Vraag me ook af of het zo heel veel gaat uitmaken voor een installer, maar soit :¯\_(ツ)_/¯

[2green]

Je leest over het relevante deel heen.

Inderdaad net als Kotlin AOT, met als groot verschil dat het 'native code' oplevert. En dat maakt een wereld van verschil.

P.s. kotlin naar native code komt er ook aan, maar dat is nog lang niet af.

[walterg]

Wil dit zeggen dat er standaard telemetry met Google zal worden gedeeld?

Als dat het geval is hoop ik dat het opt-in of met een duidelijke opt-out is.

[PrinsPace]

Ah, ik was al naarstig aan het scrollen naar dit onderwerp in de reacties. Vraag me inderdaad af of Linux gebruikers zitten te wachten op inmenging van een uit de hand gelopen reclamebureau bij de installatieprocedure...

[Omega]

Het is een UI toolkit en volledig vrij. Google doet het over het algemeen prima met hun open source contributies. De vrije software community heeft hier weinig over te klagen.

[84hannes]

Daarbij zit de Linux-kernel, dankzij Android, al vol met Google code. Daarbij heeft Ubuntu Google helemaal niet nodig om je gebruikersdata te delen.

[RL600]

Dat is inmiddels bejaard nieuws en al lang uit Ubuntu. Daarnaast (onder voorbehoud) was het vooral laten zien van een affiliate link van Amazon en was het opslaan van gebruikersdata vrij minimaal.

[84hannes]

Dat is inmiddels bejaard nieuws en al lang uit Ubuntu.

Is het daarmee irrelevant? Ubuntu heeft een geschiedenis waarin ze open source software creëerden die data deelde met derden. Het lijkt me dan ook ongepast om te doen alsof ieder stuk code dat Google ooit heeft aangeraakt dat doet en Ubuntu zelf daarvan vrij de pleiten.

[RL600]

Is het daarmee irrelevant?

Mogelijk ja. Ubuntu heeft qua dataverzamelingen toch echt een betere trackrecord dan Google. Dat je zover moet zoeken in verleden onderstreept dit alleen maar.

Voordat we verder in het luchtledige gaan praten hier een stuk over die affiliate links:

When you perform any search in Unity’s dash, your search terms will be sent to Canonical. Canonical forwards these search terms to third parties, such as Amazon, on your behalf. This means that Amazon can’t tie your searches to you personally

Link: https://askubuntu.com/que...ntu-have-an-amazon-button

En laat me even duidelijk zijn hier. Dit is zeker niet iets waar ik voor ben, verre van! Gure praktijken.

Google helpt uiteindelijk bij een open-source project dus dat zal wel goed zitten. Toch voelt het een beetje "vies" dat Google met z'n verzamelzucht ook hier zich mee gaat bemoeien. Ik denk dat dat ook het punt is waar dit draadje origineel mee gestart is.

[Reactie gewijzigd door RL600 op 22 juli 2024 16:20]

[84hannes]

Je hebt helemaal gelijk dat Google een slechter track record heeft dan Ubuntu. Ik beweer ook nergens het tegenovergestelde maar blijkbaar is het wel zo overgekomen, ik zal het voortaan explicieter neerzetten. Dat gezegd hebbende staan mijn twee uitgangspunten nog steeds.

Toch voelt het een beetje "vies" dat Google met z'n verzamelzucht ook hier zich mee gaat bemoeien.

Jouw verontwaardiging over het tweede deel van mijn post heeft je blijkbaar het eerste deel doen vergeten. Dat trek ik mezelf aan, want het eerste deel was veel belangrijker. Ik zal het hier daarom nog even onderstrepen:

Ruim 5% van de wijzigingen in de Linux 5.10 kernel lijken afkomstig van Google. Als we ons druk moeten maken dat iedere regel code die Google schrijft een middel is om onze data te oogsten dan moeten we ons dus veel meer zorgen maken over de tienduizenden regels code die Google heel recent aan alle Linux-distributies heeft toegevoegd; de installer van een enkele distributie is slechts het topje van de ijsberg.

[Omega]

Het is een UI toolkit, er zit geen telemetry in.

[Verwijderd]

Zie de reactie van @URKb8DvHFz

As ik in de projectmap naar 'google' zoek met:
grep -rnw '/home/username/Downloads/flutter-master/' -e 'google'
krijg ik onderstaande als resultaat(de docs lijken iigv voorzien van analytics);
https://dpaste.com/7BHR49UPE

Ik zie daar verwijzingen naar o.a.

• "Flutter tools over time. See Google's privacy policy: https://www.google.com/intl/en/policies/privacy
• script','//www.google-analytics.com/analytics.js';
• https://developers.google...eld-reference#timingLabel

[Reactie gewijzigd door Verwijderd op 22 juli 2024 16:20]

[URKb8DvHFz]

As ik in de projectmap naar 'google' zoek met:
grep -rnw '/home/username/Downloads/flutter-master/' -e 'google'
krijg ik onderstaande als resultaat(de docs lijken iigv voorzien van analytics);
https://dpaste.com/7BHR49UPE

[Reactie gewijzigd door URKb8DvHFz op 22 juli 2024 16:20]

[Verwijderd]

Delen is niet nodig? De analytics zijn ingebouwd in de javascript bestanden die worden ingeladen bij het opstarten van de installer van het google CDN

[Reactie gewijzigd door Verwijderd op 22 juli 2024 16:20]

[PCG2020]

2023: 'Google neemt meerderheidsaandeel in Ubuntu-ontwikkelaar Canonical'
2025: 'Google trekt stekker uit Ubuntu wegens "tegenvallende financiële resultaten"'

[gepebril]

En dan maar weer forken

[BvZ]

... op tweakers in 2022
"Google trekt stekker uit Flutter toolkit"

[cricque]

Ze gebruiken het zelf ook voor een aantal projecten, zelfde voor golang. Ik hoop van niet sant flutter zie ik wel zitten. Maar je weet maar nooit. Nuja het is niet omdat ze het zelf gebruikn dat ze niet kunnen zeggen we stoppen er mee

[YopY]

Go heeft denk ik veel meer potentie over de lange termijn; het is een back-end taal bedoeld voor grote codebases die voor langere tijd onderhouden moeten worden, precies waar o.a. Google ook mee zit. Ik hoor links en rechts geluiden dat 'oude' Java projecten omgezet worden naar Go met goede resultaten.

Maar binnen Google zijn er nog een aantal andere front-end talen actief; Java sowieso, voor alles dat Android is, maar ook Angular en zelfgebrouwen / vanilla JS omgevingen.

[cricque]

Ja en de snelheid van executie van go is niet te onderschatten. Alleen de error handling is beetje “quirky”, zelf gebruik ik een mix van python, golang en node voor backend en cloud functions, en dat werkt allemaal en alles heeft zijn sterke punten. Een dezer ga il wel eens een app maken met flutter omdat ik toch een projectje heb om een app te maken, niks fancy, maar ideaal om mee te spelen en te leren kennen. Ziet er alvast zeer gemakkelijk uit. Nuja ik werk ook met react, dus react native zou de logische keuze zijn,. Maar eens een keer wat anders kan geen kwaad

[Immutable]

Heel veel Go projecten worden weer omgezet in Rust. lol

[Verwijderd]

and the people rejoiced!

[igrutje]

Een nieuwe tool voor een installer? Ambitieus? Lijkt me lekker, tijdens het installeren of upgraden van je systeem tegen kinderziektes aanlopen.

Hopelijk alleen de frontend nieuw en de backend zwaar leunend op de verouderde / beproefde techniek.

[84hannes]

Een nieuwe tool voor een installer? Ambitieus? Lijkt me lekker, tijdens het installeren of upgraden van je systeem tegen kinderziektes aanlopen.

Als je stabiliteit wilt dan gebruik je naar het schijnt toch de eerste . release van een LTS, dus dit is een mooi moment om kinderziektes te vinden. Vervolgens heeft Ubuntu een half jaar om die ziektes er uit te werken of terug te vallen op de oude installer.

[MiesvanderLippe]

20.04 is LTS en daar zijn ondanks dat de installer update tijdens het installeren de kinderziektes echt verre van uit. Binnen een heel beperkte flow (8 keer enter rammen) gaat het redelijk goed maar bijna alles daarbuiten voelt 'onaf'.

Wat mij betreft is de nieuwe installer meer hip dan functioneel. Ook de gegeven serverrollen duiden daarop. Wat mij betreft te weinig logische standaard packages maar vooral configuraties voor hippe web frameworks enzo.

[Verwijderd]

Canonical heeft de prioriteiten goed op orde, zie ik. Die installatie procedure was echt een probleem en ik ben blij dat ze een betrouwbare partner hiervoor hebben gevonden die vertrouwen geeft in de toekomstige ontwikkelingen van ubuntu.

<zet uw sarcasme meter aan>

[Reactie gewijzigd door Verwijderd op 22 juli 2024 16:20]

[PrinsPace]

[rrrrrrrrr]

Haha, de meter slaat ferm uit zie ik hier.
Ik heb Ubuntu al jaren buitengesloten vanwege hun inmenging met dubieuze derde partijen.

[MiesvanderLippe]

Oh God. Ik kan jullie vertellen dat Subiquity word je niet gelukkig van. Het zit vol met dode eindes, onvolledige configuratie en rare programeerbugs. Configuratie op basis van yaml in een editor als vim of nano is ook echt helemaal niet handig.

Bron: automatisering van installatie gedaan in Server 20.04, en ook in 18.04. Hoe iemand dit ooit door heeft durven zetten naar productie is me echt niet helder.

[TimTurbo2]

Super gaaf om dit te zien! Ik gebruik flutter op mijn werk voor onze multiplatform app en gebruik het zelf ook voor een Linux Task Manager projectje, uit mijn ervaring is flutter velen malen makkelijk om mee te werken en velen malen stabieler dan ding zoals electron of cordova dus om te zien dat de desktop support op Linux waarschijnlijk aanzienlijk beter gaat worden is super!

[1x3xc-12]

Ik was vandaag wat aan het klooien met ubuntu server, ik heb het idee dat de installer tegenwoordig veel ouderwetser is dan vroeger(zeg 2008/2010). Tegenwoordig is het een terminal achtige omgeving met een wizzard.


Volgens mij was het vroeger visueel beter.

[coolkil]

Ubuntu server heeft geen GUI dus waarom zou je dat in de installer dan wel hebben?
bij mijn weten heeft de server editie dat ook nooit gehad.

Probeer de desktop installer en je hebt een mooi venstertje met klikbare knopjes

[Reactie gewijzigd door coolkil op 22 juli 2024 16:20]

[Anonymoussaurus]

Persoonlijk heb ik zelf m'n servers CLI-only, vanwege laag resourceverbruik. Plus dat de GUI bij mij zo traag is als dikke stront door een nauwe trechter (zowel op VMWare Workstation Pro als via Hyper-V.) Ook al geef ik m'n Linux-based VMs (CentOS, Ubuntu Server) 8GB RAM en 4 threads: het blijft traag. Staat ook op een SSD.

De installer kan je inderdaad wel via de GUI doen, maar voor de rest zal ik het niet aanraden (tenzij je specifieke applicaties op de server hebt die een GUI vereisen.

Los daarvan: je kan, los van het feit of Ubuntu Server een GUI heeft, er wel een installeren: https://linuxconfig.org/ubuntu-20-04-gui-installation

[Reactie gewijzigd door Anonymoussaurus op 22 juli 2024 16:20]

[TheVivaldi]

Ubuntu server heeft geen GUI dus waarom zou je dat in de installer dan wel hebben?

Omdat er altijd een strijd is in serverland: de een zweert bij cli-only servers en verafschuwt desktop-servers; de ander zweert juist bij dat laatste.

[Lrrr]

Ik weet dat dat bij Windows-servers een strijd is, maar bij Linux speelt dat toch niet echt?

[coolkil]

Sinds infrastructuur as code een ding is mag ik hopen dat de gui discussie voor Linux afgelopen is?

Tegenwoordig rol ik ze namelijk uit zonder ook zelf maar een enkele login of handmatige configuratie te doen. Daar zou ook geen gui voor nodig zijn maar da's persoonlijke keuze.

Zelfs op Windows zou ik het niet 123 aanbevelen. Daar zou ik een aantal Windows core servers met 1 enkele gui server. Voor zover mijn Windows server kennis is zou je ze met die enkele gui server allemaal moeten kunnen beheren via power Shell en gui snapins op je enkele server met gui.

[Reactie gewijzigd door coolkil op 22 juli 2024 16:20]

[1x3xc-12]

Ik heb nu een server versie uit 2008. Deze houdt het grafisch gezien in het midden tussen de huidige versie en een echte gui. Ziet er veel beter uit.


Een echte gui zoals de desktop dat heeft lijkt me redelijk nutteloos idd.

[Reactie gewijzigd door 1x3xc-12 op 22 juli 2024 16:20]

[Verwijderd]

Volgens mij ben je dan al een tijdje zonder security updates bezig. Ik zou upgraden...

[1x3xc-12]

Hij draait veilig in virtualbox. Ik he hem slechts gedownload om te zien hoe het er toen uit zag

[himlims_]

ligt er maar net aan; heb je de textbased installer (debian/server), of de hippe muis supported Ubiquity die bij de desktop installer zit.

preseeds zijn ook handig voor deployen; https://askubuntu.com/que...buntu-desktop-16-04-1-lts (voorbeeld link, is aardig versie onafhankelijk)

//edit; ik hoop wel dat ze de advanced/custom opties in ere laten, te vaak niet opgelet en voila; zit ineens met shitload aan apps/libs te kijken die ik nooooit gebruik.

[Reactie gewijzigd door himlims_ op 22 juli 2024 16:20]

[coolkil]

Preseeds zijn vrij beperkt is mijn ervaring. Persoonlijk ben ik tegenwoordig een gebruiker van cloudinit voor de basis configuratie

https://medium.com/@art.v...age-with-kvm-1f28c19f82f8

Werkt best wel goed en zowel voor Ubuntu als centos dezelfde syntax

[Reactie gewijzigd door coolkil op 22 juli 2024 16:20]

[DigitalExorcist]

Installers voor Linux.

Ik weet nog wel te herinneren.. Slackware proberen te installeren op een Pentium 75 of zo. Een shell na het booten en je ziet maar hoe je het geïnstalleerd gaat krijgen verder..

[Dorank]

Ik heb de laatste 25 jaar geen Slackware meer geinstalleerd, maar de screenshots van moderne slackware installers komt gewoon overeen met de installer die ik me herinner in 199x. De moeilijkheid in die tijd was de correcte bootdisk kiezen met de support voor je hardware.

[DigitalExorcist]

Ik meen te herinneren dat ik in een shell terecht kwam en zoek t maar uit .... geen setup of iets dergelijks. Eerst je schijf partitioneren, zootje kopiëren, dan compileren, uurtje of wat wachten, en kijken of het op wilde starten.

Daarna je internetverbinding zien te regelen via een modem met de benodigde PPP-drivers en zo.

Maar het is al zo lang geleden dat ik niet eens meer weet hoe ik er ooit aan gekomen ben. CD-Rom waarschijnlijk...

[Dorank]

Je bent in de war met iets anders, slackware had een zeer primitieve package manager in 199x en kant en klare kernels, heel gebruikersvriendelijk voor die tijd.

[DigitalExorcist]

https://opensource.com/ar...inux-test-driving-distros

What's missing is any notion of package management. All installs and uninstalls are entirely manual, with no tracking.

Zeker weten...?

Mja de kernel compileren was niet perse nodig wellicht ... maar heb ik wel een aantal keer gedaan om bepaalde zaken erin toe te voegen.

[Reactie gewijzigd door DigitalExorcist op 22 juli 2024 16:20]

[Dorank]

Je leest het verkeertL het is een package manager zonder dependencies.
Zie hier een install van Slackware 3 (1995): https://youtu.be/EanGvOBhr9s?t=158
Op 2:38 komt de package manager aan bod.
BTW op dat moment was naar mijn weten nog slip de standaard voor inbel internet verbindingen, meestal gebruikte ik niet eens slip maar gewoon telnet als terminal en sz/rz (zmodem) om bestanden te up/downloaden, lokaal internet applicaties draaien was maar raar