Az APEH nem szereti a linuxosokat

Vélemény

A fenti címmel jelent meg egy érdekes és egyben fura cikk az Index/it.news oldalán. A cikk itt.

( Lityi | 2006. 11. 30., cs – 10:56 )

Nem az, hogy nem szereti.

Az APEH megbízta vmelyik fejes kis hülyegyerek ismerősért jó pénzért, hogy gányoljon össze valamit.

Hozzáértés sehol, erősen megnyomott ceruzával kiállított számla viszont igen, aminek ellenértékéből mindenki részesedik odafönn.

A szeretetnek semmi köze ehhez, maximum ennek a rohadék korrupt rendszernek.

Nem mondtam, hogy kizárt amit írsz, sőt, szerintem is jó eséllyel igaz. Viszont a hozzászólásod azt tükrözte, hogy tisztában vagy a pontos tényekkel, ezért megkértelek, hogy oszd meg velünk.

Ha meg csak annyit tudsz a dolog hátteréről, amennyit én (~semmit), akkor légyszives írd oda a "valószínűleg", vagy a "szerintem" szavak valamelyikét.

"A második – még folyamatban lévő – kísérlet egy platformfüggetlen, Java-alapú verzió kifejlesztése volt. Ez a változat egyelőre azért tűnik zsákutcának, mert a leggyorsabb számítógépeken is rendkívül lassan fut."

Ez egyértelműen hozzáértés nem értés miatt. Java alapú alkalmazást nem lehet rendesen megírni? Röhögtetik magukat. A másik mondat amely az APEH informatika/Pillér totálisan nevetséges mivoltát ékesen definiálja:

"Futó Iván, az APEH akkori informatikai elnökhelyettese, aki úgy tudta, hogy a program kész, arra kért linuxos szakértőket, minél teljesebb körben teszteljék az új szoftvert. A fejlesztő cég azonban nem tudta kiadni a programot, mert az nem volt még tesztelésre kiadható állapotban."

de csitt

Java-alapú verzió kifejlesztése volt. Ez a változat egyelőre azért tűnik zsákutcának, mert a leggyorsabb számítógépeken is rendkívül lassan fut.

Ez egyértelműen marhaság, vagy teljes inkompetencia. Én nem vagyok pogromozó szagember, de használok pár javás progit, amik egész gyorsak még egy 5-6 éves Celeronon is. Pl. itt van a period04, ami ráadásul kissé bonyibb számolásokra van kitalálva, mint az a béna ABEV. Az Azureust meg nyilván nem kell bemutatni senkinek sem.

"Futó Iván, az APEH akkori informatikai elnökhelyettese, aki úgy tudta, hogy a program kész, arra kért linuxos szakértőket, minél teljesebb körben teszteljék az új szoftvert. A fejlesztő cég azonban nem tudta kiadni a programot, mert az nem volt még tesztelésre kiadható állapotban."

Ez pontosan így történt, engem kért fel dr.Futó a tesztelés megszervezésére és nekem (nekünk) ne tudta a Pillér a szoftver időben tesztelésre átadni, mert nem volt olyan állapotban.

( zwei | 2006. 11. 30., cs – 11:02 )

A vendor lock-in tipikus esete.

"az APEH által követelményként támasztott Arial betűtípus a Microsoft tulajdona .... Reménykedésre adhat okot ugyanis, hogy a .. Wine szoftver fejlesztői bejelentették a 0.9.25-ös verzió megjelenését. A számos hibajavítás és újdonság mellett ez a változat – a hírek szerint – már képes futtatni az ABEV programot."

Ez igazán jó hír, de az Arial ettől még a Microsofté, nem? Vagy amíg linux alatt nem, linux+Wine esetében már jogtisztán használható?

Hmmm, lehet, hogy az én hibám... de kettős könyvelésnél tényleg a dinamikus szélességű font az ideális választás? Mert én már itt koncepcionális hibát vélek felfedezni. Én az ilyesmire mindenképpen fix szélességű fontot használnék, mert az sokkal áttekinthetőbb (például a számlaosztályok, vagy mifenék számai pontosan egymás alá kerülnének).

( syntern | 2006. 11. 30., cs – 11:15 )

"A második – még folyamatban lévő – kísérlet egy platformfüggetlen, Java-alapú verzió kifejlesztése volt."

Volt valamilyen főiskolán, talán Egerben egy tech-day, ahol az APEH illetékes fejlesztői előadták ezeket a nehézségeket. Még valamikor tavasszal. Ami megmaradt bennem belőle, hogy nehezen tudták Java-ból elérni a megfelelő Windows registry kulcsokat. Meg volt még pár ilyen hülye akciójuk, hogy azt hitték, hogy a Java az úgy is platformfüggetlen, ha közben integrálni próbálják Windows only komponensekkel.

Ez is csak egy magyar informatikai fejlesztés :(

( Kelt | 2006. 11. 30., cs – 11:25 )

Csak remélni tudom, hogy ha a Wine fejlődését megoldásnak tekintik, akkor az APEH nagyobb összeggel támogatja majd a Wine OS X-re való portolását. Opcionálisan osztogathatnak Parallels és XP licenceket is. ;)

Szerintem eszükbe se fog jutni, de ha még valaki meg is említi nekik, akkor se fognak a zsebükbe nyúlni.
De én úgy látom, hogy már a megrendelő (APEH) szintjén gond van a követelményekkel (mármint annak a tipikus esete, hogy maga a megrendelő sem tudja, hogy mit akar. Erről jut eszembe amit a BMF-en mesélt a tanár: már minden részletben megegyezett az ügyféllel és a végén közölte az ügyfél, de basic-ben legyen megcsinálva, mert a fia is azt tanul és az úgy milyen frankó lesz... Itt meg úgye: de Arial betűtípussal legyen, mert itt csak azt ismerik az alkalmazottak (vezetők)...)

( zoli78 | 2006. 11. 30., cs – 11:34 )

Csinálni kéne egy opensource apeh bevalláskészítő keretrendszert normális programozói eszközökkel és onnan kezdve az apeh-nak csak az űrlapokat és a logikát kellene mellérakni. Ha lenne szabadidőm, akkor elkezdeném megtervezni, csak hogy lássák, hogy nem lehetetlen egy kis gépigényű jól átgondolt multiplatformos keretrendszert készíteni hozzá. Legrosszabb esetben is lenne egy apeh által nem elfogadott bevalló program (amivel azért kiszámolni, illetve ellenőrizni lehetne, csak elég ember kell, aki leteszteli).

Szerintem egy kész működő szoftver kéne csak hozzá. Bár valószínűleg csak azt érnénk el vele (feltéve, hogy egyeltalán sikerül az illetésekig eljuttatni és szemügyre veszik), hogy a fejlesztőjük valahogy kimagyarázná a helyzetet (pl. azzal, hogy de ez opensource és könnyen vissza lehet vele élni).
Amúgy tényleg csak időm nincs rá és elég valószínű, hogy nem is lesz. De ha páran összejönnénk egy levlistán/fórumon és elkezdenénk felvázolni egy ilyen keretrendszerrel szembeni követelményeket, majd a megvalósítási lehetőségeket, akkor azért valami csak elindulna. Ha más nem, akkor az APEH fejlesztői kapnának néhány tippet.
A 2D vonalkódnak utána kell nézni, mert lehet, hogy maga a technológiát licencelni kell.

jovore nem lessz meghatarozva hogy milyen programmal keszited, ha minden igaz (csak a kimenet lesz szabvanyositva, minden xml ben /most is megadjak a kimeno fajl leirasat,igaz nem mindet/

a mai konyvelo programok elkeszitik a bevallas kimeno adatait, azt akar at is teheted az apeh programba de be is kuldheted egybol azt apehnak
/legalabb is eddig, most valami gpg titkositast iktattak kozbe,amihez ugye megint kell az apeh prgja//

de a Wine "szerencsenkre" feljavitotta MSHTML tamogatasat igaz meg nem tokeletes, de mukodik

innentol fogva nem erdekel apeh mint kavar a win-el
inkabb az zavar hogy az en penzemet szorjak

a nyari linuxos apeh program fejlesztes mert nem folytatodik? mert hogy nem eri meg :)
delfi mar fordit linuxra is,/csak a beallitasokat kene megtalalni/
kinyomtatni meg ugy se kell /hivatkoznak a csoda 2D3D4D kodra az aljan/
mivel jovore ugyis mindent neten kell beadni
amit nem azon meg nincs annyi adat hogy ne tudnak kezzel bevinni, vagy ne csinaljon kezzel beadhato nyomtatvanyt

A lényeg az, hogy valahogy már rendeződjön a helyzet.
Egyébként azt az egyet nem hiszem el, hogy az APEH nem szereti a linuxot (szerintem a windowst se, csak ehhez értenek, ezt ismerik), egyeltalán nem szeretet kérdése ez. Volt valamire igény, próbáltak valamit csinálni, de most már tisztán látom, amit eddig csak sejtettem a widnowsos verziók után: egy hozzá nem értő társaság fejleszti a szoftvert.

ebben az evben volt ilyen ha emlekeim nem csalnak
a programozo programozzon csak, azert kapja a fizeteset

el sem tudom kepzelni / :) / hogy plusz egy szazalekos levonast milyen nehez beleszerkeszteni egy jol megtervezett programba, sejteseim szerint sem tobb egy 8 oras munkanapnal
dokumentacioval egyutt, de biztos tobben is megcafolnak majd hogy legalabb 1-2 honap

afakulcs egy szazalekos ertek megvaltoztatni gondolom nem honapokba kerul
a jarulek alap sem tart tovabb
hangsulyozatam, de meg egyszer jol megtervezett program

itt inkabb az a baj hogy amire kihirdetik a valtozasokat, /amit ugye nem lehet elore tudni biztosra mert naponta valtozik/ addigra marad 1 hónap minden valtoztatást vegrehajtani a programon belul

nem neveznem oket uriembereknek, nem azok

Én nagyon régen tanultam programozni és jó ideje nem is csinálok ilyet, de változó paramétereket nem paraméterfile-ban tárol az ember? És a program csak a paraméterek alapján adatokat feldolgozó logikát tartalmazza? Vagy a logika is változik? Nem tudom, nem foglalkozom adózással. :-D

Ave, Saabi.

( tbandi | 2006. 11. 30., cs – 11:50 )

[komolytalan]
Az az igazság, hogy szerintem a linuxosok se igazán szeretik és ezen az ABEV linuxos verziója se fog tudni változtatni jelentős mértékben. Esetleg egy bizonyos mértékű adójóváírás az igazoltan linuxot (szabadszoftvert) használó adóalanyok számára. Addig azonban az APEH kifejezés számomra megmarad a 'halál', 'betegség', 'lepra', 'szegénység', 'adó', 'számla', 'végrehajtó', stb. kifejezések tőszomszédságában, a lelki egysúlyra törekvő tudatom által kirekesztett agyi területen.
[/komolytalan]

( Botond | 2006. 11. 30., cs – 12:40 )

Az APEH, meg a Pillér Kft. le van szarva.
A wine-0.9.25 viszont uralkodik. Éppen most nyomtattam egy bevallást wine alól az abev2006-tal. A hosszú "ő" betűk ugyan hullámosak, meg mintha más apró grafikai hibák is lennének, de a 2D vonalkód rajta van, és a nevek, meg számok jól néznek ki Arial nélkül is.

( saabi v | 2006. 11. 30., cs – 13:24 )

És a linuxosok szeretik az APEH-et? :-D

Ave, Saabi.

nem csak az APEH-hel van ilyen gond nez meg barmely allamigazgatasi hivatalt amely valamilyen bevallast kert akar elektronikusan akar papiron
eredmeny /nyilvan van kivetel is/

csak wines programok, letoltheto dokumentumok doc formatumban ugy megszerkesztve hogyha ooo-ban betoltom szetesik az egesz
le lehet persze tolteni itt ott pdf kent is ami / ismetlem tisztelet a kivetelnek/ szinten szetcsuszva kerul a pdfbe, ami nem igaz hogy mielott kiteszek valamit a netre nem ellenorzom elotte hogy sikerult-e a konvertalas vagy nem, /dehat biztos jott az ebedszuntet /

Ha az ODF Add-In-re gondolsz, az nem tudom, mitől közösségi. Az a Microsoft által pénzelt, vezetett és tervezett fejlesztés. Nyílt forrású, BSD licencű, szóval lehet küldeni patchet, de nem a "közösség" agyából pattant ki ez az ötlet. Egyelőre csak az ODT (OpenDocument Text) fájlformátum támogatása van napirenden a Word-höz. Ez egyébként működik is, próbáltam.

Az OOo még ennyire sem tudja az OpenXML-t (az elődjét, az Office 2003 XML-t igen), de a fejlesztés már itt is elindult. A Novell-Microsoft szerződés egyik pontja ez, és pont az ODF Add-In lehet ennek az alapja.

Ebben kételkedem, de az biztos, hogy az alkalmazkodás minősége nem minősíti az eszközt. Pláne, hogy egy undocumented formátumhoz próbál alkalmazkodni.
"találd ki, mi van a kezemben a hátam mögött? Nem, rossz, hülye vagy!" <- ez nem komolytalan egy kicsit? Amúgy a winword mikor fog natívan .pdf-et támogatni? Nem csak exportálni bele, szerkeszteni. Valószínüleg soha, mert csekély az esélye hogy az Adobe átadja a know-how-t.

Ave, Saabi.

Bezzeg az Asza rendszerben jól működnek a java programok. Semmi gond a lassúsággal.
Csak bírd kivárni, míg lejön egy update a gprs kapcsolaton. Vagy míg egy kattintásra reagál a rendszer.
Mondjuk egy választási próba előtti hétre időzítették a java futtatókörnyezet frissítését. Aztán csodálkoztak, hogy nem működik a program.
Amit a választási próba kapcsán csináltunk, arra én gyakorlatilag azt mondtam volna, hogy "ÖSSZEOMLOTT A RENDSZER".
De nem, voltak problémák a frissítéssel :-)

( szimszon | 2006. 12. 01., p – 14:43 )

Nekem wine-0.9.26:

wine: Unhandled exception 0x0eedfade at address 0x0000:0x7b83f430 (thread 0009), starting debugger...
First chance exception: 0xc0000025 in 32-bit code (0x7bc2fa48).
Register dump:
CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b
EIP:7bc2fa48 ESP:0033f734 EBP:0033f798 EFLAGS:00200282( - 00 - -IS1)
EAX:0033f740 EBX:7bc762c4 ECX:00110020 EDX:0033fb18
ESI:0033fb18 EDI:0033f7a4
Stack dump:
0x0033f734: 004050f4 00000000 0033fb88 c0000025
0x0033f744: 00000001 0033fb18 6f727265 00000000
0x0033f754: 7b007838 0033f9bc 01fe001a 7b8ae3e4
0x0033f764: 04098430 7b8b16bc 7b8b16cc 7bc762c4
0x0033f774: 00000003 7b8ae3e4 0033f7fc 7bc491ee
0x0033f784: 00000000 00000001 00000002 7bc2fa00
Backtrace:
=>1 0x7bc2fa48 __regs_RtlRaiseException+0x48 in ntdll (0x0033f798)
2 0x7bc6331b in ntdll (+0x5331b) (0x0033faf8)
<...>
13 0xb7e5a3b7 wine_switch_to_stack+0x17 in libwine.so.1 (0x00000000)
0x7bc2fa48 __regs_RtlRaiseException+0x48 in ntdll: subl $4,%esp
Modules:
Module Address Debug info Name (87 modules)
PE 400000-5e7000 Export abev
PE 63980000-6398c000 Deferred euvat
<...>
ELF b7e33000-b7e45000 Deferred libpthread.so.0
ELF b7e53000-b7f64000 Export libwine.so.1
ELF b7f66000-b7f7d000 Deferred ld-linux.so.2
Threads:
process tid prio (all id:s are in hex)
0000000a
0000000b 0
00000008 (D) N:\.wine\dosdevices\c:\Program Files\Abev 2006\abev.exe
00000009 0 <==

Szoval nem az igazi, el sem indul... :(