Onderwerp: Installeren Nuc als plotter met Debian en OpenCPN

Heb je de link al bekeken ? bekend probleem
Of doen we gewoon of het niet bestaat ? Ik ben zo langzamerhand wel klaar met me te laten patronaliseren. Misschien gewoon iemand serieus nemen. Die troep software is gewoon niet af en werkt meestal niet. Door jou gedrag wordt ik alleen maar meer gesimuleerd het hele linux verhaal heel snel in de bitten bak de deponeren en gewoon weer over te gaan naar iets wat direct werkt. In mijn werk was dat een stelregel. Als software twee keer niet deed wat de maker er van beweerde dat het wel zou moeten doen werd er geen minuut langer aan besteed. Ik ben hier al lang in over tijd.
O-charts moet gewoon nog even aan het werk om de zaken netjes voor elkaar te krijgen. Niet erg. Maar ik ga er geen tijd meer in steken.

3Noreen schreef : En dat is gewoon een kwestie van goed configureren welke data wel of niet via dat bolletje gaat.

Lijkt me simpel om daar een meerdere filters voor te zetten, zodat daar niets per ongeluk door gaat. Bijvoorbeeld een defaultroute naar de bittenbak en een 2e route voor de belangrijke data via de sateliet. En hier geldt dat automagische tools je vaak tegenwerken.

Ik zie hier eigenlijk alleen voordelen voor Linux (zelfs met Ubuntu), maar een uitgebreide uitleg over iproute2 lijkt me hier te ver gaan. Ongetwijfeld is dit ook mogelijk met BSD, Windows en MacOS, maar ook hier geld dat je het best werkt met het systeem van jouw voorkeur.

reuver schreef :

Nu gooi je het weer compleet over een andere boeg. Jij snapte niet:
Bijvoorbeeld: waarom 3N hamert op het overvloedig delen van gegevens op een systeem dat in mijn ogen offline wordt gebruikt.

Maar nu ik je dat duidelijk heb gemaakt ga je mij uitleggen hoe ik dat zou moeten voorkomen. Ik ben blij dat jij nu daarvan de noodzaak begrijpt.

3Noreen schreef :
Het fundamentele probleem in de discussie tussen ons is dat ik totaal andere prioriteiten stel als jij.

Jouw "Ubuntu-probleem" zie ik als een algemeen probleem dat opgelost moet worden ongeacht het OS (windows, macos, ubuntu, debian).

Jouw plugin probleem zie ik als een groter probleem. Maar jij bent natuurlijk veel beter in het oplossen van problemen in code als ik.

reuver schreef :
Je mag andere prioriteiten stellen dan ik maar mag ik je er op wijzen dat dit een project draadje is ? Jij ziet allerlei beren op de weg die ik niet in herken. Ik heb een prima werkend systeem met slechts 1 nog op te lossen dingetje. Dat is dat de plugin voor de o-charts.org kaarten nog in ontwikkeling is. Daardoor niet stabiel werkt ongeacht welke verzie van Linux je gebruikt. Dit een bekende bug en is gemeld op github. Ik ga er vanuit dat de ontwikkelaar(s) hier aandacht aan zullen besteden en er uit zullen komen. Bugs zijn nu eenmaal inherent aan software en zijn pas onoverkomelijk als de maker van de software er geen aandacht aan wil besteden.

3Noreen schreef :

8 Maanden terug gerapporteerd; lijkt helaas die kant op te gaan. Of zijn er geen nieuwere releases meer uitgekomen en ligt de ontwikkeling van deze plugin uberhaubt stil?

Nachtvlinder schreef :
Ja die ligt stil. Er wordt gewerkt aan een nieuwe vervangende plugin. Vandaar dat mijn aandacht zich ook vooral richt op het instaleren van deze nieuwe plugin. Tegen de adviezen van de linux adepten in.

Wat me verder wel opvalt is dat de bereidheid van de ontwikkelaars om Debian te ondersteunen heel gering is. Het komt mij over als een vorm van cancel culture. Waarvan mij niet duidelijk wordt wat daarvan de motivatie is. De libs die om overduidelijke reden geen open source zijn zou je prima kunnen installeren onder het regime van undisclosed security wat Debian bied.

3Noreen schreef : De starter van de issue op GITHUB is de ontwikkelaar van een alternatief opensource navigatie-programma voor OpenCPN op o.a. RaspPI (AVNAV - zie draadje over NMEA-bluetooth). Avnav ondersteunt echter alleen native rastercharts, maar interfaced ook naar SignalK en Ocharts. Blijkbaar heeft hij bij de integratie van de plugin deze problemen gevonden.

Mijn interesse in /gebruik van Avnav is wegens excellente support, bluetooth, android en server functie.

PietO schreef :
Ik heb dit stukje nu een keer of tien gelezen maar snap nog steeds niet wat er staat.
Bedoel je dat diegene dit het probleem signaleert een concurrent is die mogelijk belang heeft ? Of zo iets.

Maar bedankt voor het aandragen van een alternatief. Ik heb zelf ook al zitten kijken naar qtVlm en visitmyharbour kaarten.

3Noreen schreef :
Je klaagt alsmaar over problemen die anderen niet hebben. Het werkt zoals uit de reacties blijkt zonder problemen. Maar het kan natuurlijk altijd weer beter. Daar wordt nu volop aan gewerkt.

Als je het toch wilt proberen, niet gaat zeuren dat het beta is, dan kan dat.

Je moet hiervoor de beta instelling nemen van het plugin menu. Maar die is er niet.

Die kun je wel verkrijgen door in de opencpn.conf achter plugins de volgende regel toe te voegen:

CatalogExpert=1

Zeker niet aan te raden. De verdere updates van deze plugin komen dan binnen via de plugin. De basis is de 0.9 versie. Kaarten hiervoor downloaden is nog niet mogelijk. Dit kan wel voor test doeleinden.

Zal overigens niet zo lang meer duren omdat het werk grotendeels gereed is. De bijbehorende documentatie is nog een achter gebleven punt.

Overigens heb ik wel een probleem met de laatste plugin in combinatie met de RPI Bulleye. Op het RaspiOS en Ubuntu 64 bits werkt het perfect.

Nogmaals je kunt het proberen, maar dan niet weer gaan mekkeren dat het beta is.

De ontwikkelingen liggen zeker niet stil en ook een nieuwe versie van OpenCPN komt er ook al aan.

Bram

3Noreen schreef : Diegene is "Wellenvogel" open-source ontwikkelaar van Avnav. Het woord concurrent duidt op financieele aspecten, maar die zijn er hier niet.

PietO schreef :
Nee van financieel gewin leek me ook geen sprake. Daarom, mede geïrriteerd door sommigen die op een bepaald stramien blijven doordrammen, interpreteerde ik jou opmerking verkeerd. Daarvoor mijn excuses. Wellenvogel lijkt me juist iemand die verstand er van heeft en een andere ontwikkelaar een helpende hand toesteekt. Iemand als Wellenvogel kan ook veel beter dan ik zou kunnen aangeven waar het fout gaat. Ik als leek kan alleen maar constateren dat het zaakje vastloopt.

Thnx: klopt exact wat je zegt; iemand met verstand van zaken en uiterst behulpzaam.

Na wat gekloot met cmake instructie files een nieuwe oeSENC-4.2.19.29 en o-charts-0.9.0.33 voor debian 11 gebouwd. De binaries (libs) waren van 16 mei. Mijn geteste builds waren van 15 mei Misschien dat het iets uitmaakt.
We gaan het zien.

Nachtvlinder schreef :
De opmerking zal over versie 4.2.16.x of ouder zijn geweest. De fix zal ergens rond 4.2.18.3 zijn doorgevoerd (februari, ook erg laat). We zitten inmiddels op 4.2.19.29.

Ik vraag me af of de OpenGL driver die 3N gebruikt niet zorgt voor een heel specifiek probleem.
(Het probleem dat ik in de changelog van TurboVNC vond lijkt niet aanwezig bij oesenc_pi.)

Het probleem van Wellenvogel was een issue voor de RPI3 met 1GB. Als de 16GB van 3N volloopt in 8 uur hoe snel loopt het geheugen van de RPI3 dan vol als alleen de "kleine" memory leaks nog aanwezig zijn?

3Noreen schreef :
Ik heb eens gekeken wat Debian nu eigenlijk is. (ik heb geen verstand van Ux meer sinds 1980).
Dan schrik ik toch wel. De hele familie Debian staat op wikipedia.
Er zijn inmiddels 186 familieleden. Hele stamboom staat op wiki.
Betekent 8 forks per jaar....
Daarbij komt nog dat Debian voor 3 verschillende kernels bestaat (Linux, FreeBSD en Hurd).

Al met al geen aanlokkelijk terrein voor ontwikkelaars van toepassingen..... veel te veel variaties die je moet ondersteunen.

Baasklusje schreef :
Maar aan de andere kant ontwikkel je voor Debian zelf. Ontwikkel je voor alle forks. Alleen daar komt het, debian is niet het meest flitsende en nieuwe wat er is. Daarom worden veel forks van de test versies gemaakt. Als je daar in tegen wacht tot de versie van debian als stabiel en klaar voor gebruik in "productie" is dan heb je vooral een heel saai besturingssysteem wat geen verrassingen oplevert. De debian versie die ik in dit project gebruik gaat deze week na anderhalf jaar testen over naar de status stabiel. Een ander ding is dat alle software die tot het originele debian wordt toegelaten nogal hardhandig wordt beoordeeld op stabiliteit. Opencpn heeft na jaren werken eindelijk die status bereikt. Daardoor ben ik verleid om deze poging van dit draadje. Alleen had ik me niet gerealiseerd dat de toegevoegde software in de vorm van plugins niet die status heeft. Ik heb dus door schade en schande en veel werk mogen ervaren dat de plugins alleen beschikbaar blijken voor de forks waar niet zo nauwlettend op de stabiliteit gelet wordt.
Het mooiste voor een gebruiker zoals ik die voor maximum stabiliteit gaat zou zijn dat dat ook de plugins in de standaard DebianRepository zou zijn opgenomen. Maar de mogelijkheid daarvoor wil de belangrijke ontwikkelaar voor opencpn die van de o-charts plugin juist van af.

3Noreen schreef : Over 7 weken

Menno schreef :
Ok, heel belangrijke cruciale fout in mijn verhaal. Heel erg bedankt voor deze correctie. Ten aanzien van dit project had ik moeten wachten tot volgend seizoen.

Anderhalf jaar tijd om een goed werkend systeem te krijgen ?. Elke maand verschijnt er een nieuwe kernel versie, die daarna doorwerkt in diverse Linux versies. In principe is Linux in de basis hetzelfde.

Dan heb je toch veel ontwikkelingen op het gebied van drivers (modules) gemist.

BK heeft zijn kennis al niet meer bijgehouden sinds 1980 en dat blijkt wel.

Linux is er voor allerlei toepassingen, zit in een router, media center, TomTom, Android, AMD64 en ARM64 desktop versies, supercomputers, Nasa ruimtevaart en SpaceX vliegt ermee naar het ruimte station.

Ja, dan heb je wel wat variaties.

Voor OpenCPN moest je voorheen nog een juiste release versie toepassen.

Dat is met de flatpak (=Snap) versies niet meer nodig. Je kunt op de meeste systemen, ook op Debian, de applicatie Flatpak installeren. En daarmee er OpenCPN op zetten.

Overigens op Ubuntu zit OpenCPN standaard in de repositories. Echter flatpak gaat een stapje verder.

De plugins komen van diverse ontwikkelaars en die kun al dan niet inschakelen. Inmiddels een hele lijst inclusief de Radar plugin met een radar overlay op je OpenCPN kaartplotter. Dat heeft niets met een bepaalde Linux distributie te maken.

Men moet het niet onnodig moeilijk maken dan nodig is.

Met een bootje varen is geen "rocket science" en razend snelle software heb je ook niet direct nodig als je 6 knopen vaart.

Je hoeft ook niets te compileren. Kan allemaal wel, want het is open bron software. Je kunt vrijwel overal bij.

Bram

Baasklusje schreef :
Van die 186 versies worden er maar 3 veel gebruikt: Debian, Ubuntu en Mint.
Mint heeft heel weinig eigen packages, en neemt het meeste direct over van Ubuntu.
Ubuntu neemt 2 keer per jaar een snapshot van Debian testing of unstable en gooit daar dan een eigen sausje over.
Als je een package bijhoudt voor Debian Unstable wordt dat vanzelf een keer geschikt voor Ubuntu Stable, Debian Stable en Mint.

brambo schreef : Flatpak en Snap zijn concurrerende tools, en niet compatibel

brambo schreef :
'In principe in de basis' kan één 1-tje ipv één 0-letje de hele boel krakend tot stilstand brengen. Dat weet je nog wel toch?

brambo schreef : Het is eigenlijk 1,5 jaar steeds naar de laatste versies van alle software upgraden in unstable, en dan een freeze van een aantal maanden om er een stabiel geheel van te maken. Grote wijzigingen die doorwerken in veel packages (bijv. verwijderen Python2, overgang van sysvinit naar systemd) mogen alleen voor de freeze gebeuren.

Ubuntu heeft een vergelijkbare opzet, maar bouwt in die anderhalf jaar ook nog drie minder lang ondersteunde releases. En bij Ubuntu staan de release-datums vooraf vast, terwijl Debian werkt met een release “when it’s done”