Příspěvky

1

Studium a uplatnění / Re:Plat správce sítě v Praze (junior/medior)

« kdy: 07. 11. 2023, 13:08:01 »

Tady se dozvíš akorát to, že si musíš říct minimálně o 200 tis. jako zaměstnanec nebo 10 tis. CZK/MD jako OSVČ, protože dobrej síťař by za míň ani nevstal z postele.

Teď vážně... https://www.platy.cz/pruzkum-platu , nebo se zeptej nějakýho člověka, který dělá nábory IT lidí. Někoho mezi známejma nebo známýma známejch určitě najdeš. Je jich dneska mraky. Stejně nakonec budeš mít co si vyhádáš, ale k tomu dospěješ až s věkem. Nechtěj všechno hned.
Jestli máš dobrou angličtinu, tak jdi na 2-3 roky do zahraničí. Ne kvůli penězům, ale kvůli zkušenosti.
 

2

Server / Re:Správa infrastruktury pro webové aplikace

« kdy: 15. 10. 2023, 13:32:36 »

Vzhledem k tomu, že "kamarád" o technologiích jako Kubernetes, Docker, Terraform jen slyšel, tak bych se na Kubernetes v produkci zatím vykašlal. Šel bych cestou HA clusterů postavených třeba na Pacemakeru (Apache, Nginx... podle preferencí). Podobně i u databází (MySQL, Redis).
To je něco co člověk znalý Proxmoxu, Linuxu a PHP vytvoří myslím relativně rychle.

Tím bude standardizované prostředí, které podle mě poskytne požadované HA řešení a sníží i nároky na údržbu, čím uvolní čas pro učení se Kubernetu.

Pak bych prošel internet a hledal:
- Základy Kubernetes (deployment, údržba) -> Koukni třeba na Kubespray
- Specifika aplikací provozovaných na Kubernetu. Není to vždycky jen tak, že existující aplikace "se zabalí do Dockeru" a mám Kubernetes aplikaci.
- Zjistit, co je to CI/CD, jak automaticky provádět buildění a nasazování nových verzí. -> Mezi produky co sledovat jsou třeba Jenkins, Tekton, ArgoCD...

Ze začátku to bude trochu bolet, ale po nějakém čase už kamarád bude vědět sám jakým směrem jít. :-)

BTW. Pro produkční prostředí bych nepoužíval co zde zaznělo (1 control-plane + 1 worker). To totiž dost redukuje (odstraňuje) jednu z výhod Kubernetu co se týká vysoké dostupnosti a schopnosti se zotavit z pádu HV nebo VM na kterém Kubernetes běží.
Vše by mělo existovat minimálně dvakrát, ideálně 3x (z pohledu Kubernetu u aplikacích na něm běžících to může být jiné).

3

Desktop / Re:Reset do výchozího nastavení při každém restartu

« kdy: 22. 09. 2023, 06:26:24 »

Všem díky za komentáře.

Co se podívat na Fedora Silverblue? Nešlo by to přiohnout pro tvé potřeby?

To vypadá zajímavě, ale bohužel z různých důvodů je potřeba aby to byl Rocky 9. Pokud bude Silverblue existovat za pár let až se bude dělat nějaká revize, tak to určitě vezmeme v potaz. Díky.

Teď zkoušíme zkoušíme řešení, kdy se po restartu udělá snapshot, který se okamžitě zamerguje zpět. Jelikož jsou partitions aktivní, tak se ten merge odloží na dobu, kdy se deaktivují a reaktivují VG (po restartu). Všechny změny, které se tak po této události (zamergování snapshotu) stanou se při restartu zahodí. Jsou to 2 příkazy v cronu. Uvidíme, jestli to bude splňovat to, co chceme.

4

Desktop / Reset do výchozího nastavení při každém restartu

« kdy: 20. 09. 2023, 18:43:37 »

Ahoj,

Potřebuji na koncových stanicích (starý NB) provést deployment tak, aby se po každém restartu vyresetoval do defaultního nastavení. Nejde jen o nastavení uživatelské, ale o reset všeho.
Pár okolností:
- Nelze to dělat přes LiveCD, ani USB s live ISO.
- Musí to (reset) být možné bez přístupu k internetu, pouze za použití stroje jako takového (tzn. asi nejspíše z interního disku)
- Po deploymentu operačního systému se provedou ještě nějaké customizace specifické pro každý stroj, které musí být zachovány i po restartu.
- Řešení musí být upgradovatelné (aplikace security patchů, nebo nových funkcionalit)

Prozatím mě napadly jen LVM snapshoty. Kdyby nebyla potřeba ta upgradovatelnost, tak bych se asi spokojil s read-only partitions a nějakýma read-write partitions, kde je to potřeba (třeba /tmp).

Napadá ještě někoho něco jiného, řešil někdy někdo podobný problém?
Je to v zásadě něco jako kiosk, ale upgradovatelný na dálku.

Díky za náměty a nápady.

5

Studium a uplatnění / Re:Jak funguje remote práce v zahraničí?

« kdy: 09. 08. 2023, 12:13:58 »

... Ja si dokonce s pani z FU nekolikrat volal a na nejaky konkretni veci se primo ptal. Nemel jsem s danovym priznani nejmensi problem. ...

Tak tohle závidím. Já když skrz příjmy ze zahraničí volal na svůj FÚ, tak mi paní řekla, že na mě nemá čas, že si mám zeptat daňového poradce.

Jinak tu asi vše podstatné už zaznělo. V EU to je relativně jednoduché, mimo EU asi budeš potřebovat pracovní povolení, ohledně daní je potřeba vědět, jestli má ČR s danou zemí uzavřenu smlouvu o zamezení dvojího zdanění (ale u "civilizovaného světa" to jsou snad všechny).
Ohledně zdravotního pojištění. Zdravotně pojištěn můžeš být jen v jedné zemi. To co tu bylo zmíněno, že můžeš využívat zdravotnictví v obou zemích... To platí jen pro přeshraniční pracovníky, tzn. ty, co každý den/týdně dojíždí do domovského státu (nebo to tvrdí - zase záleží na pojišťovně). Když jsem dělal na Slovensku, tak to nebyl problém, ale v UK, nebo Irsku to samozřejmě nešlo.

6

Server / Při připojení SMB mountu dojde k zahlcení (High CPU) jádra

« kdy: 31. 05. 2023, 10:50:01 »

Pěkný den,

Potýkám se se zvláštním problémem.
Nastavil jsem cluster pomocí pcs, kde jsou 2 nody + quorum.
Jako resources mám:
- wildfly (systemd)
- virtuální IP
- 1. SMB mount (systemd)
- 2. SMB mount (systemd)

V /etc/fstab je následující záznam (+ jeden další se stejnou strukturou pro druhé SMB):

Kód: [Vybrat]

//protector/transmek   /home/jboss/mnt/protector/transmek    cifs  noauto,vers=3.0,_netdev,credentials=/etc/ucr/vu-d.crd,domain=zumn,uid=wildfly,noexec,nosuid,mapchars,file_mode=0664,dir_mode=0775,nounix,nobrl 0 0
Pomocí příkazu mount ho připojím bez problémů. Stejně tak pcs ho připojí a vše fungoju tak tak má. Až do nějaké doby, která je různá... Od 2 hodin po asi 20h (bohužel jsem nevypozoroval spouštěč).
Pak dojde k zahlcení/zacyklení procesu v jádře a zahlcení CPU.
Stroj přestane komunikovat s okolím a musí se natvrdo přeš konzoli restartovat.
V messages pak najdu následující záznamy.

Kód: [Vybrat]

May 30 22:10:00 konor1 systemd[1]: Finished system activity accounting tool.
May 30 22:11:20 konor1 pacemaker-controld[419997]: notice: State transition S_IDLE -> S_POLICY_ENGINE
May 30 22:11:20 konor1 pacemaker-schedulerd[419996]: notice: Calculated transition 196, saving inputs in /var/lib/pacemaker/pengine/pe-input-104.bz2
May 30 22:11:20 konor1 pacemaker-controld[419997]: notice: Transition 196 (Complete=0, Pending=0, Fired=0, Skipped=0, Incomplete=0, Source=/var/lib/pacemaker/pengine/pe-input-104.bz2): Complete
May 30 22:11:20 konor1 pacemaker-controld[419997]: notice: State transition S_TRANSITION_ENGINE -> S_IDLE
May 30 22:19:12 konor1 pacemaker-controld[419997]: notice: High CPU load detected: 3.990000
May 30 22:19:13 konor1 kernel: watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [kworker/0:0:1456407]
May 30 22:19:13 konor1 kernel: Modules linked in: tls nls_utf8 cifs cifs_arc4 rdma_cm iw_cm ib_cm ib_core cifs_md4 dns_resolver nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_
reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 rfkill ip_set nf_tables nfnetlink vsock_loopback vmw_vsock_virtio_transport_common vm
w_vsock_vmci_transport vsock sunrpc vfat fat intel_rapl_msr intel_rapl_common vmw_balloon rapl pcspkr vmw_vmci i2c_piix4 joydev xfs libcrc32c sr_mod cdrom ata_generic vmwgfx drm_ttm_helper ttm d
rm_kms_helper ahci syscopyarea sysfillrect sysimgblt fb_sys_fops libahci ata_piix sd_mod drm t10_pi sg crct10dif_pclmul crc32_pclmul crc32c_intel libata ghash_clmulni_intel vmxnet3 vmw_pvscsi se
rio_raw dm_mirror dm_region_hash dm_log dm_mod fuse
May 30 22:19:13 konor1 kernel: CPU: 0 PID: 1456407 Comm: kworker/0:0 Kdump: loaded Not tainted 5.14.0-284.11.1.el9_2.x86_64 #1
May 30 22:19:13 konor1 kernel: Hardware name: VMware, Inc. VMware7,1/440BX Desktop Reference Platform, BIOS VMW71.00V.18227214.B64.2106252220 06/25/2021
May 30 22:19:13 konor1 kernel: Workqueue: cifsiod smb2_reconnect_server [cifs]
May 30 22:19:13 konor1 kernel: RIP: 0010:native_queued_spin_lock_slowpath+0x21/0x30
May 30 22:19:13 konor1 kernel: Code: 82 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 66 90 ba 01 00 00 00 8b 07 85 c0 75 0d f0 0f b1 17 85 c0 75 f2 c3 cc cc cc cc f3 90 <eb> e9 e9 38 fe ff ff 0f 1f 84
 00 00 00 00 00 0f 1f 44 00 00 41 57
May 30 22:19:13 konor1 kernel: RSP: 0018:ffffb00087187d78 EFLAGS: 00000202
May 30 22:19:13 konor1 kernel: RAX: 0000000000000001 RBX: ffff9cdc14b62800 RCX: 000000364c970000
May 30 22:19:13 konor1 kernel: RDX: 0000000000000001 RSI: 0000000000000001 RDI: ffff9cdc14b60828
May 30 22:19:13 konor1 kernel: RBP: ffff9cdc14b60828 R08: ffffb00087187e38 R09: 0000000000000000
May 30 22:19:13 konor1 kernel: R10: ffffb00087187ce8 R11: ffff9cdc3594dc00 R12: 0000000000000000
May 30 22:19:13 konor1 kernel: R13: ffff9cdc14b60800 R14: 000000000000ffff R15: 000000000000ffff
May 30 22:19:13 konor1 kernel: FS:  0000000000000000(0000) GS:ffff9cdcb9c00000(0000) knlGS:0000000000000000
May 30 22:19:13 konor1 kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
May 30 22:19:13 konor1 kernel: CR2: 00007fa14a882000 CR3: 00000001ab010003 CR4: 00000000000606f0
May 30 22:19:13 konor1 kernel: Call Trace:
May 30 22:19:13 konor1 kernel: <TASK>
May 30 22:19:13 konor1 kernel: _raw_spin_lock+0x25/0x30
May 30 22:19:13 konor1 kernel: smb2_reconnect.part.0+0x3f/0x5f0 [cifs]
May 30 22:19:13 konor1 kernel: ? set_next_entity+0xda/0x150
May 30 22:19:13 konor1 kernel: smb2_reconnect_server+0x203/0x5f0 [cifs]
May 30 22:19:13 konor1 kernel: ? __tdx_hypercall+0x80/0x80
May 30 22:19:13 konor1 kernel: process_one_work+0x1e5/0x3c0
May 30 22:19:13 konor1 kernel: ? rescuer_thread+0x3a0/0x3a0
May 30 22:19:13 konor1 kernel: worker_thread+0x50/0x3b0
May 30 22:19:13 konor1 kernel: ? rescuer_thread+0x3a0/0x3a0
May 30 22:19:13 konor1 kernel: kthread+0xd6/0x100
May 30 22:19:13 konor1 kernel: ? kthread_complete_and_exit+0x20/0x20
May 30 22:19:13 konor1 kernel: ret_from_fork+0x1f/0x30
May 30 22:19:13 konor1 kernel: </TASK>
May 30 22:19:23 konor1 corosync-qdevice[933368]: Server didn't send echo reply message on time
May 30 22:19:34 konor1 corosync-qdevice[933368]: Connect timeout
May 30 22:19:41 konor1 kernel: watchdog: BUG: soft lockup - CPU#0 stuck for 52s! [kworker/0:0:1456407]
A to se neustále opakuje...
Přiznám se, že ani moc nevím, jak tohle debugovat. 
V corosync.log jsem našel toto (příklad z jiného dne):

Kód: [Vybrat]

I, [2023-05-22T09:57:32.101 #00000]     INFO -- : 200 GET /remote/get_configs?cluster_name=wildflycluster (10.10.51.46) 3.75ms
I, [2023-05-22T10:06:42.066 #00000]     INFO -- : 200 GET /remote/get_configs?cluster_name=wildflycluster (10.10.51.47) 4.13ms
I, [2023-05-22T10:06:42.271 #00012]     INFO -- : Config files sync started
I, [2023-05-22T10:06:42.272 #00012]     INFO -- : SRWT Node: konor2 Request: get_configs
I, [2023-05-22T10:06:42.272 #00012]     INFO -- : Connecting to: https://konor2:2224/remote/get_configs?cluster_name=wildflycluster
I, [2023-05-22T10:06:42.272 #00012]     INFO -- : SRWT Node: konor1 Request: get_configs
I, [2023-05-22T10:06:42.272 #00012]     INFO -- : Connecting to: https://konor1:2224/remote/get_configs?cluster_name=wildflycluster
I, [2023-05-22T10:07:05.272 #00012]     INFO -- : Config files sync finished
I, [2023-05-22T10:07:35.262 #00000]     INFO -- : 200 GET /remote/get_configs?cluster_name=wildflycluster (10.10.51.46) 7.95ms
I, [2023-05-22T10:16:42.015 #00013]     INFO -- : Config files sync started
I, [2023-05-22T10:16:42.016 #00013]     INFO -- : SRWT Node: konor2 Request: get_configs
I, [2023-05-22T10:16:42.016 #00013]     INFO -- : Connecting to: https://konor2:2224/remote/get_configs?cluster_name=wildflycluster
I, [2023-05-22T10:16:42.016 #00013]     INFO -- : SRWT Node: konor1 Request: get_configs
I, [2023-05-22T10:16:42.016 #00013]     INFO -- : Connecting to: https://konor1:2224/remote/get_configs?cluster_name=wildflycluster
I, [2023-05-22T10:16:42.016 #00013]     INFO -- : No response from: konor1 request: get_configs, error: couldnt_connect
I, [2023-05-22T10:16:42.016 #00013]     INFO -- : No response from: konor2 request: get_configs, error: couldnt_connect
I, [2023-05-22T10:16:42.016 #00013]     INFO -- : Config files sync finishedJako by server najednou ztratil síťovou konektivitu...

Mám ale jiný VM, kde je tento mountpoint se stejnýma parametrama připojen již několik dní a problém s tím není.
Stejně tak... Když na clusteru odpojím SMB mounty, tak tak běží dny bez problémů. 
Děje se to na obou nodech v clusteru, zkusil jsem i přeinstalovat VM a nic.

Setkal se někdy někdo s něčím podobným? Má někdo nápad co by to mohlo způsobovat?
Díky za jakékoliv postrčení.

7

Studium a uplatnění / Re:IT freelancer - pojištění odpovědnosti OSVČ

« kdy: 14. 04. 2023, 11:40:34 »

A neboj, projekt si vie vzdy pekne vycislit kolko ho stoji hodina lepenia zaloh dohromady aby mali znovu funkcny system.

Je někde k dispozici nějaký rozsudek, kde by se tohle řešilo (z českého prostředí)? Docela by mě to zajímalo, jak se k tomu přistupovalo.

BTW. Obnova ze záloh je jedna věc, ale větší problém je podle mě ušlý zisk nebo ztráta důvěry zákazníků, což jsou věci jež se kvatifikují poměrně složitě a rozhodně je ten dopad větší než jednotky MD vlastních či externích zaměstnanců na obnovu systémů.
Další věc je, že můžeš zapříčinit ztrátu důvěry zákazníka ve firmu kde pracuješ a to povede k ukončení kontraktu mezi zákazníkem a firmou kde pracuješ, což může být chápáno, že jsi způsobil škodu i firmě ve které pracuješ a ne jen u zákazníka.
To je spíše otázka na to jak by ta žaloba byla pojatá nebo co přesně kryje ta pojistka.

8

Studium a uplatnění / Re:IT freelancer - pojištění odpovědnosti OSVČ

« kdy: 13. 04. 2023, 15:16:50 »

Taky jsem se o něco takového před pár lety zajímal a nabyl jsem dojmu, že to je obecně v podstatě nepojistitelné. Kolegovi se před pár lety povedl průser na datech. Tam to mělo jít z pojištění odpovědnosti za škodu způsobenou zaměstnavateli, ale pojišťovna jen pomyslně ukázala vztyčený prostředníček.

Pojišťovák tenkrát neoficiálně naznačil, že kdyby s tím serverem zakopl na schodech a celý ho rozflákal, čímž by došlo ke ztrátě dat, tak by se s tím asi dalo něco dělat, ale takhle že ani omylem. Že by to bylo tolik fakticky neprokazatelných pojistných podvodů, že do toho nejdou.

Mám v zásadě stejnou zkušenost.
Pojistí tak rozbití, krádež, ztrátu NB, telefonu... Ale smazání dat těžko někdo pojistí.
Myslím, že by to všechno zamrzlo u soudu na tom, že by bylo hodně těžký vyčíslit tu škodu.

9

Studium a uplatnění / Re:HPP vs IČO

« kdy: 07. 02. 2023, 11:47:07 »

Co si ohlídej je smlouva, zde pozor na dvě věci:
- omez si ručení do výše škody třeba na 10.000 EUR apod.
- dej si podmínku že kontrakt můžeš vypovědět bez pokuty ihned pokud odběratel bude s prodlevou platby déle než 21 dnů

Dobrý point. Smluvní pokuta za zpoždění platby, případně ta výpověď, i když pokud je to velká agentura, tak ti řeknou ber naší smlouvu, nebo nic.
Ještě bych doplnil, že pokud to budeš mít jako jediný příjem, tak by bylo dobré si vytvořit rezervu, aby až se stane, že ti neproplatí fakturu v termínu, sis najednou nechodil půjčovat na svačinu.
Vymáhní těch plateb je pak kapitola sama o sobě.

10

Server / Re:Jaký Cloud Object Storage?

« kdy: 07. 12. 2022, 14:59:30 »

wasabi.com

11

Hardware / Re:Nový IBM mainframe Z16

« kdy: 25. 08. 2022, 18:59:12 »

Viete niekto, ako je realizované to prepojenie v rámci banky (analytici, okienkový pracovníci a ďalšie systémy)?
Sú to terminály priamo na ten mainframe, alebo používajú prístup cez iný server prostredníctvom nejakého API a pod.
A tiež, ako komunikuje s týmto systémom taký server internet bankingu?

K samotnému OS se dnes přistupuje pomocí emulovaného terminálu (např. 3270), pokud na mainframu běží linux, tak funguje normálně SSH. Jsou ale i projekty jako ZOWE (https://www.zowe.org/).
Pokud je řeč o tom co na tom běží, tak k databázím se jde připojit pomocí třeba JDBC a API jsou vystavena notmálně přes HTTP/S. Tam není moc rozdíl mezi mainframem nebo Linuxem. Řekl bych, že všechny běžně používané protokoly jsou implementovány i na mainframech, takže komunikace rozhodně není problém.

12

Hardware / Re:Nový IBM mainframe Z16

« kdy: 23. 08. 2022, 09:45:07 »

Já tam chodil v pondělí, ale on tam vysedával snad každý den. Kolem 8.-9. hodiny tam většinou býval. 
A je trochu divnej. Pije Heineken se Spirtem.

13

Hardware / Re:Nový IBM mainframe Z16

« kdy: 22. 08. 2022, 09:15:58 »

Pokud si to tom chete pokecat, tak v Irsku v Passage West do hospody zvané Glue Pot chodí chlap jménem Phil, který dělá System i support. :-)

Tak tohle je parada, a bude do te hospody chodit jeste i za 30 let :-)

Já myslím, že on jo... Byl (je) celkem pravidelný návštěvník. 
To to spíš zařízne IBM. 

14

Hardware / Re:Nový IBM mainframe Z16

« kdy: 22. 08. 2022, 06:45:53 »

Na mainframy tu byl odborník PowerLenin. Ten je tuším že i provozoval, ale je to už hodně dlouho co jsem o něm slyšel.
Hodně vlastností tu byl zmíněno, ale mainframe z/OS je oproti x86 opravdu trochu jiný svět. z/OS má třeba sysplex, což je věc, kdy více instancí OS na více strojích může pracovat jako jeden stroj. Dokonce si umí i sahat do paměti toho druhého. Na x86 existuje něco podobného pouze v IBM Db2 PureScale technologii (pokud i jinde, tak dejte vědět), kdy když padne jeden ze strojů v clusteru, tak ten systém umí dojet transakci na jiném nodu. Navíc všichni přistupují ke stejnému úložišti dat a ví co který nód clusteru změnil v datech a dokáží s tím pracovat, i když to ještě nebylo zapsané na disku a maj to zatím jen v paměti.
Pokud vím, tak v ČR je mainframů jen pár... Nebo spíš bylo. Pamatuji, že byly v Škoda Auto, ale pak je vyměnili za Powery, ale dnes už možná nemají ani to. Pak byl mainfraim v Třineckých železárnách, kde s tím tuším řídili výrobu. V Praze je pak CA a tam jsou taky lidi od mainframů, ale fyzicky tu možná žádný nemají.
Jestli jsou mé informace správné, tak v IBM ČR na Chodově už není nikdo, kdo by měl mainframy na starosti (technicky).
IBM System i se stále hojně použiván, hlavně v bankách z podobného důvodu jako Mainframy, ale je trochu více zaměřený na databáze, ostatně Db2 je jeho nedílnou součástí. Pozor ale, že Db2 na Mainframe, System i a Linuxu je úplně něco jiného. Jsou to 3 různé produkty, které mají společný jen název. Pokud si to tom chete pokecat, tak v Irsku v Passage West do hospody zvané Glue Pot chodí chlap jménem Phil, který dělá System i support. :-)
Maniframe určitě není a ještě dlouho nebude mrtvý, i když jsou snahy přesunout některé věci na Linux... Viz. IBM LinuxOne (https://www.ibm.com/products/linuxone-iii), který existuje už v 3. generaci. Jde tam získat i měsíční přístup na testování. https://developer.ibm.com/articles/get-started-with-ibm-linuxone/
Díky za připomenutí PUB400. Musím se podívat jestli mi přístup ještě funguje.

15

Hardware / Re:Zkušenosti s notebookem Schenker

« kdy: 01. 08. 2022, 10:21:39 »

Vlastním cca rok a půl Tuxedo Pulse 15, což je vlastně to samé jako zmíněný Schenker VIA 15 jen jiné logo. Budu se vyjadřovat k první generaci (AMD 4800H). Druhá je relativně nová, ale řekl bych, že rozdíl bude jen ve vnitřnostech.

- jak je to s celkovym zpracovanim : Tam asi v pohodě. Víko drží, nic nevrže, vůle kdekoliv bych řekl že nejsou. NB používám i ráno na klíně když jedu do práce, takže v autobuse si dost vytrpí, ale zatím v pohodě.
- co klavesnice: Je taková jiná, ale je to spíš o zvyku. Po tom roce a půl bych řekl, že žádný problém, ale dost používám externí klávesnici.
- pripadny zarucni problemy - Support je tragedie. Za cca rok a půl nedokázal poslat 3 klávesy, které blbě vypálili.
- koupe baterie napr za 4 roky - Po roce a půl: Designovaná kapacita 91,2Wh, v současnosti jsem na 87,8 Wh. V náhradních dílech baterii mají, takže koupit asi půjde.
- kvalita touchpadu - Řekl bych, že musím trochu víc přitlačit na kliknutí než na začátku, ale jinak asi OK.
- kvalita LCD - Používám to hlavně na práci v terminálu + web. Za mě v pohodě. Větší rozlišení (3840x2160) na externím monitoru (HDMI) to ale neutáhne (problikává). Rozlišení 2560x1440 ale jede v pohodě. Druhá generace má displayport a novější grafiku (AMD Radeon RX Vega 7 vs , takže to třeba bude lepší.
- kompatibilita s linuxem - Tuxedo má vlastní linuxovou distribuci založenou na Ubuntu. V tomhle v pohodě. Ze začátku byly nějaké problémy, že se čas od času z ničehož nic restartovalo GUI, některé klávesové zkratky (třeba na jas obrazovky) nefungovaly úplně na 100%, ale to už jsem teď delší dobu neviděl. Asi to odladili. Čas od času přijde nějaká aktualizace pro ovladače.

Z hlavních věcí má druhá generace displayport, úspornější CPU, lepší grafiku a 2 místa pro m.2 SSD místo jednoho. Až budu za pár let měnit NB, tak bych do 2. případně další generace šel, ale kvůli supportu bych zkusil spíše Schenker (třeba to bude stejné, třeba ne). Cena je v zásadě stejná. V případě záruky na 3 roky je Schenker o asi 100 EU levnější, ale u Tuxeda zase můžeš mít záruku až 5 let.