pflanze

> Teasing an owl: https://youtube.com/watch?v=Y0i9tjnW7r0

There was a video on youtube about a crow coming to a human and making that sound, also in winter with snow; commenters agreed that it was probably thirsty and was imitating running water that way to get the human to give it water. The human in the video didn't get that. But here in the end we can see the crow eating snow, which may confirm that it is really a way for crows tell when they are thirsty? Not sure what that has to do with the owl--"teasing" might be just testing the owl's capabilities for checking whether killing the owl to drink its blood would be an option? (I guess melting snow for water is increasing the risk for the crow to be cold & run out of energy.)

Thanks for the info! I guess it also makes sense as I realized after posting, if it did use the result of malloc unused it should crash immediately due to references into the zero page segment, thus can't have been what I saw.

Do you happen to use memory resource limits? I used to run Firefox under some, like everything, to prevent it from potentially making the whole system unresponsible, and at the same time had frequent cases of Firefox showing random visual corruptions and crashes. At some point I realized that it was because it was running out of memory, and didn't check malloc failures, thus just continued to run and corrupting memory. (That was some 6-8 years ago, maybe Firefox does better now?)

If the code in the closure moves a value, then the closure becomes an FnOnce and does move the value out of the context. That's what you probably have in mind.

So, Rust does support partially-moving closures, and does so automatically.

But the converse is also true: Rust does not move values just because. If the code inside the closure doesn't move the context, then it will only move context if you use the `move` keyword (in which case the lifetime of the closure is not restricted by borrows of the context; Rust doesn't automatically move things to satisfy the closure's required lifetime, that's a manual decision process consistent with how Rust behaves in other places).

There's still one difference to the macro case: the closure borrows all the values at once. So if it needs &mut access to some variable in the context, you can't take another &mut to the same variable outside the closure as long as it is alive (as determined per what the non-lexical lifetime borrow checker can do). Those cases need to be worked around by instead passing in the &mut as a closure argument. Code deposited by macros is not subject to bundling all captures together, hence the borrow checker has more allowance to reduce the borrowing time of each borrow.

> So AFAICT Embassy doesn't do this at all?

I haven't used Embassy, but the README mentions "Tasks on the same async executor run cooperatively, but you can create multiple executors with different priorities so that higher priority tasks preempt lower priority ones" and links to an example that shows how a higher priority task runs even though a lower priority one runs a long time job (does not yield), thus understanding and infrastructure seems to be there.

So, Embassy may in its entirety replace an RTOS / be one, but it's not the async mechanism that can provide the RT part (and I guess you're right to point out the dangerous sentence as it could mislead people to use only async and believe it's RT).

OTOH the sentence would be right if it were something like "async multitasking is an alternative to preemptive multitasking, and can replace the use of a preemptive OS if real-time guarantees are not needed (note that Embassy separately allows running multiple executors to allow to pre-empt tasks running in lower-priority executors)". They should probably also describe what the reason for not needing per-task stack size tuning is.

No, unless you ask for it via the `move` keyword in front of the closure.

This works fine: https://play.rust-lang.org/?version=stable&mode=debug&editio...

> The behavior is all the more impressive given that the rodents hunt at night, when they are effectively blind

I can't access the paper to check if they verified it, but given there is a strong IR light, and even humans can see IR light if strong enough (and close enough in frequency, which is typically true for IR illumination for cameras), I wonder if that is true.

There's an independent reimplementation of the PIO assembler here: https://crates.io/crates/pio -- I haven't tried it so don't know how good.

I think the hard drive platter moves in the wrong direction--it pushes the head into the platter instead of away from it if it gets too close.

I wonder if they sensed that at some point number plates would be automatically recorded wherever you drive, even when not causing an accident or doing anything illegal.

Just a funny coincidence or is there some connection?: OP writes that legislation started 1 January 1904, which happens to be the time epoch in the classic Mac OS, which was released in 1984 with the well-known 1984-styled commercial.

Thanks for the nojs version!

I would expect that this increases the gap between new and old phones / makes old phones unusable more quickly: new phones will typically have enough RAM and can live with the 9% less efficient memory use, and will see the 5-10% speedup. Old phones are typically bottlenecked at RAM, now 9% earlier, and reloading pages from disk (or swapping if enabled) will have a much higher overhead than 5-10%.

That sounds plausible. I've sent them a mail.

OK, but they wrote "At the end of the last century", which implies towards 2000 not 1900.

> At the end of the last century, coal was used to generate more than 95% of the UK's energy, but last year it had fallen to 1%.

That looks like an impressive change, even if the coal use hasn't been replaced with renewables. But looking up details, the 95% number doesn't appear to be true:

- "Energy mix of UK"[1] shows no time when coal was above ~55%, and even total fossil fuel use was over 95% in 1965, not around the year 2000. But this may be total energy use, not just for electric (not sure).

- "UK electricity production by source"[2] shows that around the year 2000 fossil fuels made up perhaps about 70% of the mix.

[1] https://en.wikipedia.org/wiki/File:Energy_mix_of_UK.svg [2] https://en.wikipedia.org/wiki/File:UK_electricity_production...

If we're talking about constructing structs, like in `Foo { bar, baz: 123 }` (with the `bar` style shortcut in it), I have used that kind of syntax 10 times in 16 KLOC of Rust. Not a lot, but it does happen, and I found it kinda neat when LSP integration suggested its use.

I've probably used it more for pattern matching (`let Foo { bar, baz } = ...`), but haven't measured the number of instances of that idiom.

Linkers & Loaders is their own book (I haven't checked the others).

They have a page at https://www.iecc.com/linker/ where they used to publish a draft of the book contents, but changed the page to say "Chapters were available in an excessive variety of formats, but are not any longer due to chronic piracy", when it got posted to HN at https://news.ycombinator.com/item?id=18424233 and I bundled the files for offline reading. I notified them via email about that asking if they are OK with it but got an unfriendly response that I pirated the files and that wasn't OK, so I took the link down again and they changed that text. (Shrug. I'm not a/the book author, they are. I'll say that I also suggested to them they ask on the page not to do what I did since then I wouldn't have, but they chose their more radical approach.)

I was looking at the main branch, and described the situation there. They have a different branch for the optimization work; in that branch, they do mark those functions as `unsafe` (and already did when I posted).

Using clone or Arc with boxing everywhere to avoid using references with lifetimes at all will lead to code that's slower than Go/Java, yes, unless you're just cloning small objects that don't internally use heap allocations or your algorithm dictates to only need moves, not sharing, or perhaps except it will likely use less RAM which in some situations may still make it faster. But such "newbie" code will probably still be using some other existing code that is using references internally, which makes things faster for those parts. Also, the difficulty of the use of references varies depending on how long / indirect they are going to be used, in many places references are easy to deal with even for a beginner; so it becomes a question of how much the code relies on clone and reference counting.

When I learned Rust, I actually never went with the "use clone or Arc to make your life easier while learning" recommendation but always used references and learned how to use lifetime declarations and program design to go as far with them as reasonable. TBF I had experience with C and C++ already. But once reasonably experienced working in Rust (after a year?), your code should be faster most of the time the way you write it on the first try without needing optimization work.

Yes, but their code appears to actually be `unsafe` (in the Rust terminology sense) without specifying that in their function declarations. They use `unsafe` inside their `slice` function, but return a value that is unsafe to use, hence `slice` should be marked `unsafe`, as should `copy_to_bytes` and then `merge_bytes`. Same for PromLabel::merge_field and PromTimeSeries::merge_field as far as I can see, and maybe higher up in their actual app. This is definitely not how Rust code is supposed to work, if a function isn't marked unsafe, it should not be allowed to introduce UB; they violate that. This approach is on par security wise with C/C++ code iff programmers are aware of the pitfalls, which normally isn't the case since Rust programmers expect non-unsafe functions to be safe (i.e. not require additional care to avoid undefined behaviour).

They either need to mark their functions `unsafe`, or use lifetimes (which may require changes in some APIs, which may be the reason they didn't).

After a cursory inspection of the memleak program source and Brendan Gregg's blog post it's still not clear to me what it is tracking to be able to decide that there's a leak here. It would seem to me that palloc causes a mmap call for the initial allocation (or to enlarge the region?); but why would an individual allocation within the region be treated as a leak? I can see how eBPF can allow to track mmap usage for custom allocators where valgrind or ASAN might not (I'm not sure about that), but it being reported as a leak would imply that the whole region is missing a deallocation call? How would it recognize via eBPF tracing that 4 KB within the region remain without a pointer?

PS. My assumption here is that palloc is allocating within a region. Which is how OP describes it (oddly it doesn't take a MemoryContext as an argument so that must be in some global or thread-local var, or palloc is a macro and takes the context from a lexical variable (uh)?).

I'm using VNC for coworking/mentoring sessions and it works very well for us (it's lower latency, higher frame rate, sharper picture than typical screen sharing, and allows both/all sides to interact with the session and use the mouse pointer to point to things). We're using Linux on both the server and client side. There's a full desktop on the remote side, to fully interact with that (to have key bindings go to the server instead of the local desktop) the client needs to be made full screen. Latency isn't really an issue even between central US and Europe.

I've automated the set up of a Debian server for the purpose using[1]. There are some details on how to run it and how to set up the client side here[2] (probably slightly outdated). Feel free to mail me about it.

[1] https://github.com/pflanze/chjize [2] https://github.com/pflanze/chjize/blob/master/client-side-to...

The sorting is according to the "sort" column, not the "name" column (they are not explicit about this but it's clearly what they mean, and it solves your problem).

I think the benefit could mostly be for the implementation of the GUI to change the tree (that they do mention).

If you don't feel like using a hack, don't. (They make that clear, too.)

Yakety Moog, https://youtu.be/qp_b-TkkR4I

Maybe I'm hearing more into it than there is, and I'm not a musician. Still it's the piece closest to the Thing on a Spring tune that I've heard and I would be surprised if Rob Hubbard (who is said to have written the latter) didn't hear this one before composing his. But who knows. Maybe they are just both in the line of some classical country music pieces including rhythms (I don't know much about country music), and share the use of synthesizers for it, but also the daring attitude, change of sound from part to part, and the pitch up (however you would call that) bits.

Interesting, this Gil Trythall piece is the tune in the Commodore C-64 game "Thing on a Spring", isn't it. I didn't know that was a pre-existing piece.

https://www.youtube.com/watch?v=AeRP8rQ-07I https://www.youtube.com/watch?v=QhkFF0c-gUo

> that the programmer job somewhat evolved from data entry and clerical roles that employed plenty of women already

This reminds me of a presentation[1] that showed pictures on how early computers were advertised and what roles programmers (women) took in the advertisements, which echoes your statement.

(For context, see response to a comment of mine here[2]; more[3] info[4])

[1] https://youtu.be/5zN83hvn68U [2] https://news.ycombinator.com/item?id=37411221 [3] https://www.bbc.co.uk/programmes/b08wmk5l#playt=0h10m07s [4] https://web.archive.org/web/20190713175933/https://datasocie...

> the C64 could display a total of 16 colors at a standard resolution of 120 x 200 pixels, though it also has a graphics mode with the higher resolution of 320 x 200 with more limited colors

I'm not sure where your 120 pixels are coming from, looks like an error. Color mode was half the resolution of the hires mode (2 hires pixels were taken together to represent 4 values that a color pixel could represent; there were 40x25 blocks (corresponding to characters in text mode) where the colors used for each of the 2 or 4 states could be set (with some additional complication as it was using a separate RAM chip for part of that, the details of which escape my memory without looking it up). There were also 8 sprites of 24 (hires) or 12 (color) pixels horizontally, those don't add up to 120 pixels either.

To give context for those who don't know: relatime is a relatively (I'm a dinosaur) newer introduction into the Linux kernel; mounting partitions noatime used to be the only alternative to the default which was updating the atime on every access, thus fiddling with that setting used to be important. Not any more.

BTW I used to continue to mount everything noatime anyway, since having the atime field be set upon file creation and not anymore afterwards was a way to get file creation time, and I found that more useful than the access time. This isn't necessary either anymore since the introduction of an actual file creation time.

I wonder what she did after the war given she was talented with logic and programming? She couldn't have used her work as a reference, but she still had experience for a good use.

I've been using genawaiter[1] for writing generators in Rust. Are there things you can't build on top of async-await? Or is it just that it's simpler without that indirection?

[1]: https://crates.io/crates/genawaiter