Operátor O2 představil tarif Datamanie 1200 GB . Nový tarif přináší 1200 GB dat s neomezenou 5G rychlostí, a také možnost neomezeného volání do všech sítí za 15 Kč na den. Při roční variantě předplatného zákazníci získají po provedení jednorázové platby celou porci dat najednou a mohou je bezstarostně čerpat kdykoli během roku. Do 13. listopadu jej O2 nabízí za zvýhodněných 2 988 Kč. Při průměrné spotřebě tak 100 GB dat vychází na 249 Kč měsíčně.
Byly publikovány informace o útoku na zařízení s Androidem pojmenovaném Pixnapping Attack (CVE-2025-48561). Aplikace může číst citlivá data zobrazovaná jinou aplikací. V demonstračním videu aplikace čte 2FA kódy z Google Authenticatoru.
Free Software Foundation (FSF) spustila projekt Librephone, jehož cílem je vytvoření svobodného operačního systému pro mobilní telefony. Bez binárních blobů.
Byla vydána verze 7 s kódovým název Gigi linuxové distribuce LMDE (Linux Mint Debian Edition). Podrobnosti v poznámkách k vydání. Linux Mint vychází z Ubuntu. LMDE je postaveno na Debianu.
Byl vydán Mozilla Firefox 144.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Vypíchnout lze lepší správu profilů. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 144 bude brzy k dispozici také na Flathubu a Snapcraftu.
Discord potvrdil únik osobních údajů přibližně 70 000 uživatelů. Incident se týká uživatelů po celém světě, především těch, kteří v rámci ověřování svého věku nahráli do aplikace doklad totožnosti. Únik informací se netýkal systémů samotné platformy, ale došlo k němu přes kompromitovaný účet pracovníka zákaznické podpory u externího poskytovatele služeb.
Americká společnost OpenAI, která provozuje chatbota ChatGPT, kvůli výrobě vlastních procesorů pro umělou inteligenci (AI) spojí síly s firmou Broadcom. Firmy o tom informovaly (en) ve svém včerejším sdělení. OpenAI se snaží zajistit si výpočetní výkon potřebný k uspokojení rostoucí poptávky po svých službách. Akcie Broadcomu po zprávě výrazně zpevnily.
O víkendu 18. a 19. října lze na brněnském výstavišti navštívit s jednou vstupenkou dvě akce: Maker Faire Brno, "festival tvořivosti, vynálezů a bastlířské radosti", a GameDev Connect, "akci určenou pro všechny současné a hlavně budoucí herní vývojáře, kteří touží proniknout do jednoho z nejúžasnějších průmyslů na světě".
Do 20. října do 19:00 běží na Steamu přehlídka nadcházejících her Festival Steam Next | říjen 2025 (YouTube) doplněná demoverzemi, přenosy a dalšími aktivitami. Demoverze lze hrát zdarma.
O zavedení nástroje na monitorování online konverzací v rámci boje proti dětské pornografii (tzv. Chat Control) měli ministři vnitra rozhodovat na úterním společném zasedání v Lucemburku. Plán dánského předsednictví Rady EU ale před pár dny ztroskotal, když se ukázalo, že Chat Control nemá dostatečnou podporu.
Well I won't lie: quite a lot. This is a blogpost about an ANSI escape text user interface for a mobile phone ... made in the shell enhanced with elements from the object programming paradigm.
It all started with a PXA272 SoC based mobile phone (Let's teach penguin how to become magician 1 2 3). The SoC is really buggy. Usually I've had only one way of the control: an USB device network. The problem is the PXA272 USB device controller is really buggy so the USB network crashed a lot. How can you reset the controller if the only access to the system is over the crashed controller? One way is to use the phone keyboard itself, unless it has only 10 buttons (most of them are unusable for "typing") and a touch screen? You need to make a menu then!
There isn't much and X windows server mostly keeps failing, so only a terminal application based menus are available. The most obvious use is a ncurses based dialog and it has been used as the first implementation. The problem with ncurses+dialog is the size of hundreds of kB and they require gpm for the pointing device support. The dialog has a big graphical overhead for 30x40 character display (for 8x8 font, we could use 4x6 fonts, but dialogs with them are an ugly thing).
The gpm had another problem with a correct support for the touchscreen's absolute position reports. This itself disqualifies the full use of the dialog and there is a problem with the switching between two focusable groups. There is not enough buttons. Problem with gpm disqualified the scriptable menu drawing utility gpm-root too.
By using a dialog based menu I've realised an interesting fact. You can redirect output of any ncurses application (for example midnight commander) to any (even regular) file and later dump it back to terminal. So why should I use dialog and ncurses to draw an almost static UI when I can use a ansi escape dumpfile with highly compression ratio? Why do I even need to store a dumpfile when I can draw it dynamically? Why would I use this awesome interface to only reset an USB controller when I can build whole GUI with it?
The answer is here:
Almost everything in this version was hardcoded. Still, it already supported a reset of some controllers and a battery charging checks (first thing which dies with the undercharged battery is the USB device controller).
We gonna need a reference for ansi escape codes and some frame drawing characters. The wikipedia uses UTF-16, but the terminal uses UTF-8, we need to convert the values. The laziest way is to copypaste them from the wikipedia into your hexdump . You can store the following 3 bytes as a string for a symbolic naming. Using the native character should be possible (and the string will have only one quart length), but you may have problems with editing or parsing the source code and with debugging the shells without a valid unicode support. There shouldn't be problems with printing the string, so it should be safe, but still you really want to debug the string parsing functions in the shell source code?
c_form_h="\xe2\x94\x80"
c_form_v="\xe2\x94\x82"
c_form_tl="\xe2\x94\x8c"
c_form_tr="\xe2\x94\x90"
c_form_br="\xe2\x94\x98"
c_form_bl="\xe2\x94\x94"
Now we have the constant frame drawing symbols defined. Let's make more constant strings (readonly mode is enforced by the mind of a programmer, obviously):
c_form_h_arr="${c_form_h}"
c_form_h_arr="${c_form_h_arr}${c_form_h_arr}"
c_form_h_arr="${c_form_h_arr}${c_form_h_arr}"
c_form_h_arr="${c_form_h_arr}${c_form_h_arr}"
c_form_h_arr="${c_form_h_arr}${c_form_h_arr}"
c_form_h_arr="${c_form_h_arr}${c_form_h_arr}"
c_form_h_arr="${c_form_h_arr}${c_form_h_arr}"
c_form_h_arr="${c_form_h_arr}${c_form_h_arr}"
lazy to copypaste the constant string 2^n times. Some 10 lines of that should be enough for everybody (unless you want to fill 4k monitor with 4x6 font).
c_spaces=" "
c_spaces="${c_spaces}${c_spaces}"
c_spaces="${c_spaces}${c_spaces}"
c_spaces="${c_spaces}${c_spaces}"
c_spaces="${c_spaces}${c_spaces}"
c_spaces="${c_spaces}${c_spaces}"
c_spaces="${c_spaces}${c_spaces}"
c_spaces="${c_spaces}${c_spaces}"
same with spaces. Yeah and don't forget to use "{" and "}" or you gonna have the hell with a renaming. And now we can print a simple frame:
c_sizex=10
c_sizey=10
c_color="32;1"
echo -e "\x1b[${c_color}m${c_form_tl}${c_form_h_arr:0:$(((${c_sizex} - 2)*12))}${c_form_tr}"
i=1
while [ ${i} -lt $((${c_sizey}-1)) ] ; do
echo -e "\x1b[${c_color}m${c_form_v}\x1b[0m${c_spaces:0:$((${c_sizey} - 2))}\x1b[${c_color}m${c_form_v}"
i=$((${i}+1))
done
echo -e "\x1b[${c_color}m${c_form_bl}${c_form_h_arr:0:$(((${c_sizey} - 2)*12))}${c_form_br}"
I don't use printf as I've found inconsistencies between different shell implementations. Some may have problems with escaping the predefined strings. A raw unicode character could help, but the copying from the array is the place where an unicode unaware shell may differ from an unicode aware shell.
# xxx="╬"
# echo -n ${xxx} | xxd
00000000: e295 ac ...
# echo ${#xxx}
1
And mine configuration of the busybox shell would count bytes, but I don't remember if I configured all parts of the system with the unicode support.
If we want to print the frame somewhere in the middle of the screen we need to add "cursor position set" ansi escape code for every line. We can use the code "CSI n ; m H" (there are multiple ways):
while [ ${i} -lt $((${c_sizey}-1)) ] ; do
echo -e "\x1b[${c_row};${c_column}H\x1b[${c_color}m${c_form_v}\x1b[0m${c_spaces:0:$((${c_sizey} - 2))}\x1b[${c_color}m${c_form_v}"
i=$((${i}+1))
done
BTW the values of c_row and c_column are counted from 1 (yum), but you can incerment them in the string with an embedded $(()) expression.
The CSI for the color settings can set different attributes, which may or may not work on your terminal emulator. For example: the one for the framebuffer in the kernel cannot blink, you would have to write some scheduled rewriting in the kernel driver, but most of framebuffer drivers can increase the intensity and X server terminal emulators can do anything.
During the bugfixing I've started naming the versions by the letters of the greek alphabet. Let's see the β version:
Now the engine supported a directory based menu (and a "nice" hardcoded selection frame):
BTW I was able to chroot the whole system from an SD card into the RAM (because of my second crazy project).
By abusing the loadkey database I was able to type a simple command and run it in the terminal (with only arrows, enter and 2 more keys).
echo -e "keycode 169 = F70\nstring F70 = \"${KEYSTRING}\"" | /usr/bin/loadkeys - > /dev/null
In the Delta version I've manually colored all icons with the ansi escape codes:
and in the Epsilon I've started to rewrite the engine (for the first time) for more flexibility. Here is what happens when you make movable "window" in a shell:
BTW the engine should be called "ever rewrite engine" as we will see but I called it "Failsafe" (the irony was intended, but it was more stable than Xorg by that time).
In the next part we will take a look on the basic data manipulation in a shell.
If you have found this idea funny or you want me to rewrite the engine in a more sane language, consider a donate to my BTC adress: 1CqzWKDLdcbjbzvzkrcP5bHsScjm5CwcjH or to my ETH adress: 0x1440d31eD70fc6b084c71f03590F6e1d121C919E
Tiskni
Sdílej:
s/github/gitlab/g
nebo jinam…
"more stable than Xorg*" alebo tak niečo tam píšeš, nechce sa mi k tomu vracať :) Sorry ja som zástanca Xorgov a nemám rád kecy bez riešenia čo je na nich zlé :)To se přímo netýka bashe, ale spíš intel Xscale SoC architektury. V té době nefungoval pořádně touchscreen, Xka sežerou značnou část RAM a nevejdou se do 30MB ramdisku (takže je nelze spouštět bez SD karty), fluxbox má dost neefektivní stavový automat na obsluhu klikání, takže se špatně fungujícím touchscreen driverem to bylo nepoužitelné. Když umře nějakej driver, tak potřebuju vidět dmesg puštěnej ve smyčce, v tty konzoli to je přece jen robustnější. GTK se nedá použít na rozlišení menší než 640x480 (mám dojem, že to mají dokonce ve specifikaci UI layoutu, minimálně jsem musel ty layouty ručně upravovat, protože jsem jinak viděl jen výpis adresářů). Současně používaný matchbox ještě v té době pořádně nefungoval (je málo vyvíjenej) a občas segfaultoval. Stejně tak nefungovala virtuální klikací klávesnice (jsem musel najít až minulej rok, že se před x lety změnil server repa). Dále zapnutí Xek začne víc žrát baterku, takže je vyšší šance, že systém selže nadproudem (ani bych neměl v xkách aplikaci na sledování odběru z baterky). Intenzivní používání "grafického" "řadiče" ho může zablokovat. A finálně největší problém. GCC pro xscale negenerovalo validní instrukce a tak občas dostal ARM buď random kód a nebo instrukci z novější generace architektury (protože ARMv5TE nemá pořádnou podporu debuggingu, tak to vypadalo tak, že kód skáče náhodně po paměti a on nejspíš i občas skákal). Taky to znemožňovalo používat 16bpp xkový aplikace (ty instrukce se používají pro zoomování pixmap).
BTW, ja pouzivam Qt/QML i na miniaturnim monochromatickem displayi 128x64 OLED s radicem SSD1305. Mam tam dost podobne GUI, jako jsou screenshoty v zapisku (program slouzi k flashovani a otestovani zarizeni ve vyrobe, takova ozivovaci SD karta).
Vyhoda je, ze mam tim padem stejne vyvojove prostredi, at uz jsem na PC, dotykovem embedded zarizeni, i na tech nejjednodusich tlacitkovych zarizenich.
Přijde mi to dost nečitelné. Nepřemýšlel jsi o rozdělení na vrstvy bitmap (resp. spíš znakových map)?
text = " ╭──────╮ │ Ahoj │ │ 123 │ │ ... │ ╰──────╯ "; barvaPisma = " xxxxxxxx x x x aaaa x x bbbb x xxxxxxxx "; barvaPozadi = " dddddddd d cccc d d d d d dddddddd "; akce = " dddddddd daaaaaad daaaaaad daaaaaad dddddddd ";
A pak mít funkci, která ti to poskládá dohromady a vygeneruje ANSI sekvence. Ve zdrojáku by bylo na první pohled vidět, co bude na obrazovce. Dynamické hodnoty by se daly doplňovat prostým nahrazením textu (+x kontrola délky), např. bys tam měl {ppp}
a za to bys doplňoval hodnotu nabití baterie v procentech.
Další funkce by pak podle souřadnic zjistila akci a vrátila např. akci "a"
.
před prvním použitímJo to je ten problém, co popíšu v dalších částech.
# printf "AAA %.5s BBB\n" "${var2}"
but it does not copy five UTF-8 characters (with 3 bytes). It copies only 5 bytes (1 and 2/3 of an three bytes UTF-8 char).
In this situation "printf" doesn't have any benefits over "echo", but it has a disadvantage with the formatting string, which has to be complexly parsed. In the bash it doesn't really matter as the implementation overhead of a program with more features is bigger than the speed differences between echo and printf (= there are equally slow). In busybox there may be speed differences.
And you can opt to disable one of the busybox ash functions to gain a space for the binary so using only a dumb echo output could be seen as a benefit.
The rest of the "echo over printf" choice was most likely in my unwillingness to deal with the printf documentation as a _much_ more difficult stuff required my attention.