agentkilo

IIUC, yes, all the kernels involved run directly on the hardware, in a "cooperative" way, i.e. they must agree on not touching others' memory regions.

I think the architecture assumes all loaded kernels are trusted, and imposes no isolation other than having them running on different CPUs.

Given the (relative) simplicity of the PoC, it could be really performant.

Yeah that part of the article put a big smile on my face.

I did the same thing back in college, when I was in a lab. We wanted to do some research on Wi-Fi signals, and I happened to own a bunch of Wi-Fi adaptors produced by SomeSmallTech Co. Ltd., which featured relatively new Atheros chips and didn't have Linux drivers at the time.

So I sent an email to the company's public email address, asking for some datasheets, "for science". To my disappointment, presumably a PR person replied that they "don't have a company policy to collaborate with academic research". (But they did send a quick reply, kudos to that.)

Funnily enough, years later I ended up working for said company. Naturally, when I first logged into the company network, I searched for the datasheets I asked for. There were "classified" watermarks all over the PDFs :)

Built on top of Owl Lisp[1]. TIL about this dialect, and it looks interesting! Instead of native threads, it has continuation-based threads[2], and it seems the whole VM architecture is based on that.

[1]: https://haltp.org/posts/owl.html

[2]: https://haltp.org/posts/owl.html#heading26

> An offset would be nice, though I'm sure it's not easy to define a heuristic that works in all places.

I agree. I considered dynamic offsets, in an effort to declutter the labels, but found it even more confusing. Maybe I should do more experiments on this.

> but where the labels were laid out it just looked like an inviting right-aligned label on the clickable tabs themselves

The labels are left-aligned by default (except in `frame-hinter`). I think you can try some combinations of the `:anchor` and `:show-highlights` options[1] to see if they work better for you.

[1]: https://agent-kilo.github.io/jwno/ref/built-in-modules/jwno-...

Edit: Wrong link

It seems your right alt key is actually the AltGr key. I didn't explicitly support AltGr in Jwno, so it freaked out.

Sorry for the confusion. I think switching to another leader key, such as LAlt or RCtrl, should fix the issue.

Thanks! I created a tracking issue here: https://github.com/agent-kilo/jwno/issues/12

Meanwhile you can try to change leading `RAlt` to something else, like `Win + H`, and see if it works. There may be a bug that gets triggered when only modifier keys are mapped.

> Having tiling options that fit within a smaller part of the screen (e.g. still allow side by side or top/bottom split, but in a smaller total region) would be great.

Do you mean reserving screen space for the on-screen keyboard? If that's the case, you can try to "transform" the top-level frame (a frame that tracks a monitor's screen area), either in the REPL or in your config: https://agent-kilo.github.io/jwno/cookbook/adjust-top-level-...

> Using example-config.janet I tried pressing RAlt or RAlt+K and I get the UI hint shortcuts list coming up, but none of them seem to do anything

Can you please file a bug report and attach relevant logs? You can write logs to a file by starting Jwno like this:

jwno.exe --log-file C:\jwno.log --log-level debug --no-console your-config.janet

There should be some interesting logs when you press one of the UI hint shortcuts.

> Fwiw, as a newbie I found it a bit intimidating/off-putting that it doesn't work out the box without choosing a config file. That's quite a lot of extra cognitive effort and link-clicking before you can try it out.

I totally understand. But I chose to not include a default config in the executable, because I thought a window manager is a... personal thing. It should evolve with your habits and workflows, so the default config will most likely get changed to something dramatically different anyway. I can be wrong though.

A fellow StumpWM user!

My StumpWM is heavily customized though, and I mostly modeled Jwno's behavior after my own config, so it may not be what you expected at all.

But that's one of the reasons I like Lisp and things built in Lisp: They are so flexible, you can sometimes build something based on the original thing, while it feels completely different from the original.

> my monitor seems just the right shape/resolution for the standard Windows splits to be suboptimal

Do you use an ultra-wide? In that case, Jwno has no OOTB ultra-wide support, but there's a section for adjusting it in the cookbook[1].

[1]: https://agent-kilo.github.io/jwno/cookbook/adjust-top-level-...

Sorry for the confusion. Multi-monitor support is only briefly mentioned in the docs[1] and the interactive tutorial[2].

Jwno's internal data structure has these levels (higher-level comes first):

Root - Virtual Desktops - Monitors - Normal Frames - Windows

So monitors are part of a virtual desktop, and every virtual desktop has the same layout that reflects your physical monitor arrangement. When you switch virtual desktops, all monitors switch to the new desktop at the same time.

[1]:https://agent-kilo.github.io/jwno/frame-tree/frame-nodes.htm...

[2]: https://github.com/agent-kilo/jwno/blob/master/example/tutor...

TBH I dived right in when I decided I should build something with Janet, and didn't really consider any alternatives. Now you mentioned it, I think Janet's simplicity and conciseness played a large part in attracting me to it, comparing to Common Lisp at least.

Thanks for posting the link!

It's a quick-and-dirty PoC with lots of caveats and limitations though. E.g. it works only for a single monitor. I don't think we can clip windows to a "view port" on Windows (the OS), so this may never be as nice as PaperWM, Niri etc.

I think these are the most obvious differences between the two:

* By default, Komorebi uses dynamic tiling, while Jwno uses manual tiling.

* Komorebi has workspaces, Jwno works with Windows native virtual desktops instead.

* Komorebi uses IPC and native system command line to send commands, while Jwno usually operates all by itself.

There are definitely other details that are important to you, but these are the things that immediately came to my mind. I don't run Hyprland so can't really comment on that.

I think Janet is quite...liberal? It's a practical language, but doesn't force a specific paradigm on you. There're "escape hatches" in different levels of the language, and I like that.

Maybe the most "opinionated" things in Janet are the ev stuff and fibers. I think they're done right though, you just need to be careful with the event loop when embedding Janet.

I find the REPL and interactive development workflow invaluable. A window manager is a long-running background service by nature, and has a lot of accumulated runtime states. The ability to peek inside and debug while the process keeps running helped me a lot when building Jwno.

I think Jwno's REPL module is so important, I specifically changed Jwno's architecture at one point to make it work.

> I think it's inspired by Clojure and Lua, and somehow manages to be better than both

This is exactly how I feel about Janet too. I don't think I have enough experience on Clojure or Lua to comment on them, but I got attracted to Janet almost immediately.

Working on Jwno also confirms my first impression on Janet: It's really a practical language. The tooling has some room for improvement, but the language itself can get things done - usually fast and easily.

Thanks for the kind words! It means a lot coming from you :)

Definitely! I got great inspirations from both of the Komorebi and GlazeWM communities. People who like tidy desktops are definitely nice people :)

Thanks :)

Interesting. I didn't know about Nimony.

I'm still not sure what a compiler plugin is though, after reading the scarce discussion in the forum thread. Erlang's parse transform comes to my mind. Is it something similar?

The article states that "pager daemons" that manage swap files runs in user space, and the kernel memory can also get swapped out, but never explained how a user space daemon swaps out kernel memory. Do they have hard-coded exceptions for special daemons, or use special system calls? Where can I find out more details about the user space memory management specifically?

Reminds me of Phrack [0]. I learnt all the stuff I know about the ELF format and some low-level debugger shenanigans there, and implemented my own PLT hook back then, good times.

[0]: https://phrack.org/

Haha I had the exact same thought when I saw the title.

That said, the new car looks very much like an "electrified" Golf, which is one of the first cars I drove, and I have fond memories about it. The new car may succeed if they target the same audience, and remove all those fancy user-tracking "features".

Yeah that's true, but I haven't really experienced the Apollo era personally. After the "gap" between the old space race, and the new race inspired by private space agencies, I do feel we are getting closer, to the moon at least.

Congrats to everyone involved!

I planned to watch the live stream but wasn't able to. The moment of successful landing was quite modest, only a mostly-static screen with telemetrics was shown to the public, but it absolutely felt magical. It feels like the moon is well within humankind's reach by now.

Coincidentally, I found a copy of Uchu Kyodai (by Chuya Koyama) in my local library, and started reading it recently. It's fun to compare the perspectives from more than a decade ago, to the actual development we have right now, regarding space exploration.

(This was posted to another thread, but I moved it here after I realized comments were moved)

Yeah these days I just go to LiveATC and start my own choice of music before I start my day. I used LofiATC and it gave me this hobit.

Judging by what happened to LofiATC though, it seems LiveATC was not fond of this kind of things.