Under the hood, is this simply checkpointing the files in the claude target folder or are you also checkpointing the claude context? One of my biggest pain points is after a few compactions/edits to claude.md and all of a sudden Claude has made a few mistakes and all the context window cruft of fixes it attempted and reverted actually seem to confuse it further and it would be nice to reset to a known happy place code & contextually and retry from there.
I read this as a 'coding tarte' and was expecting some sort of hodge-podge of rust transpiled into WASM being invoked by a node process that interfaces with a slice of python in the middle.
The Army has plenty of problems you see in other large organizations related to bureaucracy, strategic initiatives, retention etc, but one thing I think they do very well is their documentation. It is generally organized into four(ish) categories of Army Doctrine Pubs (ADPs) which are summaries of first principals for the major domains the Army operates in, followed by Army Technique Pubs which cover mid-level techniques and descriptive frameworks for various types of work. Field Manuals (FMs) contain more prescriptive information and tasks for both small and large units, and finally Technical Manuals which are basically instruction manuals for specific pieces of equipment or specific tasks.
I think it's debatable given the pace of change in most technology organizations whether it's even desirable to codify the standard tasks and competencies expected from different classes of information workers (ie. SRE1 vs Data Systems Analyst) but having at least ADP level documents that allow employees to align their efforts with company strategic aims is a good idea and having some sort of reference documents for involved technical tasks probably makes sense when the work is not able to be automated.
They are mentioned in the article, but I just picked up a pair of NREAL air glasses to use with my steam deck and I am blown away so far--the price point is about 1/3 of the T1s but most of the specs are very similar. The support for fixing the screen using the 3dof sensors is limited to their android nebula app for now but if they write a driver that allows it on a computer that would be helpful, but for now I find they are most comfortable to use in a fixed position (ie laying back on the couch). The technology to make compelling head mounted displays is finally here--I've owned various HMDs for drone viewing but nothing I'd want to relax and watch a movie/play a game on (the screens are usually too small and 480p resolution at best). More competition will only improve the space so kudos to Lenovo!
I think points 1-3 are valid and certainly contribute to the decision, but many manufacturers believe that the future of the interface is a mixture of voice control (environmental, cabin lighting, navigation etc) and manipulation of steering wheel controls with HUD feedback (infotainment and everything else). Failure to embrace voice interfaces and demanding a button for everything is making 'fossils' out of 20-100 year olds.
Source: I work at one of the big German car manufacturers and have mostly drank the 'use voice, don't look off the road' koolaid.
Could you expand on the last sentence a bit more regarding effective altruism? Are the uncomfortable questions related to the utilitarian nature of how the movement racks and stacks the causes they choose to support or not?
I was more referring to the fact that EA promotes philanthropy instead of asking why we have inequalities in the first place. So it evades questions of redistribution or fairness in a similar fashion as PG.
I'm not quite sure how strong the analogy is though.
I feel their pain to a degree, but this also reminds me a bit of someone who says 'When I was young, I loved building tree houses in my backyard with a couple of boards and some nails, now as a structural engineer, I have to do all sort of awful work like material takeoffs, load analysis, job site scheduling--it just isn't fun anymore!'. That's the nature of real work--small hobby projects or simple gigs are easy for a single person to write, but as soon as you bring multiple engineers, legacy system integrations, infosec reqs, etc. things get complicated quickly. It's a big ecosystem out there though, and people are inventing new way to work all the time (Hotwire and Sapper both have interesting ways of doing things compared to the current status quo). All that to say, I hope they find their bliss, and maybe a chance of scenery will at least help remotivate in the face of fatigue with their current set of frameworks.
I believe you can generally just capture a scene with a lot of dynamic range (say a person standing in front of a flat wall with the light falloff ranging from dark to overexposed) and then zoom in on a frame and you'll see more or less banding because of the tough decisions the capture device has to make on what data to throw away/reduce and what to keep
I appreciated the copy of the landing page--my literal first question after 'what is this?' was why would I use this when slack video and live share has been fine...it's still a tough value proposition but I'll certainly give it a spin and really would love to see a dev-built company like yours suceed!
> was why would I use this when slack video and live share has been fine
To be able to share your code with people not using VSC. We are also optimizing a lot the video quality and we are going to add more integrations soon to the video chat. As we are focused only on developers we can do a lot of things that Slack video can't.
We were trying to do Clojure pair programming in IntelliJ+Cursive and vim-iced over Tuple.app/Screen.so/Zoom/macOS-VNC-over-ZeroTier during the past few weeks.
Here are a few conclusions:
Having multiple, independent mouse cursors in one screen is and extremely useful feature.
Consistent low-latency is much more important than temporary low-quality video.
To conserve bandwidth, we hardly ever use the video-call capabilities; low-latency, crisp and wide-frequency-band audio is more than enough.
The screen sharing codec should be optimized for text, with sharp edges. I don't want to see glow or other jpeg artifacts around my letters...
Any of the mentioned programs can provide audio and video call capabilities; that's not a differentiating factor. I wouldn't mind using a separate program for just that, since it's a negligible initial inconvenience, when we are having pairing sessions for hours on end.
Instead of wasting your money on re-implementing such features in your own software, just blog about what existing solution would recommend for audio/video/chat. It's MUCH CHEAPER, than giving in to the NIH syndrome...
I would rather like to see you focus on more important aspects of developer collaboration, for example terminal and "network" sharing. After all we are writing that code not so we can talk about it, but to run it!
For example, since we are programming in Clojure, we must see the same REPL window(s) too, not just the source code. We are constantly running the code we just wrote (and its tests) in those REPLs. Currently, the least painful way to do this is sharing the whole screen :(
I haven't given up on other solutions, like Emacs in tmux or in a headless xvnc server with small resolution, 8bit colors only and tiny fonts. Viewers would just magnify it to full-screen. Characters would look pixelated, but still sharp, if the magnification factor is integer. It's a pity that open-source vnc solutions are a lot slower and macOS' built-in one and they don't support server-side resizing to the viewer's window size and things like that...
