I've been prepping the language for inclusion into Fedora, but I would like some feedback on if things are truly working.
If you have any cycles to spare, I would really appreciate any testing of the packages. TIA!
> dnf copr enable mroche/hare
> dnf install hare
- Fedora 38
- Fedora 39
- EPEL 9
I work with Linux in Docker on the daily. And the people and machines I support have a blend of Intel/AMD and ARM/Graviton/AppleSilicon chips.
And the thing that bites me *regularly* is that different operating systems return different values for `uname -m`, even when they're the same thing.
* macOS uses x86_64 and arm64.
* Red Hat/Fedora/Amazon Linux family uses x86_64 and aarch64.
* Debian/Ubuntu family uses amd64 and arm64.
* Alpine Linux/Busybox family uses x86_64 and aarch64.
* Windows WSL2 returns whatever the underlying Linux installation is.
Combine that with different developers publishing releases on GitHub using a variety of names, and… it's quite the multi-dimensional matrix.
the #Osdev-Notes book has been re-releaased! With tons of typo fixes (sorry we didn't had a proofreader), and a new section on how to build a cross compiler! And we released a hardcover version too!!
Here the link: https://www.lulu.com/shop/dean-tuckey-and-ivan-gualandri/osdev-notes/hardcover/product-je5drpr.html
(if you look for the cheaper paperback version search it on lulu)
Yesterday I installed Fedora Server 38 for x86_64, QEMU/KVM allows running it with great performance, as if it were running directly on the hardware, but when I send the system to shutdown (I used the "halt" command in the console), it doesn't appear no more messages, the screen is completely black and does not turn off. Forced me to force shutdown by Virt Manager.
I would like to understand this, if anyone knows and can help me, I appreciate it.
Wrote a minimal UEFI bootloader for my OS project—because #GRUB is a monstrosity—initially with the intention of supporting only #x86_64. After getting it working, I noticed that there was almost no x86_64-specific code. Because I'm using #Zig all I had to do to recompile for #arm64 is modify a single line in build.zig. No fiddling with cross compilers or fucking with sysroots.
Lo and behold it worked perfectly (other than the fact that I didn't recompile my dummy kernel.elf for #aarch64). Zig might just have the most pleasant low level development and cross-compilation workflow I've ever worked with.
🔒 Red Hat Security Advisory 🔒
📦 Product: OpenShift Virtualization
🆔 Advisory ID: RHSA-2023:4420-01
📅 Issue date: 2023-08-01
🔍 CVE Names: CVE-2023-24540
Red Hat OpenShift Virtualization release 4.12.5 is now available, featuring updates to packages and images that address various bugs and provide enhancements.
🛡️ Security Impact:
This update has been classified as "Important" by Red Hat Product Security. For detailed severity ratings, please check the Common Vulnerability Scoring System (CVSS) base score for each vulnerability using the provided CVE link(s) in the References section.
OpenShift Virtualization is Red Hat's virtualization solution tailored for Red Hat OpenShift Container Platform.
This advisory contains OpenShift Virtualization 4.12.5 RPMs.
🔧 Security Fix(es):
For more information on the security issue(s), including the impact, CVSS score, acknowledgments, and other related details, please refer to the CVE page(s) listed in the References section.
To apply this update, including the changes described in this advisory, please follow the instructions at:
🐞 Bugs fixed:
- 2227593 - Tracker for 4.12.5 RPM
📦 Package List:
CNV 4.12 for RHEL 7:
CNV 4.12 for RHEL 8:
Spent part of my #RechageDay at #AMD looking at bootstrapping #TinyCC 0.9.26 from #GNUMes on #x86_64 architecture. And thanks to #Mes mantainer @janneke for his help with debugging various issues. We can now build initial #tcc binary and it can even run some simple commands such as --help or -vv.
Unfortunately, we still hit some critical bugs when trying to use this tcc binary to rebuild itself but hopefully we are not far now.
In fact my issues with it fall in three categories.
The relevant one is things still missing in #asahi itself:
- built-in #audio being disabled due to the overdrive protection stuff still missing (which is kinda meh for me anyway, I almost always use headphones)
- no #thunderbolt support, which is the only serious problem as far as I'm concerned, cause I like my keyboard and big monitor setup at home and really wish I could use it with asahi
- #suspending the laptop doesn't seem to work properly, since it keeps draining a bunch of power in that state, even though it's still less than if not suspended
There are a bunch of tiny annoyances that come from #sway and #wayland
- some tools I use on #i3/#X11 just don't have adequate analogies. It's mostly simple stuff like
fbxkb, but it still bugs me.
- #xwayland does lead to some things not working quite as expected, e.g. 1password's global shortcut actually doesn't work, so I need to go and click on it in the system tray to open it. I assume the underlying cause of this is also why the firefox 1password extension acts as a standalone thing, as if I don't have 1password installed separately.
- speaking of the system tray, it seems to be a serious hit and miss w.r.t. what will and what won't work
- the #clipboard is different. I have developed a lot of habbits around using
selection on X11 and the fact that that doesn't reliably map onto anything in wayland kinda bugs me, but I realize this is mostly a very me problem.
And then there's the fact that a bunch of stuff seems to not be distributed as an #aarch64 package. Especialluly packages on #AUR will almost always be marked as #x86_64 exclusive, even though downloading and building from source pretty much always works. I'm guessing that will be slowly getting better over time, especially if more non-apple
aarch64 laptops start going more mainstream.
TIL: Intel disabled the x86_64 v3 Microarchitecture level even on CPUs sold last year.
Previously I thought x86_64 v3 was implemented on CPUs since Haswell, that is about 2014. But now I found out the hard way (that is SIGILL) that they fused off instruction features like FMA and AVX even in Comet Lake (last 14nm generation) when the processor was branded as "Pentium" or "Celeron" (and not "Core").
That means it will take quite some time until distros can reasonably begin to ship binaries with x86_64 v3 as minimum requirement.
At least it seems they have now stopped this bullshit with Alder Lake.
Intel Suggests Dropping Everything But 64-Bit From X86 With Its X86-S Proposal - In a move that has a significant part of the internet flashing back to the innocen... - https://hackaday.com/2023/05/21/intel-suggests-dropping-everything-but-64-bit-from-x86-with-its-x86-s-proposal/ #computerhacks #x86_64 #intel #x86
@filippo is a wonderful follow. I’m grateful for him making this.
Also for some reason seeing it laid out like this made me think of them like they are the equivalent of the Linux Rules of Acquisition
What resources do people recommend for learning x86_64 and arm64 assembly? I was pretty comfortable with MIPS and 68k for those couple of semesters in college. Would love to know about modern tooling, too.
Eventual use cases: confirming proper optimization of C++ routines by the compiler (Godbolting?) and writing a few routines by hand.
Just finished RE-compiling #FFMPEG static binary from my bash script I used to compile #macOS #X86_64 & #arm64. I thought I had it solved yesterday. Ended up it worked on X86_64 to compile in #HDR10Plus and all relevant CPU optimizations, but something I did messed up ARM64’s compile - so it showed as no #NEON optimizations AND only 32-bit in the x265 section of ffmpeg!
I took the AppImage of EmulationStation Desktop Edition for x86_64 apart and added emulators if anyone is interested. I originally was just making this for myself, but decided to share it. No restricted ROM, BIOS files, or games are included.
I am trying to calculate factorial of 30 using x86_64 assembly on Linux. Here's my code:
mov %RCX, 1 # counter
mov %RAX, 1 # factorial result
cmp %RCX, n
n: .byte 30
I am converting it using these two commands:
ldd file.s -o a
However when running the executable `a`, segmention fault is raised. checking with gdb it seems that it is raised right at the first instruction after `_start`. Where am I wrong?
Any suggestion about Gentoo Linux?
I know Gentoo, but haven't used it that much.
Is Gentoo can be reliable for low spec's machine as long the program code isn't sucks right?
I want to use an old machine (2C/2T CPU with 3GB of RAM) to become reliable in my own production but still keep relevant to the newest certain software that I use.
I'm, okay to wait for the compilation as long it doesn't take for hours of time
Okay round 2- do you know of any x86_64 operating systems for desktops, laptops, etc, that *aren’t*;
Windows, Mac, Linux, BSD, ReactOS, Haiku, SerenityOS, Debian-Hurd, and Redox?
I’d like to expand my knowledge even further, please inform me if you know, or if I've missed anything!