When you think about it, "vibe coding" kinda enables gambling, but with software.
You set up your prompt, CLAUDE.MD, include the source files and let it rip. It gets some things right, some things wrong. You fix some things manually, /clean and go again. Sometimes you gotta throw it out and start over. Feels like "most players stop just before striking it big".
AFAIK, modern wind turbines use types of induction motors because it allows them to adjust the rotation speed by applying a counter-rotating stator field (which is a very neat trick) - older turbines had to rotate at a fixed divisor of 3600 rpm (grid frequency).
It makes sense if you think of a prompt not as a way of telling the LLM what to do (like you would with a human), but instead as a way of steering its "autocomplete" output towards a different part of the parameter space. For instance, the presence of the word "mysql" should steer it towards outputs related to MySQL (as seen on its training data); it shouldn't matter much whether it's "mysql" or "MYSQL" or "MySQL", since all these alternatives should cluster together and therefore have a similar effect.
I second that. Hearing in the VASAviation video (linked by someone else in a nearby thread) the robotic voice announcing what it's doing, while it does a completely autonomous landing in an airport it autonomously decided on, with no possibility of fallback to or help from a human pilot, is one of these moments when we feel like we're living in the future promised by the so many sci-fi stories we've read as children.
That's only if the distro is recent enough; sooner or later, you'll encounter a box running a distro version from before /etc/os-release became the standard, and you'll have to look for the older distro-specific files like /etc/debian_version.
> you'll encounter a box running a distro version from before /etc/os-release became the standard
Do those boxes really still exist? Debian, which isn't really known to be the pinacle of bleeding edge, has had /etc/os-release since Debian 7, released in May 2013. RHEL 7, the oldest Red Hat still in extended support, also has it.
> the oldest Red Hat still in extended support, also has it.
You would be alarmed to know how long the long tail is. Are you going to run into many pre-RHEL 7 boxes? No. Depending on where you are in the industry, are you likely to run into some ancient RHEL boxes, perhaps even actual Red Hat (not Enterprise) Linux? Yeah, it happens.
Yes, they do. You'll be surprised by how many places use out-of-support operating systems and software (which were well within their support windows when installed, they have just never been upgraded). After all, if it's working, why change it? (We have a saying here in Brazil "em time que está ganhando não se mexe", which can be loosely translated as "don't change a (soccer) team which is winning".)
> The easiest thing would probably to specify the need for "x86-64-v3"
AFAIK, that only specifies the user-space-visible instruction set extensions, not the presence and version of operating-system-level features like APIC or IOMMU.
> But putting the ticket number in the commit ... that's basically automatic, I don't know why it should be that big a concern. The branch itself gets created with the ticket number and everything follows from that, there's no extra effort.
That poster said "attach a JIRA Ticket to the PR", so in their case, it's not that automatic.
A lot of Jira shops use the rest of the stack, so it becomes automatic. The branch is named automatically when created from a link on the Jira task. Every time you push it gives you a URL for opening the PR if you want, and everything ends up pre-filled. All of the Atlassian tools recognize the format of a task ID and hyperlink automatically.
I haven't dealt with non-Atlassian tools in a while but I assume this is pretty much bog standard for any enterprise setup.
Probably not a joke. In the same way people want to get away from the C language due to its propensity to memory vulnerabilities, shell scripts have their own share of footguns, the most common being a variable not being quoted when it should (which is exactly the issue described in this advisory).
It doesn't mean getting away from scripting languages; it means getting away from shell scripts in particular (the parent poster said specifically "zero shell scripts"). If the script in question was written in Lua, or heck even Javascript, this particular issue most probably wouldn't have happened, since these scripting languages do not require the programmer to manually quote every single variable use.
That's fine; I just thought it was weird to say that we should check to see whether any shell scripts are used in the BSD init system. We know there are; it was a deliberate design decision at the time, even if we might now wish for it to be different.
> Traditional stereo won't help you localize them [...] and LIDAR sacrifices resolution for weight and power consumption
I wonder if a more mechanical solution wouldn't help:
Whiskers, like on a cat. A long enough set of thin lightweight whiskers could touch the wire before the propellers do, giving time for the drone to stop and change course. Essentially, giving the drone a sense of touch.
I hadn't thought about this in a long time. Looks like her lab is still going strong doing research at the intersection of biology and robotics on whisker-based sensing:
Thin lightweight whiskers are going to be challenging to manage on a propeller-driven vehicle. They'll get blown all over the place. Having them extend out past the propellers will likely get them tangled in the propellers.
But that's fine, isn't it? If they're intended to detect fixed objects, then noticing that one or more of them have ceased to be blown around in that way may be a good way to detect unanticipated contact with a fixed object: When the signal becomes less noisy, then maybe something is in the way.
And the whiskers don't have to be all floppy like a wet noodle. I myself am thinking that something rigid or semi-rigid might be good. Perhaps something akin to armature wire, or thin spring steel. Maybe even literal bamboo chopsticks.
They can also be constrained so that they don't get sent into the props.
My little brain thinks that the drone-end of the whiskers can be attached to potentiometers, with light return springs to bring them back towards center, like the mechanism used by an analog stick on a PS3 controller.
> And the whiskers don't have to be all floppy like a wet noodle. I myself am thinking that something rigid or semi-rigid might be good.
I don't think you're right about this. The concept of the whiskers is to notice when you've collided with something. Real whiskers aren't rigid because colliding with something when you're rigid means snapping. (Ever stub your toe?)
Think of the rigidity of the whiskers as being traded off against your maximum movement speed.
Suppose I've got an assembly with a chopstick attached to a gimbal with some minor centering springs and sensors (potentiometers) inside. The chopstick has many degrees of free angular movement provided by this gimbal and overall assembly.
I gently bounce ("slam"?) that chopstick off of a thing, and this results in the feedback loop that provides positioning control to provide immediate instruction to back off in the opposite direction of the apparent impact.
Does the chopstick take damage? Does the gimbal take damage? Does the greater assembly take damage?
Why, or why not?
(I feel like we're speaking two different languages here. Have you ever looked at how a PS3 analog stick works, or have you not? It's not new tech. It wasn't even new when it was new, and it's very nearly 20 years old now in PS3 form.)
Yes, you've successfully confirmed: We're quite clearly speaking different languages.
(Good luck with...whatever it is that you may be talking about. My diction is good. I don't have time or patience to explain it for outliers who aren't following along well and who also insist that it must somehow be wrong. I apologize for this; I am actually sorry.)
Rigid whiskers have other sets of problems. Below someone mentioned that rigid whiskers will break when they contact objects. If the whisker is as rigid as the drone itself, it plausibly breaks the same cables that the drone breaks. You also have the problem that in the event of drone failure, you now have a spike-covered drone falling out of the sky. What kind of damage does a bamboo chopstick or thin piece of steel do when it hits someone or something at ground level at drone-falling velocity with the mass of a drone behind it?
It's quite possible that these problems are solvable and can be engineered around, that there's a whisker-based solution, but I don't see it. It's certainly not an obviously workable solution.
A cage around the drone, there are kids toys like this, and also commercial products for inspection. Prevents contact with other objects, contact can be sensed and reacted to. https://www.flyability.com/elios-3
Doesn't protect against everything, like Spanish Moss which dangles from trees, but that is a lot bigger than a long thin wire.
> It's not only xor that does this, but most 32-bit operations zero-extend the result of the 64-bit register. AMD did this for backward compatibility.
It's not just that, zero-extending or sign-extending the result is also better for out-of-order implementations. If parts of the output register are preserved, the instruction needs an extra dependency on the original value.
That sounded a lot like the "have fun staying poor" argument from the peak cryptocurrency days.