c0l0

I shared https://johannes.truschnigg.info/writing/2021-12_colodebug/ a while ago here - you might appreciate it for another means to make your bash scripts easier to understand while they execute.

I recently bought a low-end ASUS Tablet PC with a rather nice 13" OLED screen (Vivobook Slate 13 T3300), and exorcised Windows 11 S from inside it the moment I got it. I then installed the latest Fedora on it, and chose the GNOME spin, because of the supposed touch UI readiness.

I must say, I am not impressed by the UX of the whole setup... which is a shame, since they iirc slaughtered the perfectly good GNOME 2.x UI to cater to those devices specifically around a decade ago - and for what? If this is all that's there to reap, it's been a bad trade-off.

Looking forward to trying Plasma Mobile; maybe it can improve on the status quo.

"data loss solutions" is a term/product category I can totally get behind :D And indeed, there's planty of those in the IT industry!

That is highly interesting and contrary to a number of reports I've read about the Samsung 970 EVO Plus Series (and experienced for myself) specifically! Can you share more details about your particular setup and methodology? (Specific model name/capacity, Firmware release, Kernel version, filesystem, mkfs and mount options, any relevant block layer funny business you are conciously setting would be of greatest interest.) Do you have more than one drive where this can happen?

This happens for you after you invoked an explicit sync() (et al.) before the power cut?

Seeing the really just puny "provisioned IOPS" numbers on hugely expensive cloud instances made me chuckle (first in disbelief, then in horror) when I joined a "cloud-first" enterprise shop in 2020 (having come from a company that hosted their own hardware at a colo).

It's no wonder that many people nowadays, esp. those who are so young that they've never experienced anything but cloud instances, seem to have little idea of how much performance you can actually pack in just one or two RUs today. Ultra-fast (I'm not parroting some marketing speak here - I just take a look at IOPS numbers, and compare them to those from highest-end storage some 10-12 years ago) NVMe storage is a big part of that astonishing magic.

In my experience, LINPACK (at least the Intel MKL on GenuineIntel combination) is both quicker and more thorough in finding setups that are not actually stable/reliable.

... and where users are going to use it to do EVERYTHING in their daily digital lives, from doing financial transactions and accessing work email, to playing data-exfiltrating "free" games and surfing porn. And where the only actually viable location for backing up the data stored on it is some Big Tech conglomerate's cloud.

I agree it's pretty crazy.

I try to automatically compile a "recommendation ranking" for currently supported LineageOS devices from the official LineageOS wiki data, refreshed daily. It's available here: https://johannes.truschnigg.info/tmp/lineageos_device_toplis...

I recently upgraded from a used beryllium (Poco F1) with a dying battery to a used, but pristine dubai (Edge 30) and have been very happy with that choice.

At least for Qualcomm-based phones, make sure to have the phone's stock ROM provision IP Multimedia Services (IMS) with your MNO/ISP, so that (you increase your chances that) VoLTE/VoWIFI will work also with LineageOS.

Hey there Bhupesh - apologies for the snark! I was just venting some of the frustration I feel every day with modern "devops" tooling ;)

I am in a bit of a rush right now (which is why I try my absolute best to keep procrastinating on HN at the the absolute minimum, I swear! ;)), but I will try to share some insight later (potentially as a comment on your blog).

   [...]
   COPY --from=ugit-ops /usr/bin/tr /usr/bin/tr
   COPY --from=ugit-ops /bin/bash /bin/
   COPY --from=ugit-ops /bin/sh /bin/
   
   # copy lib files
   COPY --from=ugit-ops /usr/lib/libncursesw.so.6 /usr/lib/
   COPY --from=ugit-ops /usr/lib/libncursesw.so.6.4 /usr/lib/
   COPY --from=ugit-ops /usr/lib/libpcre* /usr/lib/
   COPY --from=ugit-ops /usr/lib/libreadline* /usr/lib/
   [...]

For me, insane sh*t like this proves that those who do not learn from distribution and package management infrastructure engineering history are condemned to reinvent it, poorly.

This is (slightly) wrong. ALL Socket AM4 Ryzen CPUs without an iGPU have working ECC support.

ONLY AM4 Ryzen APUs (i.e., CPUs with an iGPU) with the "PRO" infix in their name have working ECC support.

However, ALL AM4 platform ECC support also depends on the motherboard vendor/firmware. There are boards on which ECC simply will not work, no matter if your CPU and DIMM combination actually supports it. You have to check the mobo specsheet to make sure it does - ASUS and ASRock, for example, support ECC on most of their boards with a suitable selection of CPU/APU and DIMM.

To illustrate the CPU situation with a few examples:

  - Ryzen 5 3600 - proper, working ECC support possible.
  - Ryzen 7 5800X - proper, working ECC support possible.
  - Ryzen 9 3900X - proper, working ECC support possible.
  - Ryzen 5 5600G - no ECC support possible.
  - Ryzen 7 5700G - no ECC support possible.
  - Ryzen 5 PRO 5650G - proper, working ECC support possible.
  - Ryzen 7 PRO 4750G - proper, working ECC support possible.

Relevant article (2012): http://mikehadlow.blogspot.com/2012/05/configuration-complex...

I find it very amusing that most of the people who abhor dynamic linking of libraries and executables as an over-complex, error-prone mistake of computer history these days seem to have not the faintest trace of restraint when they're about to turn EVERYTHING into a RPC/RMI over complex, multi-layer (and I don't mean OSI), often completely proprietary and opaque network abstractions like there's no tomorrow.

The one number that should be of interest to anyone who's not a professional "growth marketer" is missing, though, don't you agree?

I skimmed the whole article, read your posting, and even though I know some of these words, I still have no idea if the decision was hurtful to the business, or if it did not move the needle at all, or if it even was a net positive, all things considered.

Someone needs to put on their robe and wizard hat and fix this properly :'(

... which does not refute the parent post's statement ;)

FTR, on modern-ish glibc-powered systems (in code that actually does use libc, and does not do its very own syscall-related thing instead), you will not find a single call to open(2) issued, in my experience. That's because the library functions shadowing these syscalls were rewired to use openat(2) under the hood.

    $ strace -e trace=open cat /dev/null 
    +++ exited with 0 +++


    $ strace -e trace=openat cat /dev/null 
    openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
    openat(AT_FDCWD, "/usr/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
    openat(AT_FDCWD, "/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
    openat(AT_FDCWD, "/dev/null", O_RDONLY) = 3
    +++ exited with 0 +++

Assuming semi-recent bash(1), you can also get away with something like

    while read -r line; do printf '%(%F %T %s)T %s\n' "-1" "${line}"; done

as the right-hand side/reader of a shell pipe for most of what ts(1) offers. ("-1" makes the embedded strftime(3) format string assume the current time as its input).

Palladium is coming again, and this time for real, with Windows 11 and its default "Secure"/Measured Boot (de facto) requirement - and all the infrastructure in place for Internet endpoints to attest that their peers have actually been booted that way.

Actually, yes, they did so also on (some) vendors' x86 firmware: https://www.omglinux.com/boot-linux-modern-lenovo-thinkpads-...

These default firmware settings will prevent "third-party"-MSFT-signed EFI binaries from loading - gee, I wonder why that distinction is suddenly necessary, too? :)

In my view and experience, the threat model that Secure Boot and similar schemes to establishing a root of trust to assure that "noone (esp. not the owner) has tampered with this device" tries to protect against is VERY rarely relevant (to the owner of said device). The times that I have been inconvenienced or even prevented by that stuff from getting the software I, the owner of the device, want installed onto hardware that I paid good money for at a store/vendor have been numerous, however.

Parts of the comment make a LOT of sense actually, when you look at shell scripts written by the uninitated. Often times, I see constructs like

    while [ 1 ]; do ...; done

which are a pretty clear indication of the author's misconception about the perceived nature of [ ], I think.

You are just lucky, and your hardware appears to be working without any problems ;)

Some/most(?) AM4 boards can enable "PCIe AER" (Advanced Error Reporting) in their firmware, which will tell you about stuff going awry while components are communicating over said bus (but every instance of PCIe error I have ever seen, even on rather faulty hardware, was recoverable/correctable), and rasdaemon will also persist those.

I do not know what "Memory errors" are supposed to be, since ECC-related problems will be dropped into the "MCE errors" bucket. Neither do I know what "Extlog errors" are.

I tried to test and control for that to the best of my ability, but ambient/operating temperature does not seem to be part of the equation.

Two sticks of Kingston 9965745-042.A01G

If you are working on the successor protocol of HTTP/1.1, and are not aware of Slowloris the moment it hits and every serious httpd implementation out there gets patched to mitigate it, I'd argue you are in the wrong line of work.

I am fully aware the module is not 100% working, i.e., it is faulty at a specific physical address. That's OK for my personal desktop though, unless the condition worsens, and UCEs (which will panic my kernel) follow.

Maybe slightly OT, since this concerns AMD older AM4 platform with a Zen3 APU core, but working ECC support looks like this and is definitely present on my system:

    $ sudo ras-mc-ctl --errors | tail -n5
    14 2023-08-20 20:16:41 +0200 error: Corrected error, no action required., CPU 2, bank Unified Memory Controller (bank=17), mcg mcgstatus=0, mci CECC, memory_channel=0,csrow=0, mcgcap=0x0000011c, status=0x9c2040000000011b, addr=0x36e701dc0, misc=0xd01a000101000000, walltime=0x64e31c78, cpuid=0x00a50f00, bank=0x00000011
    15 2023-08-23 17:17:49 +0200 error: Corrected error, no action required., CPU 2, bank Unified Memory Controller (bank=17), mcg mcgstatus=0, mci CECC, memory_channel=0,csrow=0, mcgcap=0x0000011c, status=0x9c2040000000011b, addr=0x36e701dc0, misc=0xd01a000101000000, walltime=0x64ea5188, cpuid=0x00a50f00, bank=0x00000011
    16 2023-09-03 16:52:15 +0200 error: Corrected error, no action required., CPU 2, bank Unified Memory Controller (bank=17), mcg mcgstatus=0, mci CECC, memory_channel=0,csrow=0, mcgcap=0x0000011c, status=0x9c2040000000011b, addr=0x36e701dc0, misc=0xd01a000101000000, walltime=0x64f4d227, cpuid=0x00a50f00, bank=0x00000011
    17 2023-09-15 21:37:59 +0200 error: Corrected error, no action required., CPU 2, bank Unified Memory Controller (bank=17), mcg mcgstatus=0, mci CECC, memory_channel=0,csrow=0, mcgcap=0x0000011c, status=0x9c2040000000011b, addr=0x36e701dc0, misc=0xd01a000101000000, walltime=0x65071ed7, cpuid=0x00a50f00, bank=0x00000011

This is with an ASRock B550M-ITX/ac and a AMD Ryzen 5 PRO 5650G. It used to work the same with a Ryzen 5 3600 (using a dedicated GPU for video output) before I upgraded the CPU.

To detect and log ECC activity on modern GNU/Linux, you will want to have the "rasdaemon" service active. I will decode MCE (and other hardware-related) errors and persist them to the database that is shown being queried above.

grml, the sysop powerhouse standing on Debian's giant shoulders, is my go-to distro for diagnosing/fixing all kinds of broken computery things for what has been much more than a decade. Be it hardware/hosts that are acting up, or broken GNU/Linux installations of all kinds - grml offers all the tools that can help make things right again (or at least arrive at the definite conclusion that stuff is FUBAR ;)).

We've recently started using its commercial sister project, grml-forensic (https://grml-forensic.org/) at work, and my colleagues in forensics love it!

I highly recommend everything the grml devs touch :)

Actually running a CA, even if only for private purposes, without certain regret down the road involves more than creating an OpenSSL cnf file, creating a root cert/key, and running with it. That said, it's a starting point. If you're looking to use more modern (i.e., faster) crypto than RSA keys, maybe check out my sping on a CSR generator wrapping `openssl`, available at https://johannes.truschnigg.info/code/tls_req_gen

If you need a self-signed cert instead, maybe try https://johannes.truschnigg.info/code/tls_cert_gen