Because that would go against MSFT's wishes on pushing LLM driven development if they started acknowledging that these tools are more damaging than helpful.
you can even replace the whole computer if you tinker enough, since it runs Linux. whether or not that is a good idea in principle with _any_ vr headset is debatable.
AR glasses are much more suited towards that vertical at a lower cost, yet imo still struggle to be compelling in productivity.
not if you have to host meetings! the web versions are feature incomplete and don't support something as simple as screensharing with your camera overlayed in a corner (essential for recorded meetings).
the zoom linux client consistiently locks up my entire computer whenever i copy from the chat. ridiculous.
The web client definitely lacks features, but I fail to see how this is a client feature? You can share your screen and have your camera on at the same time. It's the recording server that decides how to composite those together.
it's a client feature because zoom is terrible. you composite camera and screen on your end so viewers see it on one screen, and the zoom cloud recorder records only one streaming source at a time. without third party integration i cant save my camera feed and screenshare at the same time in the web version. it's terrible.
You could do much of that with OBS and its virtual webcam, passed to the web client. It's a minor hassle to set up the first time, and is ready to re-use thereafter.
nope, because if anyone else talks the focus then shifts to them and nobody can see your screenshare. you have to instead use obs' popout preview and screenshare that specific window, which doesn't work if you dont have a second or third monitor due to always needing to be maximized.
The real "world's best websites" are ones that can display their static content performantly and responsively without JS, while correctly conforming to baseline.
you're missing blue bubbles, computational photography, and FOMO. re: nothing actually important.
many people have a phone as their only device though, so great screens and cameras and everything else are easily rationalized behind the managable cost of carrier plan's indirect loan.
formal verification is great and all, but you can never make it as ergonomic as functional verification. this matters for agents and real people alike.
formal verification requires a deeper understanding of underlying mechanisms to write correctly. yet nothing prevents you or your agent from changing invariants to fit the algorithm and making it incorrect.
And neither can be made as ergonomic as no verification at all. It's all about how much you need. Functional verification isn't an appropriate tool where a single bug is catastrophic.
> yet nothing prevents you or your agent from changing invariants to fit the algorithm and making it incorrect.
If the thing we're trying to prove is ungrounded, it's trivially true that any verification method falls apart. You're still encoding priors in your testing methodology. No matter how robust you think your testing suite is, I can still trick it if given free reign over the codebase.
static allocation is de-facto standard in embedded for obvious reasons, and works really well there. in operating systems with more complex memory models designed entirely around dynamic workloads, im not sure asking devs to adopt another slightly complicated design pattern that imposes new hard caps is any less of a cognitive load than before.
i can't bash the functionality and correctness aspect of static allocation, but it is akin to the humble linked list in the sense that you should already know going into the problem that you need it.
Someone recently made the point to me that a lot of dynamic situations can be rewritten as locally static allocations with proper continuations. The idea being that you re-enter the continuation with more memory when you've exhausted your existing pools. The problems are obvious, but it's a neat middle ground.
The simplest example being a stack buffer that expands to a heap allocation when required. There is an API pattern to facilitate this: when the size of the provided "out" buffer is insufficient to hold the result, return an appropriate error code and populate an out parameter with the required size. So you try once with the stack buffer, and if that fails, retry after allocating a heap buffer of precisely the required size. We used this pattern everywhere in Windows dev.
reply