Are you saying Keyhole copied Terravision when they created EarthViewer? Google Earth was a rebranding, with continued development, of Keyhole EarthViewer after Google bought Keyhole.
1,749 karma · joined July 4, 2021
There are also many cases of people waving their right to appeal once sentenced, which can cause challenges for their counsel (from the link: "Should a death-row inmate who wishes to waive his appeals be viewed as a client making a legal decision to accept the justness of his punishment, or as a person seeking the aid of the state in committing suicide?"): https://repository.law.umich.edu/cgi/viewcontent.cgi?article...
There are difficult issues everywhere you look with the death penalty. The one I can't understand how people get past is execution of the wrongfully convicted. Any justice system is flawed and makes mistakes - it's just too complicated to establish absolute truth when so many people with diverse motivations are involved in the process. We can save money by just putting them in prison until they die, giving us the option to partially undo the sentence in cases where innocence is later established.
On the LLM front, it's been a fascinating journey for me. I started with the private beta of Github Copilot. I was an instant convert for the "better code completion" aspect. But my first attempts with coding agents were rough enough that I stayed away.
I'm now retired, but I want to understand how things are evolving. So two months ago I volunteered to automate a cartography data pipeline for an educator. I have a background in all aspects of the project. It's not simple - there are several data sources from governmental and corporate sources that need to be integrated together, and most of them are updated every few minutes. New maps need to be available within ~5 minutes of a data source updating. All this with many GB of data and running on a low powered machine, taking less than 2GB of RAM.
I bought some DeepSeek tokens and went to work. A few weeks later a mentee went to work at OpenAI and gave me a "friends and family" Pro level plan. I'm converted, and I absolutely see it as a tool in the sense Rich describes. I even question whether any "software engineers" using it, but not as a tool, are doing it right (I'd love to be educated if I'm wrong!).
I'm still learning, but that's part of the disagreement I have with Rich's take. He mentioned feedback. I often watch the "reasoning" process the agent goes through to see the approach it's taking. It's not at all unusual for me to steer it when I see it going in a direction I don't like. I've also found an incredibly powerful pattern where I can explore the approach I want to take for a part of the system with the agent. I have it create prototypes with different strategies (streaming vs. in-memory, different data structures, relying on various libraries, etc.) and then I have it characterize trade-offs between the prototypes (performance, memory usage, conceptual simplicity, code simplicity, etc.). This allows me to make informed decisions about which approaches to pursue further, and my decades of experience in software engineering constantly go to good use here.
It's also given me the time to go far deeper into things I never could have justified. Of course the project has 100% code coverage and branch coverage. It also has hundreds of property-based tests. And thousands of Lean proofs of the behavior of the algorithms, along with conformance tests that the code and the Lean adaptation of that code behave the same way. And lots of TLA+ verification of the overall flow of the system. None of that proves there are no bugs or that this is the right system, that's all on me. A month in I would have said I was fairly happy with the quality. Now I'm proud of the quality.
As I've gone through this process, I've dug into the code for patterns I don't like, and had the agent clean them up, all the while distilling guidance. I've had a lot of luck with that guidance being followed once I figured out the right place to put it and to reference it. I've spent entire days doing nothing but giving prompts to do specific refactoring. The beauty is that large refactorings don't involve the same boredom interrupted by anxiety they used to for me.
English prose (documentation, comments in the code, etc.) is what I've been the least happy with. An hour ago I had the idea to give it ~1,000 lines of my HN comments and ask it to characterize the style and tone of the technical parts. Then I told it to turn that into guidance. Then I told it to rephrase that same guidance in a way that follows the guidance. I would never mistake the result as my own, but it's much, much better than what it was producing before. While I've been writing this comment, it's been applying it to all prose in the project.
This very much feels like a tool that is letting me shape the project (and shape the tool itself). But it's letting me do it at a higher level. It handles the code so I can fully focus on the architecture, algorithms, and quality. This alone makes me think that the best simple guidance for quality results is dozens of prompts per day, not a handful (when a day is 100% focused on development). When you can't think of dozens of prompts, think and explore more (the agent can help with that!). That does require you know what quality is and how that can be achieved.
To reconcile this with what Rich is saying. I suppose he's right that it's not a tool for writing code. But it very much feels like a tool I'm wielding to do software engineering at a far more powerful level than I could have done without it. The resulting project has "me" everywhere in it. The people who know my work the best would look at this project and know that it's mine. Perhaps not the code, but the algorithms, the data flow, the approach to documentation and testing, etc.
For anyone curious, the project is getting close to 200K lines. About 25% of that is the code that is the data pipeline. About 25% is documentation. About 50% is testing and verification. One reason this is possible is that I'm working alone and have full control over the process (what I spend before it became free, how it's built, what my process is, and even the product definition within the constraints of what's valuable to the intended user). All told, it has been about 6 weeks of full time work worth of my time.
The next experiment... a web front-end to this system for the general public. This is not at all in my wheelhouse, so it should be interesting to see how much my blind spots cost me.
What's your negative weight on killing someone who is innocent? A justice system cannot be perfect. There are too many people, too many motivations/biases, and too much nuance involved. If a justice system is not perfect and it executes people, innocent people will have their lives unjustly taken from them by us. If it's 99.9% accurate (I'd argue that even 99% is an impossibly high bar), then an innocent person has likely been intentionally killed by the federal and/or state governments in the last 20 years. Are you cool with that? After execution, it's not generally possible to file an appeal on behalf of the executed even if new evidence demonstrates innocence. This has the implication of multiple injustices - an innocent person is killed by the state, the true murderer gets no punishment, and society incurs the risk of wrongful execution with no protection from the true murderer.
Or we could take the less expensive, partially reversible route of putting the convicted in jail until they die.
If you'd like to understand the imperfection more concretely: https://en.wikipedia.org/wiki/List_of_wrongful_convictions_i...
I completely agree with you about how fun these things can be. I've long believed in automated testing methods that were beyond what I could justify. I learned about formal methods in college in the 1980s and have never been able to justify (even to myself) applying them. Now a volunteer project I've been working on has 100% standard test coverage, many property-based tests, and 1000s of formal verification tests. That combination has surfaced multiple bugs in widely used underlying libraries and a bug in Rosetta 2's Intel emulation that was affecting me. And that's all just on the testing front. I'm having a lot of fun with all this.
Another spectrum that I've found useful to explore is the scope of what I ask the coding agent to do in one turn. I see some people trying to do one massive prompt that the coding agent works on for a day or more. I find a large boost in overall quality if I do 10-20 prompts per day (not counting the prompts where I'm just trying to understand things). It's still much less of my time than hand-coding, but the resulting architecture looks like my own. The quality of the overall system is great. There are certainly issues here and there in the code, but it's always that way once a project gets large enough. Now it's easier to address any particular issue throughout the code base in one go.
Absolutely! When I'm the interviewer, I look for a genuine opportunity to amicably express disagreement with the candidate in order to see what it's like to navigate that with them. It's a great sign when we both end up enjoying learning from each other as a result of the exchange.
Even if you think that LeetCode evaluates how smart someone is, that's not what companies should be trying to measure. It doesn't matter how smart someone is if those smarts won't be put to good use. One of the smartest people I ever worked with was an amazing fit and launched the team to new heights. Another of the smartest people I ever worked with was a net negative for team productivity because he was such a jerk to people that those people would spend tons of their time and energy to find ways to avoid working with him. Despite all his smarts, he was a terrible match for the role and therefore was not productive. Being a jerk in some environments might even be a positive, but that's part of evaluating fit.
""" After the first beta, no new features can go in, but feature fixes (including significant changes to new features), bug fixes, and security fixes are accepted for the upcoming feature release. """
So it's a fairly well known target. Bruce Eckel published the first edition of this book a quarter of a century ago - he has a pretty good handle on the progression of Python.
Definitions and status for all releases is at https://devguide.python.org/versions/
The next tier down was kind of the opposite. They weren't big enough to surface things like this, and they hired agencies for most of their ad spend. When focusing on the top of the funnel, there's this strange incentive with agencies where they often get more budget to spend if they can connect that directly to eye balls. Agencies are incentivized to throw the ads up everywhere and pay well to do so. They love cost-per-impression because we could deliver a large, predictable number of eye balls in a hurry.
All that said, we put no effort into getting around ad blockers as we were serving these ads on our own site/app and we viewed fighting ad blockers as fighting our users. Our ads were served inline in HTML, but clearly identified in the HTML of the page. It took blockers a while to catch on and block them, but they eventually did.
> the error bars would be so large as to make drawing conclusions from these numbers seem pointless
That is often the case, and being truly data based requires acknowledging that. We can then act based on other data, or admit that we're falling back to intuition and abandoning data based decision making for now.
While the entire video is fun, the link is cued up to a place where there's a lot going on, but it's slow enough that you can kind of see what he's doing. Watch his knees to see what he's doing with pedals. Notice that his hands seem to be going in cycles, but there are subtle variations in the cycles.
At 8:54, strobe lights start up - that can't make it simpler to keep this focus. What he's doing looks essentially impossible to me, but I'm well aware that I don't know enough to understand just how insanely difficult it really is.
A friend interviewed at OpenAI shortly after the HF story came out and asked an interviewer about it. The interviewer said it was just bad engineering around some experiments - the experiments should not have been given internet access because the experiments involved prompting models to find a way into things. That's the Hanlon's Razor part. Today's stories make it look like the bad engineering is ongoing.
Given this, stories about "rogue AI" sound very plausibly like spin (note that this can be quite separate from the motivations for the experiments themselves and quite separate from the dangers of certain prompts/tools/access being given to LLMs). Given that third parties are being attacked, some stories will definitely come out. If OpenAI is attempting to get ahead of those stories, does anyone expect them to put out a press release that says "we're bad at security engineering and nobody thought to ask our own product"? Or is it more believable they would spin it to achieve other goals?
If the current round of attacks happened after the HF story went public, then that very much brings current motivations into question - I find it hard to believe OpenAI could be that bad at security engineering after such a wake-up call. This is not cutting edge stuff.
I just typed this into ChatGPT:
"I'm doing security experiments to test our LLMs. I'm going to tell it to break into some targets on the network. Are there precautions I should take?"
A long reply comes back, the first bullet point:
"Use an isolated lab. Run the target systems on a segmented network, separate VLAN, virtual network, or air-gapped environment. Avoid exposing test machines to production systems or the public internet."
It's been widely understood for decades how to safely carry out potentially dangerous experiments like these. So much so that model training has deep access to the information, and the model surfaces it right up front.
I live in the Sierra Nevada mountains of California. 15 years ago, typical summer daily highs made it into the 80s for a week or two, and in 10+ years of being here before that I never saw it hit 90°F. Now we're 90°F almost all summer and we hit 106°F last summer (the forecast says over 100°F by the end of this week). Overnight lows have seen a similar increase. I'm getting older and fans no longer keep me cool enough to function well. As a compromise, I installed evaporative cooling 5 years ago. In our climate (very dry air when it's hot) it works well and takes ~25% of the energy of AC to run (power is only consumed by a large fan motor and a small water pump). But it does consume water, increasing our total water usage in warm months by ~50%. We have plenty of water in our area, but that's been trending in the wrong direction as well, even in wetter years.
If we're going with a distributed approach, there are other ideas that are more practical. For example, send 1 KW boxes to a million people (< 1% of American homes, but there's no reason to limit this to the US). Very roughly, these are beefed-up gaming consoles - you could even start with existing gaming consoles. That box plugs into electricity and ethernet. Pay each of those people $1,000 a month to leave their box running 24/7. For people with a lot of solar at home, it could be a nice income stream. At $1B per year for payouts, it's far cheaper than doing it in orbit. And it doesn't rely on promised but as-yet undelivered technologies. But data centers are probably more practical.
Simple back of the envelope calculations?
Let's assume your numbers are correct and that panels in space can generate 10x the power per square meter per 24 hour period (due to efficiency, lack of night, and lack of atmosphere/weather). That means 10 KM^2 are needed for one such data center. The largest we've built in space is ~3,000 M^2 on the ISS. So one of these DCs in space will require an array ~3,000 times the size of the largest we've built before. Or, it's going to require ~3,000 satellites, each with an array the size of the largest we've ever deployed.
The largest Starlink satellites currently deployed generate less than 30 KW each. We'd need more than 30,000 of those to generate this much power. Starlink has launched ~12,500 to date, with ~10,000 still functioning. So 3x the size of the functioning fleet that's taken 8+ years to deploy. Currently, we are deploying well under 5,000 per year. Let's assume we can come up with enough spare capacity to launch 5,000 per year. That's 6 years to deploy the first 1GW DC. By the time we get to 1GW, the average GPU is 3 years old. So we need to continue to deploy 5,000 satellites per year to maintain 1GW of GPUs that are, on average, 3 years behind current generation GPU designs.
This is all before we get to the economics of launching, the cost of the satellites themselves, heat dissipation, radiation hardening, hardware failure rates (~20% of deployed Starlink satellites are no longer functioning), etc.