1
Sítě / Re:Interference Bluetooth a Wi-Fi na 2,4 GHz
« kdy: 14. 03. 2024, 17:40:49 »802.11n a jeho 40MHz pásmem
Díky, tohle přesně pomohlo. Teď to běhá naplno i se současně připojenou BT myší a sluchátky ..
Zobrazit příspěvky
Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.
Díky, tohle přesně pomohlo. Teď to běhá naplno i se současně připojenou BT myší a sluchátky ..
2
Sítě / Interference Bluetooth a Wi-Fi na 2,4 GHz
« kdy: 13. 03. 2024, 12:59:16 »
Zdravím,
na NTB mám kombinovaný adaptér WLAN/Bluetooth, nějaký bazmek od Realteku. Při zapnutí BT se WiFi 2.4G drasticky zpomalí, asi nic překvapujícího...
Otázka:
1. Dá se s tím něco dělat, kromě přepnutí na 5GHz ? Hádám, že asi ne, když BT přeskakuje v celém rozsahu 2.4G pásma, a tím pádem nepomůže přeladit WiFi na jiný kanál ....
2. Je to specifikum kombinovaných adaptérů? Funguje to líp u separovaných modulů?
3. Je to stejné i u ostatních značek nebo se to někde chová líp?
na NTB mám kombinovaný adaptér WLAN/Bluetooth, nějaký bazmek od Realteku. Při zapnutí BT se WiFi 2.4G drasticky zpomalí, asi nic překvapujícího...
Otázka:
1. Dá se s tím něco dělat, kromě přepnutí na 5GHz ? Hádám, že asi ne, když BT přeskakuje v celém rozsahu 2.4G pásma, a tím pádem nepomůže přeladit WiFi na jiný kanál ....
2. Je to specifikum kombinovaných adaptérů? Funguje to líp u separovaných modulů?
3. Je to stejné i u ostatních značek nebo se to někde chová líp?
3
Vývoj / Re:GDrive, vlastní .apk obsahuje virus
« kdy: 24. 01. 2024, 16:48:58 »
Ano, tohle jsem taky našel, ale není to tím, v releasu mám debuggable off. Právě naopak, musím debuggable zapnout, aby to fungovalo
4
Vývoj / GDrive, vlastní .apk obsahuje virus
« kdy: 22. 01. 2024, 17:38:29 »
Ahojte,
jako Java amatér jsem zkusil začít dělat i něco pro Android. Ubuntu, Android studio, všechno tak nějak ve výchozím stavu. Mám 4 různé aplikace se stejným nastavením projektu. U dvou z nich, když je zbuilduju jako release, tak Google Drive řve, že jsou zavirované (ty .apk soubory), debug není problém. Zbylé dvě fungujou i jako release.
Evidentně v tom nejsem na světě sám, ale řešení google nenabízí..
Podobná zkušenost? nějaký tip? Díky
jako Java amatér jsem zkusil začít dělat i něco pro Android. Ubuntu, Android studio, všechno tak nějak ve výchozím stavu. Mám 4 různé aplikace se stejným nastavením projektu. U dvou z nich, když je zbuilduju jako release, tak Google Drive řve, že jsou zavirované (ty .apk soubory), debug není problém. Zbylé dvě fungujou i jako release.
Evidentně v tom nejsem na světě sám, ale řešení google nenabízí..
Podobná zkušenost? nějaký tip? Díky
5
Vývoj / Re:Java DataInputStream - rychlost
« kdy: 23. 05. 2023, 16:25:30 »
Díky za podněty, z uvedeného mi přijde, že hypotéza ohledně JIT nejvíce odpovídá reálnému chování.
Celkem uspokojivě jsem to vyřešil pomocí toho ByteBufferu. Čím větší tím je to rychlejší (a blíží se výkonu MappedByteBufferu), ale zase se potýkám s konzumací až 2-násobného množství RAM, což začíná být významné u souborů přes 500MB. Takže jsem zvolil nějaký přiměřeně velký buffer.
Celkem uspokojivě jsem to vyřešil pomocí toho ByteBufferu. Čím větší tím je to rychlejší (a blíží se výkonu MappedByteBufferu), ale zase se potýkám s konzumací až 2-násobného množství RAM, což začíná být významné u souborů přes 500MB. Takže jsem zvolil nějaký přiměřeně velký buffer.
6
Vývoj / Re:Java DataInputStream - rychlost
« kdy: 21. 05. 2023, 10:58:07 »
Našel jsem řešení, tedy spíše workaround (příčinu stále neznám):
Namísto
Použít
takže to zřejmě souvisí s implementací metod readXxx() v DataInputStreamu, v tomto konkrétním případě DataInputStream.read(byte[] bytes) je lepší než DataInputStream.readFloat()
Namísto
Kód: [Vybrat]
DataInputStream dis = new DataInputStream(new BufferedInputStream(new FileInputStream(file)));
float[] pole = new float[size];
for (int i = 0; i < size; i++)
pole[i] = dis.readFloat();
Použít
Kód: [Vybrat]
byte[] bytes = new byte[4];
ByteBuffer buf = ByteBuffer.wrap(bytes);
for (int i = 0; i < size; i++) {
dis.read(bytes);
buf.rewind();
pole[i] = buf.getFloat();
}
takže to zřejmě souvisí s implementací metod readXxx() v DataInputStreamu, v tomto konkrétním případě DataInputStream.read(byte[] bytes) je lepší než DataInputStream.readFloat()
7
Vývoj / Re:Java DataInputStream - rychlost
« kdy: 19. 05. 2023, 19:36:28 »Citace
Je zpomalené čtení celého souboru, nebo třeba jen první čtení, nebo dokonce ještě před prvním čtením?
Načítám do paměti celý soubor, viz:
Kód: [Vybrat]
DataInputStream dis = new DataInputStream(new BufferedInputStream(new FileInputStream(file)));
float[] pole = new float[size];
for (int i = 0; i < size; i++)
pole[i] = dis.readFloat();
dis.close();
Tohle trvá napoprvé těch 15s. Opakovaně už jen 5s se stejným nebo jiným souborem, třeba i se stejnou kopií toho prvního. Chová se to stejně na Win10 + Java8 Oracle, Ubuntu 20.04 /22.04 + Java11 openJDK. Poměr času je zachován, na rychlejším stroji je to 5s vs 1.7s.
Ještě mě napadlo jestli to nějak nemůže souviset s tím, že to pouštím v samostatném vlákně skrze java.util.concurrent.Executor, protože dokud je to uvnitř vlákna tak i opakované čtení je pořád stejně pomalé, ale jakmile to spustím znovu (v samostaném vlákně) tak už je to OK ...
8
Vývoj / Re:Java DataInputStream - rychlost
« kdy: 19. 05. 2023, 13:04:42 »
OK díky, mrknu na to.
On by ten samotný ByteBuffer asi nakonec stačil, ale chtěl jsem využít mj. i DataInputStream.readUnsignedByte() a readUnsignedShort() abych se vyhnul ruční konverzi uint8 -> short a uint16 -> int. Předpokládám, že tyto vestavěné funkce jsou efektivnější než když to budu implementovat sám.. ale nakonec na výsledku uvidím
On by ten samotný ByteBuffer asi nakonec stačil, ale chtěl jsem využít mj. i DataInputStream.readUnsignedByte() a readUnsignedShort() abych se vyhnul ruční konverzi uint8 -> short a uint16 -> int. Předpokládám, že tyto vestavěné funkce jsou efektivnější než když to budu implementovat sám.. ale nakonec na výsledku uvidím
9
Vývoj / Re:Java DataInputStream - rychlost
« kdy: 19. 05. 2023, 10:02:43 »
Pomalé je první čtení celého souboru. Mám datové soubory velikosti stovek MB a různě s nimi pracuju. S prvním souborem trvá načtení třeba 15s, poté už okolo 5s. Kdybych to mohl udělat jednoduše přes read(byte[]) v BufferedInputStream a potom jako celek zkonvertovat skrze ByteBuffer, tak je to asi za 2s (vždycky). Ale chci/potřebuju využívat ty metody specifické v DataIntputStreamu. Každopádně 5s je OK, potřebuju urychlit těch 15s.
Co třeba pomůže je načíst nejdřív malý soubor (2-3 MB) předem a pak už i ten první velký jde rychle. Ale když jsem zkusil takové iniciální "předčtení" přidat automaticky k načtení velkého souboru (načíst nejdřív malou část a pak znovu všechno), tak to nepomohlo.
Shrnuto:
DataInputStream: nejprve 15s a dále 5s
BufferedInputStream: nejprve 2s a dále 2s
Ano, je to první IO volání po spuštění
Co třeba pomůže je načíst nejdřív malý soubor (2-3 MB) předem a pak už i ten první velký jde rychle. Ale když jsem zkusil takové iniciální "předčtení" přidat automaticky k načtení velkého souboru (načíst nejdřív malou část a pak znovu všechno), tak to nepomohlo.
Shrnuto:
DataInputStream: nejprve 15s a dále 5s
BufferedInputStream: nejprve 2s a dále 2s
Ano, je to první IO volání po spuštění
10
Vývoj / Java DataInputStream - rychlost
« kdy: 18. 05. 2023, 16:44:59 »
Zdravím a mám dotaz na zkušenější Javisty:
Načítám číselná data ze souboru (~ stovky MB) do pole v paměti. Data mohou být různého formátu (int8, uint16, float32, ... atd) a proto volám v cyklu DataInputStream.readWhatever(), podle toho co je zrovna potřeba, např. takto:
Všechno funguje, až na to, že první volání tohoto kódu po spuštění aplikace je asi 3x pomalejší než všechna následná volání. Nezáleží na tom, jestli čtu ten samý soubor znovu nebo úplně jiný. Chová se to stejně i když ten soubor načtu do byte[] a použiju ByteArrayInputStream. Paměti je k dispozici řádově víc než velikost pole.
Pokud v tomto konkrétním případě použiju
tak je to rychlostně OK, takže by to nemělo souviset s disk IO nebo alokací paměti, či co...
Načítám číselná data ze souboru (~ stovky MB) do pole v paměti. Data mohou být různého formátu (int8, uint16, float32, ... atd) a proto volám v cyklu DataInputStream.readWhatever(), podle toho co je zrovna potřeba, např. takto:
Kód: [Vybrat]
DataInputStream dis = new DataInputStream(new BufferedInputStream(new FileInputStream(file)));
float[] pole = new float[size];
for (int i = 0; i < size; i++)
pole[i] = dis.readFloat();
Všechno funguje, až na to, že první volání tohoto kódu po spuštění aplikace je asi 3x pomalejší než všechna následná volání. Nezáleží na tom, jestli čtu ten samý soubor znovu nebo úplně jiný. Chová se to stejně i když ten soubor načtu do byte[] a použiju ByteArrayInputStream. Paměti je k dispozici řádově víc než velikost pole.
Pokud v tomto konkrétním případě použiju
Kód: [Vybrat]
byte[] buf = new byte[size * 4];
dis.read(buf);
ByteBuffer.wrap(buf).asFloatBuffer.getFloats(pole);
tak je to rychlostně OK, takže by to nemělo souviset s disk IO nebo alokací paměti, či co...
11
Windows a jiné systémy / Re:Dešifrování dat na disku zašifrovaném BitLockerem
« kdy: 21. 04. 2023, 14:32:24 »
Jednou jsem měl přidělen služební ntb od externí organizace, která si strašně zakládala na bezpečnosti a ochraně dat. Přihlašování skrze HW token, dálkový přístup pro jejich admina. No, disk nebyl šifrován. Upozornil jsem na to a dostal jsem následující odpověď:
"Bitlocker je k ničemu, průměrný puberťák to dokáže prolomit dle návodu na Youtubu za 15 min. Klíčová je možnost ntb na dálku vymazat při nějakém incidentu"
Podototýkám, že jsem v tomto laik, nicméně tam, kde se můžu rozhodnout, používám bitlocker s PINem. Mám z toho tak nějak lepší pocit...
"Bitlocker je k ničemu, průměrný puberťák to dokáže prolomit dle návodu na Youtubu za 15 min. Klíčová je možnost ntb na dálku vymazat při nějakém incidentu"
Podototýkám, že jsem v tomto laik, nicméně tam, kde se můžu rozhodnout, používám bitlocker s PINem. Mám z toho tak nějak lepší pocit...
12
Odkladiště / Re:Zadaní telefonu při přihlášení do Komerčky
« kdy: 01. 04. 2023, 23:22:49 »
Ověření telefonního čísla je vyžadováno i při prvním přihlášení (na daném počítači/účtu) přes KB klíč.
V tomhle zásadní problém nevidím. Jestli to snižuje odolnost uživatelů proti podvrhu... těžko říct, jediná obrana je stejně jen poctivá kontrola adresního řádku s platným zámečkem...
Mnohem víc mě vadilo, když zrušili možnost hlásit se přes osobní certifikát + SMS, to byla poctivá dvoufaktorová (i když skoro třífaktorová) autentizace. U KB klíče mi ten nezávislý kanál prostě chybí.
V tomhle zásadní problém nevidím. Jestli to snižuje odolnost uživatelů proti podvrhu... těžko říct, jediná obrana je stejně jen poctivá kontrola adresního řádku s platným zámečkem...
Mnohem víc mě vadilo, když zrušili možnost hlásit se přes osobní certifikát + SMS, to byla poctivá dvoufaktorová (i když skoro třífaktorová) autentizace. U KB klíče mi ten nezávislý kanál prostě chybí.
13
Vývoj / Re:Příklad abstraktní třídy
« kdy: 26. 02. 2023, 10:35:08 »
Jako Java-amatér se zeptám: co přesně je na tom příkladu tak hrozně špatně? Že jsou tam jen abstraktní metody (jak píše p. Jirsák)? Kdyby tam bylo
tak je to OK?
můžete to nějak rozvést, třeba na jednoduchém příkladu? Resp. kdy je vhodné použít dědičnost a kdy ne?
Kód: [Vybrat]
abstract class Vehicle {
abstract void move();
abstract void accelerate();
protected void stop() {
// do something
}
};
tak je to OK?
Přesně tak, je chybou prezentovat dědičnost jako hlavní rys OOP. Snadno se s ní člověk dostane do úzkých.
můžete to nějak rozvést, třeba na jednoduchém příkladu? Resp. kdy je vhodné použít dědičnost a kdy ne?
14
Windows a jiné systémy / Re:Windows chce, abych si uložil EFS klíč, proč?
« kdy: 21. 11. 2021, 00:21:50 »
Ne, Win 10 Pro opravdu nešifrují automaticky :-)
BTW: při zapnutí nástroje Bitlocker Widle nutí uživatele uložit "obnovovací klíč nástroje Bitlocker" na externí médium, bez toho to nejde spustit. Pokud to chtělo zálohovat "EFS klíč" pak se nejedná o Bitlocker, ale asi nějaký encrypted-file-system pro šifrování jednotlivých souborů, jak je psáno výše ...
BTW: při zapnutí nástroje Bitlocker Widle nutí uživatele uložit "obnovovací klíč nástroje Bitlocker" na externí médium, bez toho to nejde spustit. Pokud to chtělo zálohovat "EFS klíč" pak se nejedná o Bitlocker, ale asi nějaký encrypted-file-system pro šifrování jednotlivých souborů, jak je psáno výše ...
15
Hardware / Re:Thinkfan na T430
« kdy: 20. 10. 2021, 09:24:44 »
Ale ono se to děje v době kdy se žádné úpravy otáček konat nemají. CPU má třeba 41st a každých pár vteřin se na chvilku roztočí větrák, zřejmě jako důsledek toho, že se to přepne do enabled módu ...
Zajímavé je, že ta četnost přepínání klesá s rostoucím limitem pro level 1. Když nastavím první úroveň na 55st, tak to dělá tak jednou za minutu, při 50st každých 10-15 vteřin, atd..
Zajímavé je, že ta četnost přepínání klesá s rostoucím limitem pro level 1. Když nastavím první úroveň na 55st, tak to dělá tak jednou za minutu, při 50st každých 10-15 vteřin, atd..
