higherhalf

Thanks, I really should've looked deeper than that.

clock_gettime() goes through vDSO, avoiding a context switch. It shows up on the flamegraph as well.

Thanks, I looked it up and it's indeed quite ugly, and my shebang isn't portable. A little saddened that even 'env -S' didn't make it to POSIX.

Seems a little complicated when you can do:

  //usr/bin/env rustc "$0" && ./config "$@"; exit

Or

  //usr/bin/env rustc --edition 2024 "$0" && ./$(basename $0 .rs); rm $(basename $0 .rs); exit

> It doesn't allow you to import `std::iter::Iterator::collect` on its own. It's an associated function, and needs to be qualified.

You probably noticed, but it should become a thing in RFC 3591: https://github.com/rust-lang/rust/issues/134691

So it does kind of work on current nightly:

  #![feature(import_trait_associated_functions)]
  
  use std::iter::Iterator::{filter, map, collect};

  fn get_ids2(data: Vec<Widget>) -> Vec<Id> {
      collect(map(filter(Vec::into_iter(data), |w| w.alive), |w| w.id))
  }  

  fn get_ids3(data: impl Iterator<Item = Widget>) -> Vec<Id> {
      collect(map(filter(data, |w| w.alive), |w| w.id))
  }

What makes this a "systems programming language", especially since it has "no pointers or references"?

It's not due to a move to AI-enhanced workflows. The article speculates that it's caused by companies wanting to develop AI-related products, moving some workforce and culling the unwilling, just like my employer.

This can be done even simpler:

  global _start
  _start:
      jmp next
  string:
      db `Hello World!\n`
  len: equ $ - string
  next:
      mov ecx, string
      mov edx, len
      mov ebx, 1
      mov eax, 4
      int 80h
  
      mov ebx, 0
      mov eax, 1
      int 80h

For NASM, it can also be put into a macro, for example printing to video memory at 0xb8000:

  %macro print 1
      mov ecx, %%loop_start - %%strdata
      mov eax, 0x0700
      jmp %%loop_start
  %%strdata: db %1
  %%loop_start:
      mov al, [%%strdata + ecx - 1]
      mov [0xb8000 + ecx * 2 - 2], ax
      loop %%loop_start
  %endmacro

Yes. Kind of.

AMD processors have Upper Address Ignore (UAI) with 7 bits of ancillary data, for Intel there is Linear Address Masking (LAM) with 6 or 15 bits [1]. The latter has made it into Linux after some initial resistance [2].

[1]: https://lwn.net/Articles/888914

[2]: https://www.phoronix.com/news/Intel-LAM-Merged-Linux-6.4

They mention git worktrees in the next paragraph.

It's a joke, as some Rust projects used to repetitively claim to be "memory safe & blazing fast", thus becoming a tongue-in-cheek phrase. I also anticipated language to be Rust, but it would be way too comical.

https://github.com/mTvare6/hello-world.rs

> But rust absolutely does not have any C/C++ compatibilty besides [..]

> In zig you _can_ actually start with a c codebase and rewrite it file by file in zig and you _can_ include c headers in your zig files verbatim. Both of these are not possible in rust.

You can. Either via FFI and bindgen-ing headers, or by using c2rust. The latter is not just a toy ambitious project, but actually a very impressive piece of engineering and does produce a result where you can transpile a project or file and start rewriting file-by-file or function-by-function.

Excited for threads, sockets, futexes, but not excited for fork, signals and setjmp. They didn't include POSIX stuff like shared memory, select(2), unix sockets, and had to draw a line somewhere. Why include error-prone cruft?

There's also JSON5

https://json5.org

There's something mildly charming about fixes to ed(1) in software released today.

> Fixed ed(1) to print bytes read/written and the ? prompt to stdout, not stderr.

This fits as a "list of links by topic": https://github.com/rust-embedded/awesome-embedded-rust

> tmux show-environment

> [..]

> -WINDOWIDkj

Consequence of using Vim to edit blog posts? It should be, according to author's dotfiles :-P

Or maybe using tmux, because I also press kj to determine what pane I'm on sometimes.

For me, it was the "I Am Graphics And So Can You" [1] series, where author progresses from the similar concepts up to a working renderer for DOOM 3, linked in the intro of this article [2].

[1]: https://www.fasterthan.life/blog/2017/7/11/i-am-graphics-and...

[2]: https://github.com/DustinHLand/vkDOOM3

> [..] in kernel mode while retaining the ability to compare how the very same usermode bits run on the Linux kernel as well. That's a unique feature in the realm of educational kernels.

There's also Kerla: https://github.com/nuta/kerla

I'm latching onto a non-main argument to be pedantic, but I'd like to mention that Rust is fine for _non-embedded_ kernel development too, in my experience.

As you're likely aware, Rust for embedded sucks when there's no HAL, but should be pretty pleasant otherwise. Have you looked into the cortex-a[1] crate?

Some unnecessary instructions could also be a part of an ongoing optimization effort[2][3].

[1]: https://github.com/rust-embedded/cortex-a

[2]: https://old.reddit.com/r/rust/comments/yn6105/optimization_o...

[3]: https://arewestackefficientyet.com

Speaking of significantly faster linkers, I personally use mold[1], including when writing in Rust.

[1]: https://github.com/rui314/mold

I was wondering if memfd_secret [1] could be a part of a solution to this problem. Sounds like it. Of course, it'd require a recent kernel version, which is an obstacle.

[1] https://lwn.net/Articles/865256/

I fail to see a contradiction.

The color legend and some basic help instructions are coming.

> I'm surprised this is written in Rust and doesn't use the object crate--did the author do this in part to learn how elf works?

No. When I started the project I was expecting to just read data into the ELF structs, in style of C. (Un)fortunately, it's not possible to do safely, so I started looking into crates to do that, and was stumbling upon data deserialization ones. In particular, the first attempt was in nom. In hindsight, that wasn't particularly smart, and specific object-file-parsing ones would be better. I don't regret implementing reading manually, despite it looking pretty ugly, because attending to NIH syndrome is fun.

> Speaking of visualizing virtual memory, one of the things that I haven't seen a nice prior tool for is breaking down the memory map of a process on a per-section basis

That is planned. It's noted in readme, and in issue #3 I go over how it can look like[1].

[1]: https://github.com/ruslashev/elfcat/issues/3#issuecomment-86...

You can click on their starts and ends (the fields they are referencing) too.

I sure am! I wish it was more "done" however, right now it's pretty raw.

> The three nulls in the load segment (between the code and data) are included in [..]

Yes, this is a bug. Thanks for reporting it to the issue tracker.

> Also, I wish the arrow heads did not opaquely overlap the numbers. Adding opacity="0.3" to the svg tag fixes this for me.

Will put to toggle-able options. The arrows really hinder comprehension, perhaps arrowheads could be made smaller too.

Hello, author here (I edited the bio on github to show). Don't know how I missed it on HN, must have been the grey link.

First I'd like to say that right now this is just the first release, and it's a bit raw so far. That's why I was hesitant to post on HN yet, expecting a more harsh but merited critique. I am reading through the thread for bugs and suggestions. Thanks for that.

Are they fuzzed? Should be useful as some guarantee against memory-safety bugs. Didn't find this mentioned in the project.