Only for some use cases. I don’t think the parent is arguing for forcing compaction. I’d personally use this with periodic compaction (cronjob), but I can see the utility either way.
Not to get into an iOS vs Android thing, because that’s not the point (it’s okay to appreciate both or neither, you do you).
But this is one of the things I really would love to have on my iPhone that I’m jealous of the Android ecosystem for. I know there are alternatives for iOS and I’ve used them (no need to list them here, this thread isn’t about iOS). For me, a really good terminal/CLI with good integration with the OS would be killer. But I know I’m niche and unlikely to see such a thing outside of SSHing to a remote VM.
It’s not theater. It introduces friction into the process. And when there is friction in both choices (read the paper, or take a photo and upload the picture), you’ll get more people reading the physical paper copy. If students want to jump through hoops, they will, but it will require an active choice.
At this point auto AI summaries are so prevalent that it is the passive default. By shifting it to require an active choice, you’ve make it more likely for students to choose to do the work.
That friction is trivial. You are comparing the effort of snapping a photo against the effort of actually reading and analyzing a text. If anyone chooses to read the paper, it's because they actually want to read it, not because using AI was too much hassle.
You can certainly make it harder to cheat. AIs will inevitably generate summaries that are very similarly written and formatted -- content, context, and sequence -- making it easy for a prof (and their AI) to detect the presence of AI use, especially if students are also quizzed to validate that they have knowledge of their own summary.
Alternately, the prof can require that students write out notes, in longhand, as they read, and require that a photocopy of those notes be submitted, along with a handwritten outline / rough draft, to validate the essays that follow.
I think it's inevitable that "show your work" soon will become the mantra of not just the math, hard science, and engineering courses.
Any AI app worth its salt allows you to upload a photo of something and it processes it flawlessly in the same amount of time. This is absolutely worthless teather.
It’s not the time that’s the friction. It’s the choice. The student has to actively take the picture and upload it. It’s a choice. It takes more effort than reading the autogenerated summary that Google Drive or Copilot helpfully made for the digital PDF of the reading they replaced.
It’s not much more effort. The level of friction is minimal. But we’re talking about the activation energy of students (in an undergrad English class, likely teenagers). It doesn’t take much to swing the percentage of students who do the reading.
Are you really comparing the energy necessary to read something to taking a photo and having an ai read it for you. You are not comparing zero energy to some energy, you are comparing a whole lot of energy to some energy.
Cities can largely do what they want. They can deny applications for whatever reason they want. Citizen concerns are very important here (they need to keep voters happy to keep their jobs). But their main mandate is to protect the public good. If a project isn’t in the interest of their community, they ca deny it.
Whether or not it’s legal is another question. And NIMBY and… and… there are lots of potential concerns. But this article is about Wisconsin, where the question is really what are we going to do with this land and how are going to power it.
Your post mentions a lawsuit near you. This is a feature, not a bug. Even if the city is unlawfully denying an application, the denial still has the desired effect — a de facto denial for the length of time it takes to resolve in the courts. By dragging out the time for a lawsuit to be resolved, the city hopes that the developer will just go away and find someplace else.
This is in the context of not knowing the entity behind the application, and evaluating it on its merits alone. I'm not convinced that's a bad thing. Kindof like evaluating a resume without knowing the name or gender of the applicant.
Cities are bound by laws, and not complying opens them up to lawsuits which the taxpayers pay for. Sure, maybe that's in the best interest of the community in some cases. However, I think it usually happens because people have feelings and biases rather than as a calculated move.
The more I think about your comment on statistics, the more I change my mind.
At first, I think you’re right - these are (thankfully) rare events. And because of this, the accident rate is Poisson distributed. At this low of a rate, it’s really hard to know what the true average is, so we do really need more time/miles to know how good/bad the Teslas are performing. I also suspect they are getting safer over time, but again… more data required. But, we do have the statistical models to work with these rare events.
But then I think about your comment about it only being 30 cars operating over 6 months. Which, makes sense, except for the fact that it’s not like having a fleet of individual drivers. These robotaxis should all be running the same software, so it’s statistically more like one person driving 500,000 miles. This is a lot of miles! I’ve been driving for over 30 years and I don’t think I’ve driven that many miles. This should be enough data for a comparison.
If we are comparing the Tesla accident rate to people in a consistent manner (accident classification), it’s a valid comparison. So, I think the way this works out is: given an accident rate of 1/500000, we could expect a human to have 9 accidents over the same miles with a probability of ~ 1 x 10^-6. (Never do live math on the internet, but I think this is about right).
500,000 / 30 years is ~16,667mi/yr. While its a bit above the US average, its not incredibly so. Tons of normal commuters will have driven more than that many miles in 30 years.
That’s not quite the point. I’m a bit of an outlier, I don’t drive much daily, but make long trips fairly often. The point with focusing on 500,000 miles is that that should be enough of an observation period to be able to make some comparisons. The parent comment was making it seem like that was too low. Putting it into context of how much I’ve driven makes me think that 500,000 miles is enough to make a valid comparison.
But that's the thing, in many ways it is a pretty low number. Its less than the number of miles a single average US commuter will have driven in their working years. So in some ways its like trying to draw lifetime crash statistics but only looking at a single person in your study.
Its also kind of telling that despite supposedly having this tech ready to go for years they've only bothered rolling out a few cars which are still supervised. If this tech was really ready for prime time wouldn't they have driven more than 500,000mi in six months? If they were really confident in the safety of their systems, wouldn't they have expanded this greatly?
I mean, FFS, they don't even trust their own cars to be unsupervised in the Las Vegas Loop. An enclosed, well-lit, single-lane, private access loop and they can't even automate that reliably enough.
Waymo is already doing over 250,000 weekly trips.[0] The trips average ~4mi each. With those numbers, Waymo is doing 1 million miles a week. Every week, Waymo is doing twice as many miles unsupervised than Tesla's robotaxi has done supervised in six months.
> I can almost guarantee this is from some endpoint management software your company installed.
I know you're getting hammered on this, but this is also an indicting statement. If your brand-new OS requires you to have endpoint management that locks it down so much that it affects how long it takes to open files, that's on the OS, not the endpoint management.
Okay, it's on both... endpoint management as a rule is horribly written software, which is shocking knowing how intrusive it is into the system. But, if the OS has so many vulnerabilities that you're required to have endpoint management, that's not a good look on the OS.
My current and former $JOB both required endpoint management on Macs (and a limited amount for folks who used Linux), so it's not a blanket statement. But the impact of the endpoint software on Mac and Linux were still much lower. That is, once I figured out that a certain (redundant) enterprise firewall was crashing my work Mac anytime I plugged in a USB network adapter.
It seems to me that jargon would tend to be defined in one language and minimally adapted in other languages. So I’d not sure that would be much of a concern.
I would look at non-English research papers along with the English ones in my field and the more jargon and just plain numbers and equations there were, the more I could get out of it without much further translation.
I recently had Codex convert an script of mine from bash to a custom, Make inspired language for HPC work (think nextflow, but an actual language). The bash script submitted a bunch of jobs based on some inputs. I wanted this converted to use my pipeline language instead.
I wrote this custom language. It's on Github, but the example code that would have been available would be very limited.
I gave it two inputs -- the original bash script and an example of my pipeline language (unrelated jobs).
The code it gave me was syntactically correct, and was really close to the final version. I didn't have to edit very much to get the code exactly where I wanted it.
This is to say -- if a novel language is somewhat similar to an existing syntax, the LLM will be surprisingly good at writing it.
I was talking to a product manager a couple weeks ago about this. His response: most managers have been vibecoding for long time. They've just been using engineers instead of LLMs.
Having done both, right now I prefer vibe coding with good engineers. Way less handholding. For non-technical managers, outside of prototyping vibe coding produces terrible results
I can’t really take this too seriously. This seems to me to be a case of asking “can an LLM do X?” Instead, the question is like to see is: “I want to do X, is an LLM this right tool?”
But that said, I think the author missed something. LLMs aren’t great at this type of reasoning/state task, but they are good at writing programs. Instead of asking the LLM to search with a drone, it would be very interesting to know how they performed if you asked them to write a program to search with a drone.
This is more aligned with the strengths of LLMs, so I could see this as having more success.
reply