Projekt reprodukovatelné openSUSE dosáhl významného milníku: proof-of-concept fork openSUSE se 100 % reprodukovatelně sestavitelnými balíčky.
Společnost Ondsel se snažila vylepšovat UX/UI FreeCADu a nabízet jej komerčně. Po dvou letech to ale vzdala. Pierre-Louis Boyer, bývalý zaměstnanec Ondselu, by rád pokračoval. Na YouTube představil soft-fork FreeCADu s názvem AstoCAD.
Aplikace pro blokování internetové reklamy v celé síti Pi-hole (Wikipedie) byla vydána v nové verzi 6. Přehled novinek a oprav v příspěvku na blogu.
Vývojáři počítačové hry Kingdom Come: Deliverance II (Wikipedie, ProtonDB) oznámili (𝕏), že za 2 týdny se prodalo 2 miliony kopií.
Společnost xAI založena Elonem Muskem na síti 𝕏 představila Grok-3, tj. novou verzi svého AI LLM modelu Grok.
Byla vydána nová verze 9.9p2 sady aplikací pro SSH komunikaci OpenSSH. Řešeny jsou 2 bezpečnostní chyby: CVE-2025-26465 (MITM pokud je zapnuta volba VerifyHostKeyDNS, ve výchozím stavu je vypnuta) a CVE-2025-26466 (DoS). Detaily na stránkách společnosti Qualys (txt).
Argentinský prezident Javier Milei čelí více než stovce žalob a trestních oznámení kvůli spáchání podvodu, protože na svých sociálních sítích propagoval kryptoměnu $LIBRA, jejíž hodnota se v krátké době znásobila a pak zhroutila.
Wayland Protocols byly vydány ve verzi 1.41. S dlouho očekávaným protokolem správy barev a High Dynamic Range (HDR).
Multiplatformní open source voxelový herní engine Luanti byl vydán ve verzi 5.11.0. Podrobný přehled novinek v changelogu. Původně se jedná o Minecraftem inspirovaný Minetest (Wikipedie) v říjnu loňského roku přejmenovaný na Luanti.
V stredu 19. 02. 2025 o 10:00h bude spustený jarný webinár zdarma. Na tomto webinári si ukážeme praktické ukážky monitorovania Prometheus endpointov s využitím nástroja Zabbix. Účastníci sa dozvedia, ako nastaviť a konfigurovať Zabbix na zber dát z prometheus exporterov vrátane vytvárania LLD pravidiel. Tento webinár je určený pre mierne pokročilých administrátorov Zabbixu. Registrácia na stránke: Axians Slovakia. Zoznam všetkých webinárov: Axians Slovakia webináre.
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.