29 replies to this topic

[hro]

    UP/DOWNLINK 2018-11, 21 november
pagina    inhoud
2    (Kanalen)nieuws en wijzigingen
2    Algemeen omroepnieuws
3    Astra 1, 19,2 oost
4    Astra 3, 23,5 oost
5    Astra 2, 28,2 oost
6    Hotbird, 13,0 oost
7    Eutelsat 9B, 9 oost
7    Kabel, IPTV/OTT, DAB+, DVB-T(2), FM, AM, streams enzovoort…
9    Reacties en vragen van lezers
10    Special: Is een lnb met 0,1dB ruis beter dan een lnb met 0,6dB ruis?
10    Special: Kanalenlijst Hans, video met uitleg staat online
10    Special: Maatvoering chaos in schotelland
10    Wetenswaardigheden
18    Hardwarenieuws
18    Axas E4HD 4K Ultra
19    Softwarenieuws
19    888zoeker
19    Favorieten-boeket bewaren in Kanalenlijst Hans
20    Lamedb: laa-med bee of leem DeeBee?
20    DemonEditor: Linux software voor bewerken van een kanalenlijst
21    OpenPLi 7.0 Release Candidate: een pre release test image
22    De Transponder
22    Thema op clubdag 24 november: Google Chromecast
23    Oproep voor 'demonstranten'
23    Uitsmijters
23    2 cent per zender per dag…
23    LON met de handen in het haar
25    Typisch Belgisch…
 

Attached Files

•  updownlink_2018_11.pdf   1.27MB   154 downloads

[WanWizard]

Dank voor het leesvoer weer!

 

t.a.v. het stukje van Dolf:

 

het is toch echt Lame DB, een database geimplementeerd in een flat file omdat de eerste enigma box helemaal de power niet had om een fatsoenlijke database te draaien. Daarom is er een abstractie laag bedacht, als je in de bouquet files kijkt, dan zie je zaken die lijken op SQL syntax, die de abstractie laag omzet naar het doorlopen van een platte lijst. Dit is ook de reden dat Enigma deze data allemaal inleest bij het opstarten, realtime door een tekst bestand zoeken zou veel te traag (geweest) zijn. 

 

Dat van het LAME project is leuk bedacht overigens.

[Frenske]

En uiteraard ook weer bedankt namens ondergetekende.

[cobus]

Hier idem

[pgmpli]

Kan geen boek tegenop,

[wortellica]

Super weer, gaan we weer ff doornemen.

[hro]

Super weer, gaan we weer ff doornemen.

nou ff... deze keer 25 pagina's vol informatie...

 

de redactie is benieuwd, reageer gerust.

[Remi_4]

En bedankt weer.

Verstuurd vanaf mijn SM-T800 met Tapatalk

[40H3X]

Dank redactie!

[Tech]

Altijd weer leuk leesvoer met leuke wetenswaardigheidjes.

 

Wederom bedankt voor deze nieuwe uitgave!

[Pippin]

Eindelijk een (Demon)Editor voor Linux.

[MiLo]

LAMEDB is inderdaad maar een "suffe database".

Een voor die tijd rare keuze, want ASCII data inlezen en omzetten naar iets waar de CPU intern wel iets mee kan is voor veel CPU's, en dan met name ARM en MIPS (destijds de CPU in alle settops), een zware taak. De Intel x86 familie heeft zelfs speciale instructies voor die omzetting, maar dan nog kom ik op 't werk ook vandaag de dag nog systemen tegen waar de processor 80% van zijn tijd verkwist met het inpakken en uitpakken van ASCII. Enfin, dat even terzijde...

De LAME MP3 codec was gewoon een open source MPe encoder/decoder, en de suggestie dat die was "om te leren hoe het werkt" was alleen maar om de juristen van Fraunhofer op afstand te houden. Wie "iets" maakte waar een MP3 codec in zat, zoals een shareware of zelfs freeware programma, moest per gebruiker een bedrag tussen de 50 cent en 2 dollar aftikken aan die toko (voor gebruik van hun patent), met een jaarlijks minimum van 15000 dollar. De oplossing was om de MP3 support via LAME te doen en de gebruiker die codec zelf te laten compileren en installeren. Daarmee kon je het patent omzeilen.

Het goede nieuws is dat de MP3 patenten dit jaar zijn verlopen, en dus alle MP3 codecs gewoon onder vrije licenties gebruikt en verspreid kunnen worden.

Edited by MiLo, 22 November 2018 - 12:10.

[Erik Slagter]

Niet zo interessant detail, de lx106 processor (vooral bekend van de ESP chips) heeft, terwijl het een echte RISC instructieset heeft en in principe alles 32 bits doet (het bekende probleem), toch ook wel een paar instructies om slim/snel willekeurige bits uit een word te masken en shiften, in één clock. Dat scheelt toch wel een stuk, daar is over nagedacht. Ik moet wel zeggen, 80% van de cpu tijd, misschien waar, maar dan heb ben je wel heel veel van dit spul aan het doen (megabytes aan ASCII...?) op een erg trage CPU. Ik kan het moeilijk geloven. Ik houd wel van human readable configs/db's, mits heel klein uiteraard, omdat je dan makkelijk dingen kunt checken en zonodig rechtzetten, zonder dat je specialistische tools nodig hebt. Maar zoals de lamedb is gemaakt, dat is een voorbeld van hoe het niet moet. Ze hadden dan op z'n minst xml moeten gebruiken.

[MiLo]

XML is wel het eerlijkste formaat. Zowel mensen als machines hebben moeite om er nog kaas van te maken...

Belangrijkste problemen met de tekst formaten zijn dat ze alle vormen van parallelle processing om zeep helpen, en dat elke digit een multiply-accumulate cycle vereist.

[theparasol]

XML is wel het eerlijkste formaat. Zowel mensen als machines hebben moeite om er nog kaas van te maken...

 

Ben er deze week 2 dagen mee bezig geweest en maar blijven denken dat ik niet "slim" genoeg was... Alles behalve intuïtief en maar doorgaan immers anderen gebruiken het ook  

[Erik Slagter]

Belangrijkste problemen met de tekst formaten zijn dat ze alle vormen van parallelle processing om zeep helpen, en dat elke digit een multiply-accumulate cycle vereist.

Die is tegenwoordig zooo goedkoop, mits je FPU en/of SIMD hebt. Anders moet je alles hex noteren, dan kun je shiften

[Erik Slagter]

 

XML is wel het eerlijkste formaat. Zowel mensen als machines hebben moeite om er nog kaas van te maken...

Ben er deze week 2 dagen mee bezig geweest en maar blijven denken dat ik niet "slim" genoeg was... Alles behalve intuïtief en maar doorgaan immers anderen gebruiken het ook

XML vs. Ascii is net als C++ vs. Python. Python is "lekker makkelijk" omdat "alles mag". C++ en XML dwingen je er even goed over na te denken. In eerste instantie baal je daarvan, maar op de lange termijn scheelt het wel degelijk tijd, aan debuggen...

 

BTW je hebt allerlei mooie XML validators, die kun je natuurlijk best gebruiken.

Edited by Erik Slagter, 24 November 2018 - 11:03.

[MiLo]

Belangrijkste problemen met de tekst formaten zijn dat ze alle vormen van parallelle processing om zeep helpen, en dat elke digit een multiply-accumulate cycle vereist.

Die is tegenwoordig zooo goedkoop, mits je FPU en/of SIMD hebt. Anders moet je alles hex noteren, dan kun je shiften

SIMD helpt niet bij ASCII->bin conversie, dat bedoel ik met "parallelle processing om zeep helpen". Zelfs hex noteren betekent een shift+or per digit, kost je hoe dan ook weer een clock cycle. Krijg je nog steeds het effect dat een 180-taps FIR filter minder tijd kost dan het inlezen van de data uit een tekstbestand.

Dat we nu "zoveel" CPU power tot onze beschikking hebben is geen smoes om dan maar alle efficentie overboord te gooien. Ik erger mij mateloos aan al die onnozel trage meuk die je tegenwoordig voorgeschoteld krijgt...

[hro]

Het is wel frappant... geven we een blad uit over met name satelliettechniek en meeste reacties op het november-nummer zijn meer van computerclub-achtige aard... ;-)

 

Andere reacties ook welkom, het blad telt 25 pagina's, één ging maar over lamedb...

[Erik Slagter]

Dat we nu "zoveel" CPU power tot onze beschikking hebben is geen smoes om dan maar alle efficentie overboord te gooien. Ik erger mij mateloos aan al die onnozel trage meuk die je tegenwoordig voorgeschoteld krijgt...

Dan heb jij nog nooit naar de sources van "hedendaagse" commerciële software gekeken. Dat is heel andere koek dan discussie over wel of niet een config file in binary. Je hebt tegenwoordig 12 cores op 4 Ghz met 32 Gb RAM nodig om een medium size database te draaien. Gewoon omdat ze niet snappen hoe je goede SQL statements maakt die optimaal de slimmigheid van de DBMS gebruikt. In plaats daarvan trekken ze dan de hele tabel leeg en gaan er met string matches op los. Zo krijg je elke server wel op z'n knieëen.