I think he should put a large visible artwork in the yard, a blue port inspired creation, and then seek compensation for aerial photography on copyright grounds.
I had this funny thought the other day when I was in a Teams meeting and someone wanted to record it. Sure, we all had to consent, accept agreements, and then gain the ability to turn our cameras and mics on, but it was a standard status meeting, nothing special. So, I thought to myself, what if we were doing this in-person? Would we have someone break out a camera and record our meeting? Something seems off with the WFH approach.
For teams that want to use technology to the maximum, recording MS Teams meetings allows them to use copilot transcript etc. That is the most common reason I see these days.
Earlier the main reason was to allow for a human to revisit any important discussion of they missed making detailed notes. It also allowed anyone who misses the meeting to catchup. And for global teams, team members in other time zones can catchup and maybe rewatch the meeting of accent differences made following the live meeting difficult. The coworker tasked with writing the minutes (manually!) would find it super handy. We also did recordings for "requirements gathering", "design review", "prototype walkthrough", etc so we captured all feedback and nuances thoroughly so next iteration can address them all.
For all these benefits we sometimes opened a MS Teams bridge and turned on recording EVEN WHEN we were all meeting in person. I would switch on the webcam and turn it towards the whiteboard, and try to get the best clarity possible -- a service to anyone who might be watching afterwards.
>have someone break out a camera and record our meeting
I've worked with a team who did just that, they held the vast majority of their meetings in-person (1 or 2 short meetings a day) but needed other stakeholders to keep up with their work and decisions, so they had some AI listen, keep track and send summaries and minutes.
They liked it, but I'm not sure it was more efficient than having someone send half a page of meeting summary manually.
It’s definitely great that memory safety is becoming more pervasive. Though I’ll believe “a world without memory corruption” right up until another <insert your relevant hacker hero name> comes along and finds a way through an unsafe block, an FFI boundary, or the hardware itself (Rowhammer says hi).
Yeah I was thinking of prefixing my "memory corruption" with "software-bug induced"! I don't see a credible solution to Rowhammer. ("DDR[n+1] fixes it" - lol)
> an unsafe block, an FFI boundary
Honestly these feel solvable to me at this point! I think we'll see:
- unsafe code shrink as languages get more powerful
- amount of analysis we can apply to each unsafe line shoot up exponentially as AI gets cheaper
- amount of FFI we actually need shrink as it gets easier to just click "rewrite it in $lang" on the decision card when your coding agent says "I found a library for that but it's in a different language"
(Having said all of that, people seem to be adopting Zig for some bizarre reason... So maybe I'm naive to expect unsafe lines to shrink)
(But also, maybe AI gets so good and so cheap that we can just type "go fidn all the bugs andfi xthenm" into an LLM, between sips of a Piña Colada)
I'm one of those people who's adopting Zig :) But I don't think it's best for every project. For context, I've used Rust before for probably two years writing a realtime audio synthesis engine, so I'm fairly familiar with Rust vs Zig for handling low level details.
The biggest reason I use Zig is it's a very explicit language. The creators made a very intentional decision to avoid too many "high level" designs. This doesn't mean there's no capabilities for abstraction (comptime is great for that), but when you see array indexing, you can think "ptr + index * size with bounds check". There's lots of other things like that where the language does exactly one thing, and that thing is a low level operation.
This is terrible when you want to create high level abstractions that hide details from the programmer, but it's what I need when doing realtime audio synthesis or what I'm doing now which is writing an interpreter. I know exactly what allocates, I know what calls IO and can block (both operations explicitly take in an allocator or IO parameter), no data structures have private fields so I can always poke around at the insides. I know what types of errors a function returns, and creating errors is cheap with Zig's error union design.
So I don't use Zig because I think it's the safer language, I know it has sharp edges because of the number of times I've caused a panic on a poisoned pointer or use-after-free. But because it gives me such a transparent view into what is happening I find it liberating.
I'm with you. Since the post already shows Clang catching the array-decay bug, the author could even just add a “always build with -Wall -Wextra -fsanitize=address,undefined” note and some explanation of course.
https://news.ycombinator.com/item?id=50319510
reply