Příspěvky

7381

Vývoj / Re:Ovládání hw z pc.

« kdy: 27. 12. 2012, 00:01:51 »

Tak jestli jsi na VUT, tak to nemáš daleko do Blanska, takže pokud bys chtěl, můžeš se za náma stavit na http://un-xovani.gosw.cz - momentálě si právě s mikrokontrolerama hrajeme, takže pomocná ruka by k dispozici byla a fantazii se meze nekladou
Termíny na leden ještě dohodnuté nemáme, ale kdybys měl zájem, můžeš se buť ozvat na kontaktní mail, nebo tu stránku sledovat, kdy se tam nějaký termín objeví. Nemělo by to dlouho trvat, ale obvykle to tam dávám na poslední chvíli

7382

Vývoj / Re:Ovládání hw z pc.

« kdy: 26. 12. 2012, 15:21:53 »

Ve třeťáku budeš podobné věci dělat v laboratořích předmětu IMP (http://www.fit.vutbr.cz/study/course-l.php.cs?id=107).

Jestli on není spíš na FIT ČVUT, když se zmiňuje o FEL

7383

Vývoj / Re:Ovládání hw z pc.

« kdy: 26. 12. 2012, 11:04:05 »

[offtopic - nic osobního]
Ach jo, tohle je přesná ilustrace toho, co nesnáším na našem školství - napereme do nich jakési pojmy, se kterými pak budou moci šermovat, ale všeobecný přehled v oboru, propojení všeho a ukázka, jak se to vlastně používá, na to už nám nezbyl čas ((
[/offtopic - nic osobního]

Co se týče přímého ovládání z počítače z normálního OS, tak k tomu nepotřebuješ psát drivery, stačí použít sériový nebo paralelní port a používat normálně přes soubory v /dev. Ale maximum, co s tím rozumně dosáhneš, je blikání s ledkou nebo třeba zapínání nějakých relé, generování analogového signálu apod. Tam tě nějaká ta milisekunda nezajímá. O nic víc v podstatě nemá smysl se snažit, protože pokud nemáš realtime OS, nedosáhneš správného časování i kdyby ses na hlavu postavil.

Takže na cokoli víc je nejlepší použít nějaký ten mikrokontroler, kterému budeš posílat jenom povely typu "zapni ledku 1", "posílej na výstup 2 hodinový signál s frekvencí 50kHz" apod. a to přesné časování už budeš řešit v tom mikrokontroleru, kde toho dosáhnout jde (např. i maličký čip ATtiny za asi 50Kč je schopný *softwarově* emulovat USB1 a s časováním celkem nemá problém). Mikrokontroler můžeš programovat v C/C++, takže žádný megahardcore to není. Existuje spousta knihoven, která z toho programování dělá v celkem trivialitu.

Co se týče výběru toho mikrokontroleru, AVR od Atmelu je asi docela dobrá volba, pokud nemáš důvod volit něco jiného. Já osobně bych spíš než Arduino doporučil JeeNode, který je postavený na stejném čipu (takže se programuje stejně, jsou k dispozici stejné knihovny), ale má tu výhodu, že výstupy jsou pěkně uspořádané tak, že můžeš připojovat různá zařízení a hezky je řetězit za sebe nebo vedle sebe, což s Arduinem dost dobře nejde. Nevýhodou je menší portfolio zařízení a trochu vyšší ceny (Číňani zatím JeeNode neobjevili...)

Stačí si koupit JeeLink (bezdrátový USB dongle) a jeden JeeNode - a můžeš krásně z PC ovládat cokoli bezdrátově.
Koukni: http://jeelabs.com/collections/all

Nebo pokud chceš co nejlevnější věc, tak asi tohle: http://dx.com/p/nano-v3-0-avr-atmega328-p-20au-module-board-usb-cable-for-arduino-118037

7384

Odkladiště / Re:Literatura k bezpečnosti systémů

« kdy: 24. 12. 2012, 08:41:49 »

Ja si myslim, je to o pochopeni otazky zakladniho principu. Nejlepsi knizky o unixu vysli v sedmdesatkach a jsou do dnes ve vetsine platne. Ve sve podstate se principielne nic moc nemeni, a pokud pochopis jak to fungovalo tenkrat a jak se vlastne bezpecnost vyvijeja da ti to lepsi pohled na ni jako na celek. Vetsina novych bezpecnostich prvku vychazi z vylepseni strarych mechanismu.

Já ti nevím...  Linux se dost překotně mění - a to bohužel bez nějaké viditelné koncepce a směru. Tohle, co píšeš, docela platí pro konzervativnější OSjako třeba FreeBSD, kde třeba FreeBSD - Podrobný průvodce síťovým operačním systémem je ještě pořád relativně použitelný, ale u Linuxu... ?

Co z před desteti třinácti lety bude ještě dneska pro Linux platit? Struktura /dev je jiná, audio subsystém je jiný, AppArmor i SELinux byly tehdy spíš experimentální záležitost, ACLs ještě pořádně neexistovaly, startovací skripty byly radikálně jiné (-> systemd), atd. atd.

7385

Vývoj / Re:Arduino a základy programování ve WIRE

« kdy: 24. 12. 2012, 08:25:57 »

Dobrý den , chci se zeptat jestli by byl někdo ochotný mi vysvětlit několik základů a zotpovědět mi několik otázek .. Arduino již vlastním , ale programování stále moc nechápu , hlavně struktury , logický a matematický operace .... nevím jak se používaj . Rozhodně bych se nebránil nějáký komunikaci po Skype , myslim že by to bylo i časově míň náročný a lepší. díky za jakou koliv pomoc

Pokud jsi někde z okolí Brna, tak bych pro tebe měl řešení.

7386

Distribuce / Re:Nainstalovaná aplikace

« kdy: 23. 12. 2012, 11:54:49 »

Stačil o trochu zagooglit, ale linux alternativa k Program Files je /usr/bin/

Je to trochu složitější. Různé distribuce to mají různě, některé binárky můžou být taky třeba v /usr/local/bin nebo /opt/<program>/bin.

Nejjistější způsob je zeptat se balíčkovacího systému, jaké soubory patří do daného balíčku a vyfiltrovat si řetězec "bin". Např. v archlinuxu takhle:

Kód: [Vybrat]

# pacman -Ql xterm | grep bin
xterm /usr/bin/
xterm /usr/bin/koi8rxterm
xterm /usr/bin/resize
xterm /usr/bin/uxterm
xterm /usr/bin/xterm

7387

Server / Re:Zle zobrazenie ceskych a slovenskych znakov na serveri(samba, ssh...)

« kdy: 21. 12. 2012, 19:47:22 »

Existuje, jmenuje se to enca

S texty délky názvů souborů to těžko může fungovat.

7388

Server / Re:Zle zobrazenie ceskych a slovenskych znakov na serveri(samba, ssh...)

« kdy: 21. 12. 2012, 16:32:22 »

A to je přesně jeho současný stav. Má tam "správné" soubory v UTF-8 a "nesprávné" v cp852 na jednom disku a chtěl by zautomatizovat převod. Já mu poradil ruční oddělení na "správné" a "nesprávné". Přijde mi to jako nejbezpečnější. Ale určitě to lze nějakým scriptem zautomatizovat, leč bez zálohy bych to raději nezkoušel, aby nepokazil i ty "správné".

No to by právě musel líp položit dotaz. Pokud má adresář, o kterým ví, že jsou tam jenom soubory v jednom určitým kódování, tak to není problém, pokud to potřebuje provést jenom jednorázově a nové soubory tohodle typu se mu tam už objevovat nebudou.

7389

Server / Re:Zle zobrazenie ceskych a slovenskych znakov na serveri(samba, ssh...)

« kdy: 21. 12. 2012, 16:16:49 »

Prostě codepage je UTF-8 ;-) však si rozumíme.

No ale to se týká jenom zobrazování (a řazení apod.) Netýká se to zapisování na disk. Klidně můžeš mít deset adresářů, v jednom mít soubory s názvy v UTF-8 kódování, v jiném s iso-8859-2 kódováním, ve třetím ...atd... Akorát teda jenom jeden adresář se ti bude zobrazovat tzv. "správně" - a bude to právě ten, který má názvy souborů kódovány tak, jak máš aktuálně nastavené zobrazování (locales). Takže můžeš klidně přepínat mezi deseti různými locales a postupně budeš vidět "správně" soubory v jednom z těch deseti adresářů.

7390

Server / Re:Zle zobrazenie ceskych a slovenskych znakov na serveri(samba, ssh...)

« kdy: 21. 12. 2012, 15:55:22 »

Jenom máš soubory na disku zapsané v kódování UTF-8.

Přesněji *názvy souborů* zapsané atd.

7391

Server / Re:Zle zobrazenie ceskych a slovenskych znakov na serveri(samba, ssh...)

« kdy: 21. 12. 2012, 15:52:42 »

Proto to teď oba systémy vidí špatně.

To těžko - ten, který to zapsal, by to viděl správně.

Ale nabízí se otázka, mám disk připojenej v UTF-8, ukládám na něj CP1250 bez konverze do UTF-8, jako co to uloží?

No to je právě to, o čem jsem psal - a zjevně nesrozumitelně, nebo nevím

Nemáš "disk připojenej v UTF-8". Jenom máš soubory na disku zapsané v kódování UTF-8.

ukládám na něj CP1250 bez konverze do UTF-8, jako co to uloží?

Můžeš si to vyzkoušet třeba pomocí toho Pythonu. Řetězec "čert" se v CP1250 zakóduje jako E8 65 72 74, zatímco v Unicode jako C4 8D 65 72 74:

Kód: [Vybrat]

 
>>> for b in bytearray(u"čert","utf8"): print "%X"%b
C4
8D
65
72
74
>>> for b in bytearray(u"čert","cp1250"): print "%X"%b 
E8
65
72
74

Takže pokud na disk zapíšeš soubor s názvem E8 65 72 74 a budeš se ho snažit dekódovat jako řetězec v Unicode, vyjde ti v tomhle případě (kurnik, příklad jsem zvolil blbě! neplatný utf-8 řetězec, který se nejspíš zobrazí jenom jako "ert" nebo "?ert":

Kód: [Vybrat]

>>> bytearray([0xe8,0x65,0x72,0x74]).decode("utf-8")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/encodings/utf_8.py", line 16, in decode
    return codecs.utf_8_decode(input, errors, True)
UnicodeDecodeError: 'utf8' codec can't decode byte 0xe8 in position 0: invalid continuation byte

7392

Server / Re:Zle zobrazenie ceskych a slovenskych znakov na serveri(samba, ssh...)

« kdy: 21. 12. 2012, 14:44:33 »

Mirku, teď teoretická otázka ... když si označí jeden ten otazník a nechá ho přejmenovat na správné písmeno, přejmenuje tím všechny otazníky, nebo jen ten správný? Myslel jsem třeba na Gwenrename ... to asi nevyjde, viď?

Gwenrename neznám. Ale s otazníky bych moc nepracoval - jako otazník se obvykle zobrazuje něco, co program neví, jak zobrazit. Takže jako (stejný) otazník se můžou zobrazovat různé odlišné znaky.

Já bych to udělal tak, že bych se prvně snažil zjistit, v jakém kódování ty názvy jsou. Pokud by se mi to nepodařilo, použil bych pro convmv nějaké nejbližší kódování - třeba to cp1250. A těch pár znaků, které by byly zmršené, bych napravil ručně napsaným skriptíkem, třeba v Pythonu. Je to prasárna, ale co, jinak to dost dobře nejde, pokud mám něco kódované neznámým způsobem.

Ještě by možná stálo za to zkusit kódování CP852 a iso-latin-2, ty se občas někde taky z různých důvodů můžou objevit.

7393

Server / Re:Zle zobrazenie ceskych a slovenskych znakov na serveri(samba, ssh...)

« kdy: 21. 12. 2012, 14:28:35 »

Já jsem přehlédl ten screen ... tady jedině ten convmv ... ale to jsi psal, že nepomáhá.

Jestli convmv mrší názvy souborů, tak mu byly předány špatné parametry (na disku je jiné kódování než jaké jsem mu zadal jako výchozí, popř. OS používá jiné kódování než jaké jsem mu zadal jako cílové).

...a to jsme právě u toho, že je potřeba vědět, jakým způsobem tam byly ty názvy vytvořeny. Ale to rado nechce řešit, tak to asi bude každá rada drahá

7394

Server / Re:Zle zobrazenie ceskych a slovenskych znakov na serveri(samba, ssh...)

« kdy: 21. 12. 2012, 14:18:39 »

Tak este raz sa pytam je mozne cp1250 prekonvertovat do utf-8. Neriesme to ako sa to tam dostalo...ale zaujima ma ako to prekonvertovat, nech to je vsetko utf-8....
Je to vlastne mozne? Dakujem

Píšu to nějak nesrozumitelně, nebo v čem je problém? Ptáš se mě, jestli jde název souboru změnit z "str[0x86]skrz" na "str[0x87]skrz"? Ano, to jde - říká se tomu přejmenování souboru.

7395

Server / Re:Zle zobrazenie ceskych a slovenskych znakov na serveri(samba, ssh...)

« kdy: 21. 12. 2012, 14:00:30 »

Nerozumieme sa, zle som sa vyjadril. Uzivatelia, ktori tam nahravaju subory maju windowsy, tam subory ktore sa modifikuju alebo vytvoria v tomto prostredi su v cp1250. Tento subor nahraju na server a server ho nevie spravne citat, kedze pozna len utf-8. cp-1250. Mozno keby som ich namountoval ako cp1250 slo by to, lenze problem je ze  na danom disku su aj cp1250 a utf-8. Takze najvhodnejsie by bolo vyhladat a prekonvertovat nazvy suborov z cp1250 do utf8. Ten convmv to robi presne ako si predstavujem problem je ze nevie zobrazit š a č a prepise ich nespravne.
Viete pomoct ako prekonvertovat cp1250 do utf8 a zobrazit vsetko spravne vratane š a č?

Já myslím, že já ti rozumím dobře. V opačném směru nevím, jestli není nějaký šum

Ještě jednou: zapsat název souboru v patřičném kódování musí ta aplikace, která soubory vytváří - protože OS prostě do názvů souborů nezasahuje - jak mu název aplikace předá, tak se zapíše na disk. "Uživatelé zapisují soubory" neznamená nic jiného, že spouští nějaký klientský program, který komunikuje s nějakým serverovým programem, kterému řekne "tady ti posílám soubor stčskrz" - když to "č" zakóduje jako 0x86 a serverový program ho nepřekóduje, tak se na disku vytvoří soubor "str[0x86]skrz". Když ho zakóduje jako 0x87, tak se vytvoří "str[0x87]skrz". Pokud klientský OS zobrazuje 0x86 jako "č" a serverové programy zobrazují 0x86 jako "ž", tak v serverových programech uvidíš soubor "stržskrz" a v klientských uvidíš "strčskrz". Na disku ale každopádně není nic jiného než "str[0x86]skrz".

Čili pokud ti jde opravdu jenom o zápis souborů přes scp z Windows, potom musíš problém řešit na úrovni scp - buď scp server na Linuxu, nebo scp klient na Windows musí názvy souborů správně překódovat. A pokud soubory potom čteš přes sambu, musí názvy zase samba překódovat zpět. OS do toho nijak nemluví a nemá s tím víceméně nic společného (kromě toho, že programům předává default formou locales).