In our dev/stg environment we reinstall half our machines every morning (largely to test our machine setup automation), and SSH host certificates make that so much nicer than having to persist host keys or remove/replace them in known_hosts. Highly recommended.
MacBook Neo forced me to finally make the jump, and it turns out that I, much like the engineers at Apple, don't really care about the spit and finish anymore. Third-party applications handle everything else. Also, I was happy to find that Divvy still runs just fine under Rosetta.
>Email(smtp) is not a bad choice for messaging in space
Email (Taylor UUCP g protocol) is a better choice for messaging in space. Resuming partial transmission is great! I used it up until ~2010 and it worked really great on some very, very crappy connections (modems, obviously, CDPD, phone tethering in spotty locations, bad WiFi setups)...
My HT radio has a mode (I've never tried) for talking to satellites. It uses the GPS to get the radio location, and then manages doppler shift for the frequency as it's coming toward or going away from you. So you'd likely need something in your WiFi connection to Artemis/Integrity to deal with that.
>I have zero interest in these new "swarms of agents"
I think you misunderstand "swarms of agents", based on what you say above. An agent swarm, in my understanding and checked via a google search, does not imply working on multiple features at one time.
It is working on one feature with multiple agents taking different roles on that task. Like maybe a python expert, a code simplifier, a UI/UX expert, a QA tester, and a devils advocate working together to implement a feature.
"Expertise" is a completely different beast from "knowledge".
Expecting to gain it from a model only through prompting is similar to expecting to become capable of something only because you bought a book on the topic.
> does not imply working on multiple features at one time.
How can multiple parallel agents some local and some in the cloud be working on a single task?
How can:
> All local and cloud agents appear in the sidebar, including the ones you kick off from mobile, web, desktop, Slack, GitHub, and Linear.
(From the announcement, under “Run many agents in parallel”)
…be working on the same task?
Subagents are different, but the OP is not confused about what cursor is pushing, and it is not what you describe.
Same way a developer and designer can work on the same feature during the same week? Or two developers working on the same feature during the same week. They can have a common api contract and then one builds the frontend and the other works on the backend.
Subagents are isolated context windows, which means they cannot get polluted as easily with garbage from the main thread. You can have multiple of them running in parallel doing their own separate things in service of whatever your own “brain thread”… it’s handy because one might be exploring some aspect of what you are working on while another is looking at it from a different perspective.
I think the people doing multiple brain threads at once are doing that because the damn tools are so fucking slow. Give it little while and I’m sure these things will take significantly less time to generate tokens. So much so that brand new bottlenecks will open up…
They are confused in the word they use: the article on what Cursor is pushing does not, according to ^F, mention "swarm" at all. Since we have a word for multiple agents working on one task, it is probably best not to use that word if you are referring to multiple agents working on multiple tasks, right?
I bring it up not to be pedantic, but because if you think it implies multi-tasking and dismiss it, you are missing out on it's ability to help in single-tasking.
I think cursor doesn't make distinction between single or multiple logical tasks for swarm-like workloads. Subagents is the word they use for the swarm workers.
Fwiw when I select multiple models for a prompt it just feeds the same prompt to them in parallel (isolated worktrees), this isn't the same as the swarm pattern in 2.4+ (default no worktrees).
Agreed, we live at ~5K and went up to Pikes Peak; my wife and I had no problems (beyond minor headache), but my son's lips were turning blue and he was feeling pretty bad.
Other amusing things from that trip: we went up there the 3rd of July, and it snowed. We charged the car in Colorado Springs before we left, got up to the peak with 36% battery remaining. My wife worried we wouldn't be able to make it back. Got back to CS with ~70% battery left.
Lol, on my trip up Pikes Peak I was blissfully unaware that altitude sickness could be a thing. So I can't recall if I felt any different. I do recall the carburetor on my motorcycle was acting a little strange, however.
Agreed. I also have had some good times with hostapd, and I've done a lot with commodity wifi hardware in the past (I'm known as the guy that was able to get WiFi working for PyCon when nobody else could). But these days I've been running a Ruckus R620 at home and it's been a huge improvement over 4 Google WiFi APs spread around the house with ethernet backhaul.
>So I took a consulting job in a small town in Illinois called Quincy.
Adams Internet/Telco/Fiber? Same. It always impressed me how early they were to fiber to the home down there in southwestern IL. ~15 years ago I made that same trip: Chicago down to Quincy then over to Steeleville and then to St Louis to drop off the rental car and fly back home. They really make the Coop system work out there.
Not them but I was legit impressed by the fiber coverage. They have towns of like 30 people with gig access, and all the roads between access points as well. It's kind of astonishing.
Seeing their setup is actually what spurred me to put together a coop at home to run fiber for the county.
Adams definitely knows what they're doing when it comes to managing resources in a rural area
The even more impressive thing is that they've had gig fiber for at least a decade, 15+ years. My town (nowhere near as rural) got us gig to the home municipal fiber 3-4 years ago, so 15 years was really impressive. I used to do sys admin consulting for them, they had really great people.
Does anyone know if this is covered under the Apple Care plans? My 16" M1 MBP keyboard has been no problem, I'm just curious. Not saying that negates the issue.
Unfortunately, AFAICT, these repairability issues are largely due to the move to thinner and lighter laptops. Replacing my MILs Microsoft Surface tablet was a pain in the butt. Had to cut the case open and tape it back together. But that thing was insanely small and light. My MIL liked it because she has a lot of trouble carrying anything very heavy.
Yes it is, I had my M! Max keyboard replaced as repairing the individual keycaps didn't work, and then they replaced the entire logic board while they were testing due to finding an error. Total cost was around €1400, to me €0. New bottom case, new battery, new logic board.
Keyboards on MacBook Pros have been riveted since at least 2014. That doesn’t necessarily disprove your argument, but it does move the “thin and light” bar farther back than one would expect from the phrasing.
The new MacBook Neo's keyboard is not riveted and instead held with screws. As far as I could tell it is still just as thin and light as other MacBooks.
I had been using delta for around a year and liked it, but still found some of the diffs I was looking a bit hard to read. A few weeks ago after a discussion on HN I tried difftastic, and have become a fan. You might want to consider it if you go down this rabbit hole. https://difftastic.wilfred.me.uk/
ah, it's using tree-sitter to not bother reporting changes that have no effect.
That's very nice!
Now, of course, the biggest issue is that our DVCes still are from the paleolitic era and store source code as non-structured text files instead of trees, so we need to the proper thing "outside" the DVCS (which is using tools like diffstatic / tree-sitter: tools that have seen the light).
It's basically the old "tabs vs space" and "tabs = how many spaces?" and "bracket on the same line or not" discussions all over again. I'm pretty sure I've got comment from 15 years ago saying that in a proper world this shouldn't even be a concern because this should purely be a client-side concern, on the dev's machine. And that the DVCS should have a specific representation, not opened for discussion (a code formatter for example, but ideally just the source code already as a tree). And then no more bitchin' about tabs vs space, about how many spaces is a tab worth, on which line brackets should go, etc.
Don't get me wrong: it's great that people are doing the right thing. But it's still a kludge that's needed because the underlying tool were made by us and for us cavemen and really could have been oh so much better.
You forgot that while expression can be trees, statements are an ordered set. And most statements fits inside one line. So a diff that relies on lines gives enough information.
Also git can be made to ignore whitespace changes (a source of noise) and can refine a hunk to highlight what has changed. That’s plenty enough for most people.
Came here to say this, difftastic is great as long as you are working in a language where it understands the language tree (most languages). Getting away from diffs being focused on line changes to diffs that understand the actual language makes so much sense once you start to use it.
