Příspěvky

31

Hardware / Šifrování disku: heslo vs. TPM chip

« kdy: 10. 01. 2019, 11:49:37 »

Zdravím,

jak byste srovnali bezpečnost šifrování disku pomocí LUKS s vyžadovaným heslem a automatickým odemknutím pomocí TPM chipu jako Bitlocker?
Mě přijde, že ve druhém případě všechno závisí jen na bezpečnosti přihlašování do systému, v případě zranitelnosti je celé šifrování k ničemu .. ?

Jak by to fungovalo v případě LUKS + TPM + single user mode ?

32

Bazar / Re:Darujte notebook za odvoz

« kdy: 07. 06. 2018, 12:27:35 »

Toshiba Satellite Pro 4300, P III - 600MHz, 576 MB RAM, 6 GB HDD, CDROM, FDD, 1x USB 1.0, PCMCIA, bez Ethernetu. Plně funkční. Odběr možný na Praze 2 v běžné pracovní době.

V případě zájmu směrujte dále komunikaci přes soukromé zprávy ať nespamujeme fórum.

33

Distribuce / Re:Nové Ubuntu už nemá šifrování složek?

« kdy: 02. 05. 2018, 14:37:24 »

Já tam čtu, že je hlavně "Buggy, under-maintained" .. tedy, že obsahuje chyby, které nikdo neopravuje a správci distra jej ani kvůli tomu nechtějí v repozitáři "main".

Takže dokud se situace nezlepší, je doporučeno použít alternativní možnosti, např. LUKS (který jde aktivovat taky během instalace)

ale jinak díky za postřeh, to jsem nevěděl tohleto, a při první příležitosti by mě to stálo zase spoustu času...

34

Vývoj / Re:Java: String constants a velikost bajtkódu

« kdy: 18. 12. 2017, 17:09:41 »

textova konstanta je public static final alebo private static final

1 bud robite generator bajtkodu ale to by sa taketo otazky nepytali
2 xor robite beznu aplikaciu a tam su taketo mikrooptimalizacie nahouby.

co z toho je pravda?

velkost bajtkodu zalezi od kompilatora / pouzivaneho jvm / pocasia vonku. /fyi java language specification nehovori nic o velkosti jednotlivych datatypes/

Používám samozřejmě final, to jsem zapoměl uvést.  Jedná se běžnou aplikaci a šlo mi hlavně o pochopení problému, jasně že mě těch pár stovek bajtů nezabije :-) Už jsem smířen s tím, že je to nutná daň za lepší udržovatelnost kódu.

35

Vývoj / Re:Java: String constants a velikost bajtkódu

« kdy: 18. 12. 2017, 17:01:09 »

Dejte to do nějaké třídy jako public static final konstantu.

Jo přesně takhle to dělám

zároveň nechci aby tím bytecode bobtnal nebo zpomaloval ...
Že to nechcete má nějaký důvod? Nebo je to jenom rozmar? Pokud k tomu nemáte nějaký dobrý důvod, neřešte to.

Přesně tak, rozmar. Prostě jsem čekal, že se to bude nějak chovat, a rozčilovalo mě, že je to obráceně a myslel jsem, že dělám něco blbě.  Každopádně jsem zas o něco chytřejší, takže díky.

36

Vývoj / Re:Java: String constants a velikost bajtkódu

« kdy: 18. 12. 2017, 16:11:45 »

Dobrý den, to jsou v podstatě dvě spolu nesouvisející věci.
a) existuje něco co se nazývá string constant pool. Stringy v Javě jsou immutable wrappery okolo char []. Toho se využívá k tomu, že Stringy se stejným obsahem odkazují na stejné char pole.
b) bytecode pro přístup k různým typům proměnných má rozdílnou délku v bytech. Přístup k lokálním proměnným produkuje (AFAIK) nejkratší (a nejrychlejší) bytecode.

OK, díky, teď už mi to dává větší smysl.

ak robite mikrooptimalizacie takymto sposobom...good luck...

dobře a jak to tedy udělat lépe?  Chci mít textovou konstantu přístupnou alespoň v podtřídách (protected) nebo ideálně kdykoliv a kdekoliv (public static) abych neměl tentýž řetězec naflákaný na padesáti místech kódu a zároveň nechci aby tím bytecode bobtnal nebo zpomaloval ...

37

Vývoj / Java: String constants a velikost bajtkódu

« kdy: 18. 12. 2017, 11:55:46 »

Ahojte,

nejsem žádný Javaguru, jenom jsem si trochu hrál s optimalizací  kódu a zarazilo mě, že pokud místo opakovaně použitého řetězce textu použiju konstantu-field (např. pomocí public static final String) tak se o poznání zvětší výsledný bytecode místo aby se zmenšil.  Při použití konstanty jako lokální proměnné se to dle očekávání aspoň nepatrně zmenší.

Co je příčinou? je tam nějaká režie podobně jako u dědičnosti (přesunutí společného kódu dvou tříd do nově vzniklé společné nadtřídy se "vyplatí" jen když je toho kódu dostatek) ?

38

/dev/null / Re:Proč nejít dělat vedoucího do Lidlu za 60000,- ?

« kdy: 14. 11. 2017, 09:15:12 »

Můj příbuzný, takový trochu duševní prosťáček, dělal dlouho v Lidlu. Poctivý pracant, dělal co se mu řeklo, bral přesčasy, záskoky, nechtěné svátky vč. štědrého dne a silvestra. Přišla krize a s ní pokyn propustit 10% zaměstnanců daného provozu. Co udělal manažer? Svolal si tuším tři zaměstnance  - včetně jeho - o kterých správně předpokládal, že nebudou klást odpor a dal jim podepsat výpověď dohodou. Podepsali - byli zvyklí poslouchat. Manažer zcela jistě získal bonus za dobře odvedenou práci, a to, že tím zcela jistě snížil průměrnou efektivitu práce na provozovně nikoho v centrále asi nezajímalo ...

39

Distribuce / Pomalý shutdown Xubuntu 14.04

« kdy: 19. 07. 2017, 11:35:58 »

Čaute,

mám tu jeden postarší notebook HP Compaq 610, Xubuntu 14.04.5 (Linux 4.4), všechno běží out-of-the-box, jenom mě rozčiluje, že těsně před vypnutím systému je asi minutu prodleva.

je to v okamžiku, kdy už jsou všechny procesy ukončené, filesystémy demontované, disk se vypne, větrák se netočí, na obrazovce svítí "reboot: power off" a čeká to asi minutu než se to vypne.

vygoogloval jsem akorát věci týkající se čekání na běžící proces a/nebo úplného zamrznutí systému, což ani jedno není tento případ. Zkoušel jsem i měnit nějaké parametry acpi v grubu, ale spíš se tím vždy něco jiného pokazilo než že by to v tomto pomohlo

díky za jakékoliv tipy

40

Software / Re:Thunar 1.6.10 crash on rename

« kdy: 09. 01. 2017, 10:17:51 »

hmm, tak to mas asi vse ok, je blbe ze me se to neprojevi... muzes provizorne na prasaka zkusit nainstalovat thunar a  thunar-data 1.6.10-1~14.04 z toho ppa, rucne stahnout a naistalovat pres dpkg -i thunar*deb
alspon to sem v Xubuntu 16.04 vyzkousel, projde to ok (je potreba i thunar-data), pousti se ok, prejmenovava ok...

Zkusil jsem a nepomohlo - takže tahle konkrétní binárka funguje ve starší verzi distra a v nové ne ...  bůhví kde ta chyba teda vlastně je.

PS
nakonec to u mě dělá na všech kompech, včetně toho jednoho co jsem si myslel, že ne - jenom mnohem méně často, cca 1x za 20-30 pokusů. Na ostatních to zreprodukuju spolehlivě do 5 opakování. Kolega je na tom stejně na 3 strojích ze 3.

41

Software / Re:Thunar 1.6.10 crash on rename

« kdy: 08. 01. 2017, 10:56:00 »

predpokladam ze si v realu nenapsal jen patch

jasně že ne :-), taky jsem si ověřil, že se ten patch správně aplikoval

ze se zkompilovana binarka od te z balicku lisi nic neznamena
over, ze opravdu pouzivas ten zkompilovanej

sorry, měl jsem na mysli ručně kompilované verze s a bez patche. Spouštěl jsem to samozřejmě z konzole, abych věděl co pouštím (/usr/local/bin/thunar), "deaktivoval" jsem distribuční verzi: chmod -x /usr/bin/thunar, pak jsem to ještě v zoufalství nainstaloval do /opt/..

42

Software / Re:Thunar 1.6.10 crash on rename

« kdy: 07. 01. 2017, 13:44:31 »

Je zajímavé, že na některých kompech to nedělá (to je taky známo), např. u mě na jednom z pěti. Ale na všech ostatních to padá stejně - cca jednou za 3-5 pokusů, někdy klidně hned napoprvé.

Zatím to řeším výměnou za PCmanFM, což jde v Xfce naštěstí triviálně, ale irituje mě nefunkčnost toho patche, když se celý svět oficiálně tváří, že to funguje. Kdyby byl někdo komu se to povedlo zrekompilovat funkční, tak to by mě hrozně zajímalo. Možná dělám někde chybu, ale tady není skoro kde - vše jede naprosto standardní cestou:

patch
./configure
make
sudo make install

binárky se přiměřeným způsobem liší, všechno tak nějak sedí, ale nefunguje to

43

Software / Thunar 1.6.10 padne při přejmenování souboru

« kdy: 06. 01. 2017, 13:13:11 »

Čaute,

bojuju s aktuální verzí Thunaru, který je mj. přítomen i v aktuální LTS verzi Xubuntu 16.04.  Obsahuje brutální bug - náhodný častý segfault při přejmenování souborů, a možná i dalších operacích. https://bugs.launchpad.net/ubuntu/+source/thunar/+bug/1512120

Bug je známý, popsaný, neopravený, nicméně existuje oficiální patch a po Netu x-krát opakovaný návod jak si opatchovat, zrekompilovat a jak to pak krásně funguje. Děkující a oslavné komentáře. https://git.xfce.org/xfce/thunar/commit/?id=029012f4c39d9d3d9ae617491a69f76f54a4192f

Ale mě to prostě nefunguje. Zkoušel jsem to opakovaně a na různých počítačích, ale ta opravená verze se chová úplně stejně blbě jako originál.

Hoši z Xfce přiznávají, že ten patch neodstraňuje problém 100%, ale že tu situaci výrazně zlepší. Ale u mě se to nezlepší ani trochu.

Zkoušel jste to někdo?

44

Distribuce / Re:Ubuntu 16.04 a linux-firmware-nonfree

« kdy: 02. 05. 2016, 13:49:42 »

nene, testoval jsem novou verzi na čisto

balíček byl až do předchozí verze součástí repa multiverse, a teď prostě není. Ani ty soubory v něm obsažené nejsou rozmixované v jiných balíčcích. Jediné co jsem vygoogloval je, že na

http://www.ubuntuupdates.org/linux-firmware-nonfree
píšou
WARNING: the "linux-firmware-nonfree" package was deleted from this repository (multiverse, 16.04)

no uvidíme, třeba je to jen dočasná záležitost

45

Distribuce / Ubuntu 16.04 a linux-firmware-nonfree

« kdy: 02. 05. 2016, 10:29:25 »

Ahojte,

nevíte proč byl z nejnovějšího LTS odstraněn balíček linux-firmware-nonfree? Zdá se, že docela nedávno a zdá se že to zatím ani nikomu nevadí, i když bez toho nejedou různé TV tunery apod.

Ne že by byl problém (zatím) dostat tam starší verzi balíčku nebo příslušný firmware postahovat někde ručně, ale to asi není systémově korektní řešení ...