Projektek általános

Sziasztok!

Update: Jó sokan rárepültetek a lemezekre, jó is lett volna a dolog, de sajna a főnökség időközben megfúrta a dolgot, így tárgytalan a dolog.

Munkahelyemen selejtezés folyamán előkerült néhány szoftver, amitől meg kívánunk szabadulni.
Minden szoftver eredeti lemez (pl MS szoftverek hologrammos lemezekkel), eredeti licensz kóddal vannak. Természetesen feltelepítve semmilyen eszközön nincsenek, vannak köztük olyanok, amiknek még a matricák is a csomagoláson vannak)
Ti mit csinálnátok velük?

A szoftverek:

• Corel Draw X4 dobozostul
• MS Office 2000 Small Business
• Borland Delphi 5
• Cprel Draw (verzió ?)
• Works 8 (oem, még megvan a matrica is)
• FrontPage 2000 oem
• Outlook 2000 oem
• Small Business Server 2000 oem
• Small Business Server 2011 oem
• Office XP Standard
• Windows XP Prof oem
• TurboPower komponenscsomag
• Windows Server 2003 Standard oem
• Adobe Photoshop Elements 8
• Windows 98 oem (matricával!)

Ezeket simán kezeljem hulladékként (tudom, a CD-k veszélyes hulladéknak minősülnek), vagy mit javasoltok mást? 

Gábor

Eredetileg blogolni akartam róla, de elég aprócska projekt ezért csak iderakom: https://github.com/EricssonResearch/tablesnoop

A cím leírja a fő funkciót, annyival egészíteném ki, hogy képes tracelni policy lookupokat is (ip rule ...). Például ha van egy olyan ip rule, hogy a 8-as DSCP mezővel érkező csomagok nexthopját a 88-as ID-jó routing táblából lookupolja, akkor ez is látszani is fog. Tud olyat is, hogy a sikertelen lookupokat is kiírja. Eredetileg azért született meg, mert bonyolultabb policy + routing + tunnelezés konfiguráció volt és nem egészen azt láttuk a dróton amit akartunk.

Úgy működik, hogy pár helyen "probe"-okat helyez el a kernelben, azokon a helyeken, amiken a rule/route lookup is történik. Ha ismerős a Dtrace vagy LTTng az jó, nagyjából erről van szó, csak itt most eBPF-ben van elkészítve a nyomkövetési logika. Sajnos vannak adatok, amik nem érhetőek el szépen "direktben". Ezért van az, hogy bár a rule lookup mindig megelőzi a route lookupot kernel szinten, itt mégis fordítva vannak megjelenítve. Ez azért van, mert függvények visszatérése triggereli a probeokat, hogy azt is lássuk, sikeresek voltak-e, vagy nem. De a callstack miatt az tér vissza hamarabb, aki később volt meghívva...

Nyitott vagyok ötletekre, kommentekre. Ami tervben van még az MPLS támogatás, egy branchen van egy WIP SRv6 támogatás is. Szeretnék statikus binárist, mert a buildelése nem triviális sajnos.

A Neptun import funkciója bugos. Az adatfelvitel az alkalmazáson keresztül nehézkes. A fejlesztők gyakorlatilag elérhetetlenek egy kar számára.

Tud valaki valamilyen API-ról, interfészről, amin keresztül a Neptun adatfelvitel/módosítás gépesíthető lenne?

A githubon talált API csak a diákok oldalára nyújt némi támogatást.

Sziasztok!

Mivel erre a kulcsszóra nem volt találat a fórumok között, így indítok egyet.
Az alapfelállás, hogy van egy oktatási intézmény, ahol a teremben lévő eszközök vezérlése egy asztalra elhelyezett panelről történik, Crestron rendszerrel megvalósítva.

Funkciók:

• Mennyezeti projektor ki/be kapcsolása
• Hangosítás ki/be kapcsolás, hangerőszabályzással (több kimenet is van, fali hangfal, konferencia kihangosító)
• Videó forrás választása beépített asztali gép/külső jelforrás (HDMI, USB-C stb)
• Fali videókamera (koax) (Covid alatt online közvetítéshez)
• Fali vetítővászon mozgatás

A fenti funkciók logikába kapcsolva (pl projektor be + vászon le).
Ez egy 10+éves, akkor nagyon modern és nem olcsó megoldás volt. Hátránya, hogy elavult és nehezen és költségesen karbantartható. Pl. projektor csere esetében új fw programozás a vezérlő kódok miatt, horror áron. Ha kifagy a rendszer, akkor reboot kell, ami 5 perc körül van, amit a tanárok nem szívlelnek.

Ezért elhatároztuk, hogy megvizsgálunk alternatív megoldásokat is a megújítás jegyében.
Alap elvárás, hogy 

• a rendszer kezelje az eszközök közti logikát
• érintő képernyőről - tablet, panel - kezelhető legyen
• hamar rendelkezésre álljon újraindítás esetén
• konfigurálható/bővíthető legyen

Ehhez gondoltam javaslatokat, ötleteket gyűjteni, hogy akiknél működik már ilyen vagy rendelkeznek tapasztalattal melyik gyártó mellett döntöttek, milyen eszközöket (akár konkrét típusok) telepítettek.

Egyelőre google keresésekkel nem vinném el a fókuszt, mert a cégek úgyis találkozni akarnak, de irreális árú eszközök vagy ágyúval verébre rendszerek úgy sem jönnek majd szóba.
Konkrét tapasztalatok nagyon sokat segítenének.
Köszönöm,
Szilárd

Minimális erőforrásigényű dekompresszor algoritmust keresek, MC6800-ás CPU-ra.

A rendelkezésre álló olvasási művelet 3 bájtos blokkokban teszi lehetővé az adatok olvasását. Ezeket az adatokat egy adott címtől kezdve kell eltárolnom a memóriában. Mivel az olvasható adatmennyiség mérete korlátos, jó lenne az adatokat tömörített formában tárolni, és kiolvasás közben kitömöríteni, így talán el lehetne érni, hogy a rendelkezésre álló 8KB memóriát majdnem tele lehessen tölteni adatokkal.

Jelenleg az LZSS algoritmus egy speciálisan ehhez a feladathoz módosított változatán dolgozom, de még mielőtt túl sok energiát ölnék bele, megkérdezem, hátha valakinek van jobb, célszerűbb ötlete.

Az adatok összetömörítését egy C program fogja végezni, így ilyenkor tetszőleges erőforrásigény elfogadott. Csak a kitömörítés a szűk keresztmetszet.

El szeretnénk hagyni a clouderát, felépíteni a komponensekből önállóan - hue nélkül, spórolásból ugye.

Valakinek volt hasonsló projektje, bármi említésre méltó lessons learned?

Sziasztok.

Kétcsatornás oszcilloszkópra lenne szükségem, lehetőleg kis méretben.

Max 10 voltot, 440 Hz körüli értékeket szeretnék kirajzoltatni vele egyidőben mindkét csatornán bejövő jelből.

Analóg modularszintetizátorról van szó, próbálok inkább mindent magam összehozni, amit lehet...

Amiket eddig láttam:
https://www.conrad.hu/hu/p/digitalis-oszcilloszkop-200-khz-1-csatornas-…

https://kytary.hu/korg-nts-2/HN258136/?gad_source=1&gclid=Cj0KCQjw-5y1B…

A kettő között megállapodnék. HA RPIvel vagy Arduinoval rohannék neki az útnak, akkor sem úsznám meg olcsóbban.
 

https://nav.gov.hu/fooldal-elemei/fooldali-csempek/uzemszunet

Az Online Számla rendszer, az Online Számlázó program, valamint az eÁFA-program informatikai karbantartás miatt 2024. április 25-én 14 és 19 óra között nem lesz elérhető, sem az elsődleges, sem a másodlagos felhasználóknak, valamint az adatszolgáltatás teljesítésére sem lesz lehetőség.

Az Online Számla rendszer, az Online Számlázó program, valamint az eÁFA-program informatikai karbantartás miatt 2024. május 3-án egész nap nem lesz elérhető, sem az elsődleges, sem a másodlagos felhasználóknak, valamint az adatszolgáltatás teljesítésére sem lesz lehetőség.

Elvárások:

1 - Fájlokat lehessen feltölteni, az eredményt letölteni.

2- Értse az elektronikát, informatikát, értelmesen fordítson.

3 - HTML fájlokban tudjon szöveget fordítani.

Pl: https://www.esp8266.org/help/help_GPIO.html fájlt fordítsa le spanyolra.