mappu

https://github.com/ying32/govcl is a binding of the Lazarus LCL GUI library to Go. It works pretty well, although I really got the impression that GTK2 and Win32 were the best supported targets, anything more modern was pretty buggy, so don't rely on it for hidpi support.

The Radxa Orion O6 we're talking about is not server hardware, but they did implement ServerReady UEFI firmware anyway, and it does allow anything to boot. In the article they booted unmodified, upstream Windows and Linux distro ISOs.

Being right at the wrong time, is the same as being wrong

Which is a shame, a modern SoC is fast enough to emulate 32-bit in userspace with same-or-better performance than the real 32-bit SoCs from that period.

I think the old Office 97 Shortcut Bar preloaded some Office dlls too, maybe not all of them.

I wonder if Zhaoxin's VIA heritage is helping them or holding them back - because of the patents, they were the only ones allowed to try, but since x86_64 and SSE2 are both now more than 20 years old, most of the patents don't matter any more (and AVX is not far from the cutoff).

The breakaway ARM China or SpacemiT or Loongson could drop in an x86_64 frontend and might get better results.

A charitable explanation could be - they intend to reuse the numbering scheme and don't want confusion in search results

> However, its early days.

Theia has been out for eight years now,

I have a mix of SMR and CMR drives in my NAS and it works perfectly (on mdadm). I understand ZFS hates it but what is the problem on Synology?

My /usr/share/dict/words offers Clojure, cajolery, and jocular[ly/ity]. Jocular's not bad.

All that work (AGX acceleration...) is done in llama.cpp, not ollama. Ollama's raison d'être is a docker-style frontend to llama.cpp, so it makes sense that Docker would encroach from that angle.

Echoing this. At $DAYJOB some 5-10% of customers will fail to initiate a websocket connection, even over wss:// despite plain HTTPS requests working fine. This is a client-side issue with whatever outdated HTTP CONNECT implementation the enterprise has.

Android (all apps sandboxed). Desktop OSes are still barely catching up to this one.

The MIT license spells this out extremely clearly IN CAPITAL LETTERS. It's actually really refreshing to read.

> this was called “tivo-ization” at the time, because TiVo did it.

It's not widely known but what TiVo actually did was something different than this, and both RMS and the SFC believe that both the GPLv2 and GPLv3 allow what TiVo actually did. Some discussion and further links via https://lwn.net/Articles/858905/

I know it was just an example, but https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-... definitely stopped me doing separate first and last name columns.

In New Zealand we are also phasing in eInvoicing using Peppol BIS 3.0, which complies to EN 16931.

In 2005 the hot new Windows technology was .NET Framework 1.1 or 2.0. You can't just dump Framework 1.1's libraries next to the binary and expect it to work either, it needs to be installed properly.

I think this attitude to the Linux ABI is maybe out of date - with a 20 year old Linux binary, that's only 2005, so it will almost certainly be using glibc (no archaic libc5). Glibc has great backwards compatibility and the binary will work on any glibc distribution today as long as you have all the .so's, same as needing the .dll's on Windows.

Is any language immune from that?

ToaruOS has an ARMv8 port: https://github.com/klange/toaruos and Serenity has an ARM and RISC-V ports: https://github.com/SerenityOS/serenity ; although I think you would call them Unix-like.

Haiku has tier-2 ports to ARM, RISC-V, and SPARC: https://www.haiku-os.org/guides/building/port_status

ReactOS has an ARM32 port but the ARM64 one is not usable yet.

Skift apparently runs on ARM and RISC-V: https://skiftos.org/

netatop is not in Debian, and the atop package doesn't include any .ko files.

Ubuntu (via Debian) already had a system for this in `update-alternatives`, which is almost certainly already installed on this person's system.

Would it be possible to toggle coreutils/uutils via that instead of reinventing it? They're both effectively symlinks-managers.

It also has an address-of operator, you can take the address of the middle of a large array.

I suppose that would be possible with fat-pointers that are reference+offset.

For a while the GOOS=nacl port and the Google App Engine ports of Go disallowed unsafe pointer manipulation too, so there is some precedent. Throughout some of the ecosystem you can see pieces of "nounsafe" build tag support (e.g. in easyjson).

Go exposes raw pointers to the programmer, so from your description i think those semantics are too rudimentary to implement Go's semantics, there would need to be a WasmGC 2.0 to make this work.

It sounds like it would be a great fit for e.g. Lua though.

The major roadblocks for WasmGC in Golang at the moment are (A) Go expects a non-moving GC which WasmGC is not obligated to provide; and (B) WasmGC does not support interior pointers, which Go requires.

https://github.com/golang/go/issues/63904#issuecomment-22536...

Go has buildmode=c-shared, which compiles your program to a C-style shared library with C ABI exports. Any first call into your functions initializes the runtime transparently. It's pretty seamless and automatic, and it'll perform better than embedding a WASM engine.

Igalia are doing an Android port of webkit named WPE-Android[1] including a mini browser shell. There is an APK you can run[2].

1. https://blogs.igalia.com/jani/bringing-webkit-back-to-androi...

2. https://github.com/Igalia/wpe-android/releases/tag/v0.1.3

Joey Hess had this suggestion recently - https://news.ycombinator.com/item?id=43202773