I've mentioned this a few times but never publicly announced it, so consider this the announcement.
I've also ported Owl, my Cocoa Wayland compositor, from OS X to the Hurd using GNUstep.
Here's a screenshot of weston-terminal and weston-flower, running on Owl on GNUstep on Hurd, with X forwarded from a QEMU VM via SSH.
Here's another pretty screenshot for you'all
I've made a mock-up to illustrate my ideas about the next-gen terminal experience!
• the pathbar
• username, hostname and git branch displayed in the UI, shrinking the shell prompt back to just a $
• commands as cards
• syntax highlighting, including graying out the output a bit to differentiate it from commands themselves
• autocompletion (displayed in a native widget)
• built-in error handling options
• the time each command took (on the right)
I never did the #introductions thing, so here goes!
I live in Moscow, 🇷🇺 & currently study at CMC MSU.
I work at SmartDec where I write a cool static analyzer for Java & Kotlin. I'm also a tech editor at tproger.ru
I'm on the Darling team; we hack on macOS internals to make apps & programs targeting Darwin run on Linux/Android.
Cursed computer idea
#GIMP 2.99.6 is out ! And a cool Wilber & co. comics strip by Aryeom under CC by-sa license, as usual ! 🙂
« GIMP 2.99.6 is out with new/experimental features. Highlights: off-canvas guides, pinch zoom on touchpads, improved Paint Select tool (unstable), and more. Flatpak and Win installer available, no news on macOS builds yet (we encourage contributions!) »
Update: most of the patches have been merged; some are still being reviewed.
And I'm trying to fix glibc now.
For the past few days I've been rewriting my tarfs mmap implementation to unify paging and the cache after all (as I've been advised). This required significant changes to syncfs logic.
I've got it mostly working now, modulo some deadlocks. Found (& fixed) a few libpager bugs in the process: in one case, a function was always silently doing nothing due to improper check; in another, "precious" data was silently dropped.
Don't know yet if they'll like my fixes upstream, we'll see.
(This is to highlight tweaks that are *possible*, not to push "Rust changes too much, all the time" myth.)
It's fascinating how a #Rust edition can change so much more than just reserve a few more keywords — all while keeping crates that use different editions compatible.
Some recent examples:
• the prelude can be changed
• editions can change whether certain impls/methods are considered during method resolution
• built-in macros can change
• pretty much anything about closures and captures can be changed
• pattern matching can similarly be changed arbitrarily
• deprecated surface syntax can be removed
Note: on the Hurd, it's no more "kernel-side" than any other device driver — everything runs as regular processes in userspace.
And yet it's 3 times after than yes(1). What gives?
Well, to pipe yes(1) output into another program's input, you use a pipe. And that means going though the pflocal server.
The /dev/yes translator, on the other hand, can be read directly, meaning less context switches, and probably less copying data.
So in the end, it's for the same reasons it's faster elsewhere.
Uhh, so /dev/yes is now a thing for real too 😆
Performance and supported features depends on the particular implementation and kernel, but at least on Linux and the Hurd, /dev/yes is ≈3 times faster than GNU yes(1).
Looks like #Rust in GCC is progressing nicely: https://thephilbert.io/2021/05/03/gcc-rust-monthly-report-5-april-2021/
If you know #C, consider helping out.
So my understanding is that "lock elision" refers to transparently using hardware transactional memory features in place of locks, falling back to a lock if the transaction fails.
Apparently this is faster in the uncontested case because you don't even have to flip an atomic to enter/exit the critical section, so the CPU cores don't have to engage in this M*SI back-and-forth negotiating who owns the cache line containing the atomic.
Alright, I submitted the RFC patch series upstream. Let's see what happens next.
"Installation: we recommend that you use Docker."
what I'm supposed to see: "hey, it's a simple one-liner! Such clean install, much wow."
what I actually see: "we couldn't figure out how to install this thing on anything but our own machine, but hey, here is a well-compressed image of our entire disk, use this instead so that we can stop trying"
I soon ran into cache coherency issues (data written through mmap must be immediately visible via io_read, and the other way around). And I can't just unify mapped pages and the cache (like I imagine Linux does), if only because the cache block size is different from page size.
So I spent the rest of the evening trying to make that work, and I believe it does work now :)
Had a surprisingly productive day today!
Got the first working mmap (and that turned out to be enough to load a shared library off tarts, too), then spent some time beefing it up (there's a certain difference between a quickly hacked up proof-of-concept and a mergeable patch), then attempted to implement writable mappings...
...and the fixes are upstream now :) Enjoy!
Rust, objc, Kotlin, C, Python
Linux, GNOME; Android
Wayland; Plan 9
Microkernels, the Hurd
This Mastodon instance is for people interested in technology. Discussions aren't limited to technology, because tech folks shouldn't be limited to technology either!