What % of people reading that will know to not take it at face value? Of HN people yes very high, of the people living in my country I'd guess pretty low.
The "AI responses may include mistakes" disclaimer is only shown when you expand
This is awesome, it would be great to cross reference some intelligence benchmarks so that I can understand the trade off between RAM consumption, token rate and how good the model is
This looks great, i've been wanting a dev sandbox that doesn't run the risk of costing a lot if I forget to turn it off.
I had a few issues
1. manpath: can't set the locale; make sure $LC_* and $LANG are correct
suspect this is due to it inheriting locale from my local machine? easy to get around with some updates to .bashrc
2. the $SHELL environment in my sprite is `/opt/homebrew/bin/fish` I use fish on my local (mac + homebrew) machine and it seems to have inherited from my local machine, its nice to be using fish in the sprite, but seems weird that $SHELL in the sprite points to non-existent path. Slightly concerning that a local env var is being transferred to a remote machine without my explicit permission, I have some sensitive env vars locally.
Seems fun that most of the huge engineering effort seems to have gone into making the device feel as if its not there, Passthrough, Persona, EyeSight, and most of the downsides in the review comes from the fact that the device is still there.
The device is a simulation of the dream device that can overlay UI on top of your vision without you looking any different to those around you, I wonder how far away that is.
>How did they do it? As it turns out, crime. Unable to reverse engineer the chip, Tengen convinced the United States Copyright Office to hand over the source code of the lockout chip, claiming it was necessary for a lawsuit. With the code in hand, Tengen could make their own clone with ease. And Tengen was going to sue Nintendo for antitrust violations, so they probably figured they could get away with it.
I dont see many suggestions of a better way to do things. We can always find the flaws in the way things are but that doesnt mean they’re not optimal. When I learned this the first time it was just either agile or waterfall, if agile is so bad are we saying that waterfall would be better for all these situations?
My opinion is that agile needs to be agile, in that we have to adapt ways of working based on the team’s situation, what were working on, how well resourced we are … and have agility to change how we do things to optimise our work based on those constraints.