Are there realistic ways of harvesting vegetables at scale that are underneath mounted solar panels, with all their supports?
Or is the idea that there aren't now, but they could be built?
I'm just imagining that you are going to need a lot of vertical clearance for tractors, and support posts will have to be widely spaced enough that the horizontal beams supporting the panels will have to be quite strong, and that at some point this is less solar panels in a field, and more like constructing a building with solar panels on its roof.
> Or is the idea that there aren't now, but they could be built?
It's hard to see how this would work well with corn, since corn is pretty tall, corn harvesters are pretty huge, and putting panels even high enough for a different set of smaller, realistic harvesters would still require supports that I can't imagine would be cost effective given all the other hurdles they would cause.
Other crops like cotton, alfalfa, and hay aren't as tall, but have the same harvesting problems.
Most harvesting efficiency gains are directly tied to GIGANTIC machines. Farming is insanely efficient and competitive. It's hard to see how smaller machines could be viable and no one would have discovered it until this tech.
I'd guess there is far more potential in grazing land (unrelated to this tech), which is already actively being developed at scale.
The good news is that as someone else pointed out, we mostly grow corn for energy, so in a way, this is more about getting the ground we use for corn back than it is getting more energy.
We are right at the point where fully automated harvesting machines start to gain ground. And removing the operator (or moving the operator outside the machine) allows for designs that are less tall. The benefit of wider and wider machines also shrinks with full automation, even if it doesn't fully go away
You can see there are already huge examples of this in Australia with sheep grazing under panels and it's just barely starting in New York state with a cornell pilot. In my opinion it's the future of electricity in agricultural areas.
Smaller scale market gardens could benefit. Many rely on more manual labor and smaller machines.
There are some small organic farms using a system of chained paper pots and frames to quickly fill them with soil and sow with seeds, then once they're sprouted you use a hand pulled machine that spreads the chain out while directly placing each plant into the soil automatically.
Exactly. I've recently been training a number of models, and the value to any potential competitor would be approximately zero.
It's so integrated with the specific inputs of my product, and the outputs that it needs, that the model just has no value to anyone else.
If a competitor needed such a model, they need to train their own that matches the form of their inputs and outputs, which is just going to be different.
As long as your training data itself isn't sensitive. If that's e.g. photos of products and you're training a quality assurance photo recognition software, that's probably fine, if it's unredacted support tickets, not fine.
I used to work at a company who used to do this, but I'd argue that it almost never does what you want re: concealing the input space. There are so many ways to recover the input space from the latents, and often they are constructed expressly to contain exactly enough information to do precisely that.
But how much effort would that require? ... is what I was going to say but in this age of "claude reverse engineer this doohickey" maybe the better question is how much compute and how many tokens it would require.
Large firms have a much harder time hiding that kind of behavior, and they have much more to lose.
Large firms require processes and controls around everything. If Amazon is peeking into corporate customers' data, then there have to be mechanisms designed to allow that, a whole bunch of people know, it's part of engineering designs, and a whistleblower is going to leak it to the press.
And then Amazon is going to lose all of its business customers once its privacy guarantees were shown to be intentionally circumvented.
It is simply not economically rational for a company like Amazon or OpenAI to look at the data of its corporate customers.
Regular consumers are a different story, because you need to respond to abuse, illegal activity, etc. So they don't have the same privacy guarantees.
But corporate customers, that stuff is watertight. No cloud provider is going to risk losing their entire business because they violated their privacy guarantees.
> If Amazon is peeking into corporate customers' data, then there have to be mechanisms designed to allow that, a whole bunch of people know, it's part of engineering designs, and a whistleblower is going to leak it to the press
An awful lot of this sort of thing in the corporate world is based on pinky-promises and legal threats, more than on robust technical controls.
Every production system I have ever seen has at least one set of dev-accessible keys that has access to the production DB. Mature systems at least had audit logging around who retrieved those keys, less mature systems often didn't have any kind of internal access logs.
Is "Amazon the corporate entity" snooping on your data? Absolutely not. Is someone with Amazon internal access snooping on your data? You'll never know either way.
Given that even non-Amazon vendors can use Amazon.com search features to discover bestselling products from third-party sellers in various categories, I doubt there's anything contractually prohibiting Amazon from using the same information to drive their own product mix.
Same goes for selling prices. Published retail prices are not trade secrets.
Agreed -- I only do 2 active things at a time, and maybe something third that is long-running in the background (like training a model or classifying thousands of files, where I just need to check in occasionally to make sure it hasn't veered off-track).
It's rare that with my 2 active things, they're both busy, since one usually finishes while I'm drafting my reply to the other.
When it occasionally happens that both are busy for the next 5 min, I just get to enjoy the break and stretch my legs and walk to the kitchen or something.
> It is not just a woman wanting to have sex with you. It will be the woman in your dreams.
This is really not true. Spies are just people, there aren't that many of them, and they don't come "customized". The overlap of effective spies and "the most sweet and the most pleasurable and gorgeous honey that there is in the world" is very close to zero.
What you are describing is conspiracy-theory thinking or the kind of stuff you see in James Bond movies. Not real life.
Obviously spies exist, like here, but she's just... a normal woman who has a job as a spy and tried to seduce him and succeeded. He may have turned down five others who failed miserably in their attempts.
And sure they try to put together a psychological profile of the person, but that's also not really rocket science, and it's going to be pretty basic stuff. "Your weaknesses" is not going to be that exciting. Maybe he's really into expensive wines. It's not like he has a secret gambling addiction.
So let's just keep this reality-based and not fantasy-based.
> The overlap of effective spies and "the most sweet and the most pleasurable and gorgeous honey that there is in the world" is very close to zero.
The overlap doesn’t have to be that great. The spies are also not random you don’t get random spies matching with random CEOs. They just have to have enough available agents and enough info on the target, physical proximity, and other factors to attempt something to work out. In many cases it’s not something that will be in the news either. It will be just a failed attempt, or just an affair.
A nerd thinking a woman is into them...that is the fantasy...No she did not happen to bump into you in the elevator, and no she is not there to attend the same AWS conference that you... and oh no... she does NOT happen to like the same SciFi you do ...and no ...you are not ohh so funny...
Again, this isn't some low-level clerk that just needs a handjob or some Grindr kompromat--this is the CEO of the second largest company in the world by market cap.
Is it the assertion was that they'll do research on you (which is why having a gambling problem, large debts, or lying during a clearance interview is an issue)?
Is it the assertion that they'll pick a very pretty woman instead of some plain-looking one (which is why historically the NKVD recruited from theater and ballet schools)?
The "Hollywood fantasy" is real, it just happens in a vanishingly small set of cases.
This part. Not the research, not that they may be attractive. The part where they're supernaturally sculpted and emphatically unimaginably irresistible.
> They will employ the most sweet and the most pleasurable and gorgeous honey that there is in the world to create the perfect Honey trap.
> Normal people just can not imagine how sweet, specially when it has been customised around your needs and desires.
> It is not just a woman wanting to have sex with you. It will be the woman in your dreams.
I appreciate the link to Shi Pei Pu, that was an interesting read! Less strange than a literal Greek siren, but much stranger than the truth of Jensen's situation.
This seems entirely reasonable to me. And to people complaining that this is censorship, it is absolutely not. You can still type these words just fine, it's just not going to interpret swipes that are inherently probabilistic and often ambiguous as potentially risky terms.
This seems like a feature, because I swipe all the time and send messages without realizing I got a word wrong, especially because the word it chooses is usually with the same first letter and approximately same length.
All this is doing is avoiding high-risk words and terms, and making you type them out letter by letter to ensure you aren't sending an accidentally sexual/swear/political message to your Mom/boss/colleague.
This would be problematic and censorship if it were preventing you from typing the phrases at all. It's clearly a helpful feature, however, to prevent you from accidentally typing risky phrases when using something as error-prone as swipe typing.
I'll give you that one. I'd missed that in the article. That just seems like bad taste on Apple's part.
But still, the overall idea seems like it does more good than harm to the end user. I really don't think it is making anybody change their mind about what they ultimately type and communicate.
AUTOMATIC PRICE UPDATES
New pricing information automatically pushes to marketing website and ILS listings in real time.
During a six month study with an Entrata client using Entrata Pricing, market rents grew 15% more than a comparable set of properties within the same company.
Their marketing documents admitted to the exact same behavior.
No one cared about those of us hurt by this company to even bother filing a lawsuit against them.
It almost certainly does not explain it, and is probably just a coincidence.
Claude Code is not sending your email address to websites as a default, or regularly. It is not some automatic header or anything.
Rather, if you are performing certain kinds of research on sites that involves downloading certain kinds of information, like on Wikipedia or the SEC, it supplies your e-mail address when the sites request it as part of their download policy. As part of anti-bot policy. Obviously Claude should have asked for approval first, but Claude isn't out there just spamming your e-mail address in every external request it makes or anything.
Wikipedia and the SEC are not selling your e-mail address to spammers. And these are the two main sites where it has come up.
Yep it’s mainly happened to me when I was playing around with the EVE Online API via Claude. The game developer asks everyone to put their emails into the request headers so they can contact users to fix their buggy scripts and stuff.
I burnt a few tokens to get some clarity on this (giving HN as source as well, so there is a reference to this thread):
> This doesn't appear to be Claude Code automatically attaching your email address to every outgoing request. The issue is that Claude has access to your account email in its context and can sometimes include it when generating HTTP requests (e.g. "curl" commands).
> Wikipedia and the SEC were mentioned because they explicitly ask automated clients to identify themselves through the "User-Agent" header, often with contact information. Claude may try to comply with those requirements by inserting your personal email address.
> That's why the leak is probably concentrated on sites with these policies, rather than happening on every website. But Wikipedia and the SEC aren't an exhaustive list (the EVE Online API was also mentioned), and there's no technical guarantee that Claude couldn't include the email in requests to other domains.
> The important distinction is that this appears to be model-generated behavior, not a networking layer automatically adding your email to all requests.
> So "most likely Wikipedia and SEC" is a reasonable hypothesis about where the leak is more likely to occur, not a confirmed limit on where your email could have been exposed.
I do see a lot of times curl being used (in Claude). I don't check all the websites being fetched (shame on me!), but your answer doesn't convince me.
My coincidence is clearly not proof. I am just a random online guy so why trust me. I just shared my recent experience. I used extensively copilot until roughly 3 weeks ago (I went all in on Claude, to try it out properly), and that's when I started to see a lot of spam on my work account. Coincidence? Yes. Correlation? Yes. Causation? No. And I personally don't care because I assume my work email account is somewhere to be harvested, but when I then see such a but report, it kind of rang a bell like WTF. I am as careful as possible about the requests I send, but I cannot remove the UA or know everything the harness is doing behind the scenes.
This type of bugs kind of kills the trust in the tooling. On the other hand, we're being told to use more and more such black boxes.
No, it's nothing to do with your baseline coding ability, and everything to do with the type of task.
If it's the kind of thing that requires a lot of iterative back-and-forth, like tweaking UX design, then there may be little speedup.
If it's the kind of thing where you there is a clear pass/fail, e.g. writing software to satisfy a comprehensive test suite that is black and white, then it could be 1000x.
The better-defined the task is and the more the agent can evaluate its own success, the bigger the multiplier.
Also, obviously, the more you are working in an area that is more unfamiliar to yourself, the bigger the multiplier.
That's why one morning I'll feel like it's maybe just 2x as it's constantly testing an app in an iOS simulator to see if a UX bug got fixed. That afternoon it might be 10x as it works on some pure code fixes that I still need to verify manually if they work. The next morning it might be something like 200x as I have an incredibly well-defined task that requires a lot of algorithmic research and 10,000 lines of code, but where the end result is easily provably correct or not. That afternoon it could be essentially "inifinity X" as it fixes a problem in a programming language I'm not even familiar with, in a domain it would take me months to get up-to-speed on, in a library I don't know, which solves a bug that is blocking me. Because it's just not something I could have realistically done at all.
So it's incredibly task-dependent. But it's pretty much always faster to some degree. Sometimes a little, sometimes a whole lot, sometimes so much faster it's still a little hard to believe.
For the generic average dev pushing SaaS features, it's way faster. For the kind of stuff where the coding is essentially all boilerplate/connector, something like Claude shines. Because there's already a pattern for everything in the codebase.
If you are able to parallelize your work, e.g. work on 2 or 3 features at a time, your coding time goes down to essentially zero, or rather the time it takes you to write the prompts (hint: use dictation if you're working from home), and all your work is now spent on all the same design and manual testing you were doing before. So depending on what proportion of your time was spent on design/testing vs. writing actual code before, your generic/average dev can see a productivity boost of anywhere from 2x to 20x. It really just depends on what proportion of their job they actually spend literally writing code.
Pre AI a developer would come out of a product meeting knowing at a high level of what to build. Maybe a few key bullet points get written up in an issue tracker somewhere, but beyond that there's no additional design phase, highly detailed specifications curation, prompting, planning back and forth with an agent etc. A good dev has an intimate pre-existing understanding of the codebase, and immediately can just move to the actual implementation (writing code). The plan is in their head, and can go directly to code. And there's no huge agent written code diff to review at the end, and any manual testing happened along the way as code was manually written.
And FWIW, I'm not arguing against a productivity boost. I've tried the tools. But for me, it was nowhere near 10x, especially when working through a brand new feature or module. Maybe 2x, 3x? Though even that seems generous in some cases. And you give up a lot to get that boost with changing the way you work.
Agreed it's higher and probably closer to a 5x-10x for some boilerplate copy/paste duplication or extension of an already existing feature.
They are a force multiplier. Unfortunately for my bargain bin offshore strategic partner contractors who were a negative force to begin with, they are now negative 100xers.
Or is the idea that there aren't now, but they could be built?
I'm just imagining that you are going to need a lot of vertical clearance for tractors, and support posts will have to be widely spaced enough that the horizontal beams supporting the panels will have to be quite strong, and that at some point this is less solar panels in a field, and more like constructing a building with solar panels on its roof.
reply