#arm64

[netscapenavigator-official]

I successfully got Zorin OS 16.3 Core running on an ARM64 Machine. It's like 5 AM, and I'm literally writing this on the ARM Linux version of Firefox because I just needed to. It took me hours of just trying to read between the lines of vaguely related forum posts and doing my best, as someone who doesn't really consider themselves a Linux pro, but I eventually got something right, and now I have Zorin OS running on an M1 iMac via a UTM Virtual Machine, despite there being no official or unofficial ARM version of Zorin OS Core. Idk what to do with this knowledge, so I'm just letting everyone here know because idk what else to do, and I'm kinda excited it actually worked (and is working well) because I really wasn't expecting this to happen.

[zipp-os-official]

Starting Production🎉🥂

ZippOS is an alternate operating system for stand alone “spacial computing” devices. The goal of this project is to provide end users, who at their own discression, void their warranties to replace pre-packaged software bundled with their hardware. As the lead developer of ZippOS, and as an end user of a “spacial computer”, I am displeased with the current operating software, and the decisions of parent companies that distribute these products are inheriently unstable, brown-nosing share holders and consumers, and completely unaligned with the end users. As these devices are marketed as computers, I want to provide software for said computers as a choice for the end-users who feel the same as I do.

ZippOS will be a lighter(get it?), faster booting operating system built from scratch with Rust-Lang and some ARM/RISC-V assembly code to replace both the BIOS (ZIOS) and the operating system. The operating system’s goal is to have the same user functionality and multimedia multi-instancing in a mixed reality setting, citing BeOS/HaikuOS as inspiration. This operating system will have security and graceful degradation as the main focus for user safety because the main enemy for ZippOS is the companies who made the stock software it replaces on the end-user’s spacial computer. Users can also enjoy various stimulating options for navigating the software (i.e. “rolodex” style hub menus, table-top program/application storefront, “grabbing” and “throwing” programs/screens to be cast/mirrored to and from realspace and cyberspace, etc). ZippOS is a project software operating system under development, and currently has no plans to publicly publish to the open net, nor are there any current plans to open-source the software.

[itsjunetime]

I made another little blog post!

You can read it here, and it’s about trying out asahi linux, the new(ish) distribution of linux for arm macs. tldr; it works really well, honestly better than linux ever worked for me on intel macs, and imo anyone who has an arm mac should try it out.

this post is gonna be the first of 3 about trying out different systems - around this same time, i also made a small tool for cargo, rust’s package manager/build system, to help migrate configs between machines, and i also tried out nix. building the cargo tool wasn’t too bad, though there were some things about it that irked me, and nix was, to put it kindly, an experience i never want to go through again.

hopefully i’ll be able to get out the blog posts for those other two things, and yall can let me know your thoughts :)

[izder456]

My Experience Installing OpenBSD/arm64 7.6 on a 4GB Raspberry Pi 400

As any good OpenBSD user should, I read my platform's INSTALL notes; in the case of this machine, that is here: INSTALL.arm64.

I also read the arm64 page to see what would work and what wouldn't.

As per INSTALL.arm64 and the arm64 page, I needed the UEFI firmware from pftf on GitHub: Github page.

Following the README there, I put the correct files on an SD card.

Then, I downloaded the install76.img file for arm64 to my main machine.

Since OpenBSD's dd doesn't show progress, and using dd is unnecessary here, I opted to use pv to burn the img file to a USB drive. pv also gives a nice progress meter and estimated time:

# pv install76.img > /dev/rsdXc (where X is the drive I burned to)

Please read this "Cult of dd" post for more info on why the dd command is largely unnecessary in most cases.

After burning the drive, I put it in my Raspberry Pi, as well as another drive to install to. I used a SATA to USB 3.0 enclosure with a 250GB HDD inside.

I also put the SD card containing the pftf UEFI firmware in the SD card slot.

Additionally, I added a Chinaware USB Wi-Fi card with the urtwn(4) chipset, as I lack Ethernet connectivity at the moment so I could download the firmware if needed. In this case, all it downloaded was the bwfm(4) firmware.

I booted from the install USB with the UEFI firmware and went through the install process, which also downloaded the firmware for the bwfm(4) card for me.

I have a mini HDMI to VGA adapter since I don't have any HDMI monitors at the moment. Annoying Druaga1-esque hack, lol.

The install went fine, although the framebuffer & X11 resolution seemed to be incorrect after installing, which made everything sort of fuzzy- not optimal for my bitmap-doused setup.

For some reason, my monitor (ACER AL1916) doesn't properly set the resolution, even with more "standard" VGA devices like my laptop or a tower running OpenBSD. My initial reaction was to check the info in the monitor's OSD menu. It reported 1400x1050. Strange resolution; okay.

So, I went into the UEFI firmware SD card's config.txt and added:

framebuffer_width=1400 framebuffer_height=1050

Aaaaaaaand, everything was cut off.

FUCK.

It turned out the display is actually rated for 1440x900, and the info menu in the OSD was just showing what it received from VGA. Why? Idk, but it was incredibly annoying.

I eventually landed on some old forum that led me to these config options, which did work:

hdmi_group=2 hdmi_mode=47 hdmi_force_mode=1

So if any of you are trying to boot this UEFI firmware on this weird monitor with a Raspberry Pi 400, this is what you're looking for.

Then, I went through my dotfiles setup process, and nearly everything worked.

Dotfiles

Funnily, the bwfm(4) chip failed to load the firmware. I'm unsure if -current fixed this, and I don't plan to upgrade to -current on this machine. I'll report this to bugs@openbsd.org when I get more info on the situation.

Also, the sndio service doesn't see the sound card, as the only sound card on this hardware is HDMI out. Unfortunately, OpenBSD does not support HDMI audio yet, so this machine is mute for now unless I get a USB audio card.

I noticed that Xenocara is using llvmpipe graphics, which is expected as the arm64 page doesn't mention supporting the MALI chipset that this machine has. Despite this, picom and my usual StumpWM setup perform pretty well. Its on par for a netbook from the 2010s. It's not exactly zippy, but its fine enough for super lightweight tasks such as light programming via emacs, or reading/writing eMails using claws-mail. Firefox is a slog unfortunately, idk if there are any performance tweaks I could do besides what I've already done in my dotfiles, though.

Conclusion

So there you have it- my deep dive into getting OpenBSD up and running on the Raspberry Pi 400. It was a bit of a wild ride with its fair share of fuckery, but nothing too catastrophic. The framebuffer and resolution setup was a bit of a hassle, and I had some fucky moments- like the sound situation- but overall, the machine is functioning well and performing decently.

If you plan to venture down this path, just remember to be persistent and stubborn. I’ve heard that OpenBSD users perform best when matching stereotypes! :)

There’s a screenie of my RPi 400 system at the end of this post for the hell of it:

Happy hacking!

[teknolojihaber]

Windows 11 ARM iso

Windows 11 (kod adı: Sun Valley)Microsoft taraf��ndan geliştirilen Windows NT tabanlı Microsoft Windows ailesinin çıkan son sürümüdür. 5 Ekim 2021 tarihinde piyasaya sürülmüştür. Windows 11 sistem gereksinimlerini karşılayan Windows 10 cihazları için ücretsiz bir yükseltme olarak sunulmuştur. 64 bit iso: https://archive.org/ARM64.iso Read the full article

[thefossdog]

was poking around at things with fedora Linux asahi remix on the MacBook air m1 I just bought and quickly realized how many people just don't supply Linux arm builds!

I'm lurking in the oolite code rn to see what I can fix. I shall have oolite on Linux arm64

[govindhtech]

At Dual-Socket Systems, Ampere’s 192-Core CPUs Stress ARM64 Linux Kernel

Ampere’s 192-Core CPUs Stress ARM64 Linux Kernel

In the realm of ARM-based server CPUs, the abundance of cores can present unforeseen challenges for Linux operating systems. Ampere, a prominent player in this space, has recently launched its AmpereOne data center CPUs, boasting an impressive 192 cores. However, this surplus of computing power has led to complications in Linux support, especially in systems employing two of Ampere’s 192-core chips (totaling a whopping 384 cores) within a single server.

The Core Conundrum

According to reports from Phoronix, the ARM64 Linux kernel currently struggles to support configurations exceeding 256 cores. In response, Ampere has taken the initiative by proposing a patch aimed at elevating the Linux kernel’s core limit to 512. The proposed solution involves implementing the “CPUMASK_OFFSTACK” method, a mechanism allowing Linux to override the default 256-core limit. This approach strategically allocates free bitmaps for CPU masks from memory, enabling an expansion of the core limit without inflating the kernel image’s memory footprint.

Tackling Technicalities

Implementing the CPUMASK_OFFSTACK method is crucial, given that each core introduces an additional 8KB to the kernel image size. Ampere’s cutting-edge CPUs stand out with the highest core count in the industry, surpassing even AMD’s latest Zen 4c EPYC CPUs, which cap at 128 cores. This unprecedented core count places Ampere in uncharted territory, making it the first CPU manufacturer to grapple with the limitations of ARM64 Linux Kernel 256-core threshold.

The Impact on Data Centers

While the core limit predicament does not affect systems equipped with a single 192-core AmpereOne chip, it poses a significant challenge for data center servers housing two of these powerhouse chips in a dual-socket configuration. Notably, SMT logical cores, or threads, also exceed the 256 figure on various systems, further compounding the complexity of the issue.

AmpereOne: A Revolutionary CPU Lineup

AmpereOne represents a paradigm shift in CPU design, featuring models with core counts ranging from 136 to an astounding 192 cores. Built on the ARMv8.6+ instruction set and leveraging TSMC’s cutting-edge 5nm node, these CPUs boast dual 128b Vector Units, 2MB of L2 cache per core, a 3 GHz clock speed, an eight-channel DDR5 memory controller, 128 PCIe Gen 5 lanes, and a TDP ranging from 200 to 350W. Tailored for high-performance data center workloads that can leverage substantial core counts, AmpereOne is at the forefront of innovation in the CPU landscape.

The Road Ahead

Despite Ampere’s proactive approach in submitting the patch to address the core limit challenge, achieving 512-core support might take some time. In 2021, a similar proposal was put forth, seeking to increase the ARM64 Linux CPU core limit to 512. However, Linux maintainers rejected it due to the absence of available CPU hardware with more than 256 cores at that time. Optimistically, 512-core support may not become a reality until the release of Linux kernel 6.8 in 2024.

A Glimmer of Hope

It’s important to note that the outgoing Linux kernel already supports the CPUMASK_OFFSTACK method for augmenting CPU core count limits. The ball is now in the court of Linux maintainers to decide whether to enable this feature by default, potentially expediting the timeline for achieving the much-needed 512-core support.

In conclusion, Ampere’s 192-core CPUs have thrust the industry into uncharted territory, necessitating innovative solutions to overcome the limitations of current ARM64 Linux kernel support. As technology continues to advance, collaborations between hardware manufacturers and software developers become increasingly pivotal in ensuring seamless compatibility and optimal performance for the next generation of data center systems.

Read more on Govindhtech.com

[jannah-software]

DevOps with Artificial Intelligence, Automation, and Blockchain: Introductory Part 7

Video Highlights: This marks the conclusion of our introductory videos. Watching Jannah’s services come into ‘running’ state with the following command: kubectl get -w pods -A Counting the number of services that are up and running with: kubectl get -w pods -A | wc -l Take home points: We have Ansible Playbooks. The Playbook roles contain tasks to deploy our infrastructure to a K8…

[it-online]

Microsoft disponibiliza Windows 11 Insider Preview Build 25370

A Microsoft anunciou hoje, via Windows Blog, a disponibilização do Windows 11 Build 25370.1 no âmbito do Windows Insider Program, para todos os utilizadores cujos PCs se encontram registados no Canary Channel. Esta é a 3ª build da Active Development Branch a ser disponibilizada aos membros do Programa que entraram na ZN_RELEASE. Continue reading Untitled

[illuminarch]

FEX 2303 lançado para melhorar os jogos Linux x86_64 no ARM64

O FEX-Emu 2303 foi publicado nesta semana como a versão mais recente deste software de código aberto para desfrutar do software Linux x86 de 64 bits para executar normalmente no ARM de 64 bits (ARM64 e AArch64), incluindo jogos como Linux e o cliente Steam da Valve com Steam Play (Próton). O FEX-Emu tem desfrutado de grande sucesso e popularidade como um emulador rápido de modo de usuário…

[netscapenavigator-official]

While I hope the rumors about the Snapdragon X chips aren’t true, and they pave the way for widespread ARM64 adoption, I’m extremely hesitant about giving Qualcomm even more of a monopoly over the computers in our daily lives.

They already have a death strangle on the smartphone market. I really think they should keep their grubby hands off desktops.

[lichray]

Develop LLVM on Windows Dev Kit 2023

If you read the article Building LLVM in 90 seconds using Amazon Lambda in 2021, you might wonder whether you can do the same without the author's AMD Ryzen desktop. This blog will show you how I reproduce the results on a $600 ARM64 machine -- Windows Dev Kit 2023.

The software that offloads the compilation tasks to AWS Lambda is called "llama." I forked it to support ARM64. Everything to be discussed here will be using ARM64 -- Windows 11 ARM64, WSL that runs openSUSE Tumbleweed AArch64, Docker image that contains AArch64 binaries, LLVM that generates AArch64 codes, etc.

If you happen to use openSUSE Tumbleweed as well, you can check out the images I uploaded to Docker Hub: lichray/llama-gcc12 for GCC + gold linker and lichray/llama-clang15 for Clang + lld linker; the latter offers only libstdc++. As a jump start, let's give the GCC option a try.

First, clone https://github.com/zhihaoy/llama and switch to the aarch64 branch. Set the GOBIN environment variable to some PATH, go install ./... under the project root. Follow the Getting started guide carefully and bootstrap AWS resources for llama.

Next, make my Docker tag available on your local system with docker pull lichray/llama-gcc12:latest. Then you can create an AWS Lambda in your own account with llama update-function -create -tag lichray/llama-gcc12:latest gcc. The function name "gcc" is a llama default; we will change that when trying out Clang.

Everything is ready. I configure my llvm-project with the following:

env LLAMACC_LOCAL=1 \ cmake -G Ninja \ -DCMAKE_BUILD_TYPE=MinSizeRel \ -DLLVM_ENABLE_PROJECTS="clang" \ -DLLVM_USE_LINKER=gold \ -DCMAKE_C_COMPILER=llamacc \ -DCMAKE_CXX_COMPILER=llamac++ \ -DBUILD_SHARED_LIBS=YES \ -DLLVM_TARGETS_TO_BUILD=AArch64 \ -DCLANG_ENABLE_STATIC_ANALYZER=NO \ -DCLANG_ENABLE_ARCMT=NO \ -B build llvm

To simplify this small example, I didn't set up libc++. The full clang build finishes within 6 minutes with ninja -j 40 -C build/ clang

As you can see, there're warnings. For obvious reasons, the LLVM project guarantees warning-free only when building with Clang, so I'll set up a frustration-free LLVM dev environment next with Clang.

Create an AWS Lambda with my Clang image:

docker pull lichray/llama-clang15:latest llama update-function -create -tag lichray/llama-clang15:latest clang

Export an environment variable to change the Lambda function used by llama (you may want to save that in your shell profile):

# csh setenv LLAMACC_FUNCTION clang

Change cc and c++ commands to match what llamacc and llamac++ use from the image:

update-alternatives --install /usr/bin/cc cc /usr/bin/clang 30 update-alternatives --install /usr/bin/c++ c++ /usr/bin/clang++ 30

Now I can configure:

env LLAMACC_LOCAL=1 \ cmake -G Ninja \ -DCMAKE_BUILD_TYPE=MinSizeRel \ -DLLVM_ENABLE_PROJECTS="clang" \ -DLLVM_USE_LINKER=lld \ -DCMAKE_C_COMPILER=llamacc \ -DCMAKE_CXX_COMPILER=llamac++ \ -DBUILD_SHARED_LIBS=YES \ -DLLVM_TARGETS_TO_BUILD=AArch64 \ -DCLANG_ENABLE_STATIC_ANALYZER=NO \ -DCLANG_ENABLE_ARCMT=NO \ -B build llvm

200 seconds! It's totally not bad, as the original "90 seconds" article used the -O0 flag, which renders the resulting clang executable impractical to use in building clang checks or libc++ later.

And the build costs only 30¢. That is why I moved my dev environment to ARM64. ARM chips are inexpensive, even in the cloud (-20% cost overall). To take full advantage of that, all I did is to make my dev machine consume native artifacts from the cloud.

Caveats

WSL datetime can drift when the host sleeps, disrupting your cached AWS token. Read the comments in this issue to find a solution: #8204

AWS accounts that are new to Lambda have very low concurrency quota. Read this guide before requesting a quota increase: Lambda function scaling

[dandelionsprout42]

The Island Adventure Steam announcement couldn't have come at a worse time

Because,

It was announced less than 24 hours after I decided to never have to deal with "Wish me mell" ever again. I am not going to try to gift her every day for the next 48 days just to become able to complete the postgame's main questline. It took me more than 2 months just to get her to ❤15.

Less than 48 hours before the announcement did I begin thinking much more openly about which storefronts it'd be released for, since I don't like Steam as a whole; too much shovelware, weeb games, elitists, and Steam actively hampering PC gaming since the Steam elitists try to let them keep their monopoly.

So when https://store.steampowered.com/app/2495100/Hello_Kitty_Island_Adventure/ had its storepage made public earlier this morning, I felt pretty depressed about the 2 factors above. Even the 60fps that I had planned to applaud, absolutely dwindles in light of point 1 above.

(Image above is from the Steam page's gallery.)

Keep in mind, however, that I do not believe in the baffling conspiracy theories involving the upcoming "Give & Gather" event(s). A lot of people are screaming about the game making players who played in 2023 superior to those that began playing later, but that's a falsehood. It's whether they played during the 2023 "Give & Gather" event itself that matters.

[gizchinaes]

Actualización de Proton DLSS 3 de Valve aviva la especulación sobre las Steam Deck 2

Valve ha integrado recientemente el soporte para la tecnología DLSS 3 de Nvidia en Proton y SteamOS, lo que ha desatado especulaciones sobre la posibilidad de que un GPU de Nvidia forme parte del próximo Steam Deck 2. Además, la compañía ha comenzado a probar el soporte para ARM64 dentro de SteamOS, al mismo tiempo que surgen informes sobre el desarrollo de un nuevo sistema en un chip (SoC)…

[lizclipse]

so i knew it was faster, but i just compiled one of my work projects in the new macos vm i've set up and it is quite literally 2x the speed. i dont know how i havent tested this before, but it's kinda shocked me just how much quicker this thing is compared. i shouldnt be but i've not seen quite this kinda jump before

[virtuagf]

$ ./love-without-emergency-clementine-morrigan.zine --logging debug

~~DEBUG LOGGING ON~~

TITLE: LOVE WITHOUT EMERGENCY

AUTHOR: clementine morrigan

FLAVOR: discussion, polyamory, trauma, attachment, love

SEGMENTATION FAULT (CORE DUMPED)

$ gfdb love-without-emergency-clementine-morrigan.zine dump.core

virtua gfdb (Prawn 16.1-0prawn1~24.10.13) 16.1

Copyright (C) 2024 Virtua Girl Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.

Type "show copying" and "show warranty" for details.

This GFDB was configured as "arm64-linux".

Type "show configuration" for configuration details.

For help, type "help".

(gfdb) bt

#0 love_is_an_action ()

i enjoy the concept that love is an action, but disagree in a way that feels like its on the edge between "important" and "nit picky". i can't decide which.

love is a feeling but expressing it, experiencing it, or remembering it are actions, and so take time

through action, someone can stoke love in you, and you can stoke love in someone.

sometimes its the smallest action in the world, or sometimes its as simple as being reminded or a previous expression of love.

but even that takes time

time is what makes love limited

you are time bound, your partners are time bound

being time bound is not anyone's fault, its a requirement of existing

what we do with our time matters.

how we show and express our feelings of love matters.

you may spend time showing your love to someone in a specific way, but that action may not resonante with them.

not everyone is receptive to the same expressions of love, and often an expression of love to one person ends up feeling like the opposite to another person.

(i think conflicts like that are the basis of attachment theory?)

(gfdb) quit

$ tiv lovewithoutwmergency.jpg

$ exit

Connection to virtuagf closed