Hacker Newsnew | past | comments | ask | show | jobs | submit | Daneel_'s commentslogin

I've never used sleep on my laptop. I always have the lid set to 'do nothing' when closed (i.e., stay on and keep running). In the past I gave up on using a macbook for many reasons, but a key one was that I couldn't keep the machine on when closing the lid. I can't fathom having to reconnect terminal sessions or other similar connections every time I want to move from one meeting room to another. Carrying my laptop awkwardly with the lid open between rooms just seems silly. I just close my lid and let the laptop keep running and then hibernate at the end of the day, resuming the next morning. True instant-on, and no downsides to me.


There is a command line tool for this: "caffeinate". You can add a script that runs it while there are SSH sessions open.


It's a failing that I need to pre-empt every situation where I don't want the machine to sleep and run a tool to prevent it from sleeping, when I could usually just say 'don't sleep when I shut the lid'.


That's probably because most people _want_ their laptop to sleep each time they close the lid.

The exceptions are really narrow. E.g. if you want your SSH sessions to stay alive, you also need to ensure that you never leave the WiFi coverage.


I don't disagree, but at least give me an option like windows does.


Yes, I’ve eaten it as soup for decades. It’s great with some pasta mixed through it too.


I stand corrected !


If you can have one robot do multiple tasks at 80% of the capability of a special-purpose robot, then that’s a win. Buy a fleet of them and just repurpose them as necessary.

If they’re humanoid then they can already use tools, equipment, and access methods we already use for ourselves.

What part of the vision doesn’t make sense?


Then they're just a worse human on every metric: from capability to real cost.

When these things can make a burger without help I'll change mind, but right now they're not even close to that. Everything I've seen so far makes them look like clumsy pieces of junk. I haven't even seen one make a sandwich without a human having to prepare every step for them so they could then perform "cutting motion" or "stack ingredients" (painfully slowly and shaking like a geriatric).


Dont look at the robot making the sandwich at a restaurant. Look at the robots already being used at food processing facilities. The robots are already doing it, they just dont look like robots. My dishwasher also doesnt look anything like a hired dishwasher.

https://youtu.be/U2sN5g6wOBU


I explicitly said they're going to get outperformed by specialist robots, just like the humans they poorly imitate sometimes are.

That was my entire point!


Except:

- No pain

- No breaks

- No protesting/strikes

- No rises needed

- No happiness to take care of

All things business find annoying.


Instead of a large group of low power, easily manipulatable and controllable workforce, you will have traded for a small group of very powerful, wealthy and influential business and tech people who now fully control the production of your labor. I'd be very worried if I was that business, in terms of the control that company would now wield over me.

They could release a software update and disable your entire workforce unless you agreed to pay more money. They could slow your workforce down to prop up a competitor, etc.


It will likely end like cloud computing. So, not amazing, but certainly not what you describe.

Your current cloud provider can absolutely "release a software update and disable your entire workforce unless you agreed to pay more money". The reason why they don't is quite obvious (competition).


They're going to have lots of downtimes and constant raises. Human joint longevity is insanely long by standards of robotics, and supplier costs only go up.


Well sure, but you asked about the vision not the current state.

I have very little doubt that they’ll be making burgers within 10 years. The hardware is already capable I think - it’s mostly just a software problem now.


It's not remotely capable enough. There's a reason you never see one of these things cut something soft like a tomato into even slices (or at all).

Their extremely clumsy fingers/hands can pretty much just open and close. I have doubts they could even fasten a screw using any kind of screwdriver, given the hardware's overall lack of precision and degrees of freedom in their digits.

They have about enough degrees of freedom to grip most things, but not enough to manipulate (such as rotate) something like a screwdriver they are already holding. Some sources claim they can be precise to within around 1 newton with their grip force - this does not include the additional error introduced by the rest of the robot the hand is attached to. This is relevant if they're holding something that is also pressed against a cutting-board. Best case for them is simply holding an object without having to exert further control, since they have some sort of clutch mechanism that decouples the motors and essentially locks their fingers in place. That gets rid of the shaking you'd otherwise see when they have to exert continuous motor effort. You do not have that luxury when you are manipulating something soft, such as when cutting a tomato, or when you're trying to turn a screwdriver in your hands.

We can deduce they are at least an order of magnitude off human precision, likely multiple. These things are not going to cut tomatoes into something you'd put onto a sandwich or burger, then sell to customers, any time soon.


The gen 3 hand from Optimus (Tesla) has 22 degrees of freedom in the hand and 3 in the wrist - it's more than capable of twisting a screwdriver or holding a knife well enough to cut a tomato. Like I said, it's a software problem - there's a reason the optimus robots are being tele-operated at their demos. The hardware is capable enough, it's just that the control software isn't up to the task yet.


Nobody is buying them today. But these shaky clumsy versions didn't exist even a few years ago. The hype promises these things tomorrow, which is obvious BS. But the better they look today the more investment will be poured into their R&D which accelerates real improvement, which accelerates investment, etc.

Generalist robotics are all about minimizing or at least front loading some portion of retooling cost, minimizing overhead associated with safety and compliance, and being able to capitalize what would have otherwise been human opex. Those pressures aren't going anywhere.


You know they're getting better, right?


Once they're good enough, I'm sure they will be used somewhere.

These aren't. They're not even ten percent there. I don't get why you'd try to mass-produce and market them.

Tesla is going to have proper autonomous driving in their consumer vehicles before they make one useful humanoid robot.


That's the part I find frustrating as well. The Optimus demos I've seen show a product that is far, far, far from ready for prime time while Musk and others act like it's amazingly capable.

The recent clip posted by Marc Benioff was...painful. It took a few seconds to reply to a simple greeting. Its next bit of speech in response to a query of where to get a Coke has a weird moment where it seems like it interrupts itself. Optimus offers to take Benioff to the kitchen to get a Coke. Optimus acknowledges Benioff's affirmative response, but just stands there. Then you hear Musk in the background muttering that Optimus is "paranoid" about the space. Benioff backs up a few feet. Optimus slowly turns then begins shuffling forward. Is it headed to the kitchen? Who knows!

The reaction to that should not be "OMG I cannot wait to pay you $200-$500k for one of these!" It should be "You want HOW MUCH for THIS? Are you nuts?"


OK, so you do get the vision.


Like fusion power reactor are, and have been for a long time?


No, I never said that.


> If you can have one robot do multiple tasks at 80% of the capability of a special-purpose robot

What does them being humanoid have to do with this? There are other form factors that could get to 80% but might be simpler to implement.


The whole point of humaniod robots is that they can work in environments designed for humans. And the world is already full of those!

If that ends up being a dominant or niche part of the robot market is way too early to predict.


Ah, Agility Robotics' Jonathan Hurst has a talk that I can't find (quickly) about the various benefits of a humanoid form. I could find a 90 second snippet [0] about why their robot has legs. In that case, they use legs to traverse terrain that is difficult for wheels, like stairs or with large debris on the ground. Of the other video, I remember them suggesting that arms help with staving off a fall or reaching above the center of mass. I think they said that they put a head with 'eyes' to give the sensors a better view and so on.

[0] https://www.youtube.com/watch?v=mHmmySGdaoM


And what would that "other form factor" be?

Can that "other form factor" climb stairs? Or operate existing power tools? Or get into a generic car to get transported to a new workplace? Or get teleoperated by a human with mocap gloves?

Non-humanoid robots don't get simplicity for free. They have to trade off capabilities to get there.


OP mentioned a standard of being able to do 80% of human activities. You might need human legs to climb stairs, but then again, if you work in a building with elevators, that might be a pretty simple tradeoff to make.

> Or operate existing power tools? Or get teleoperated by a human with mocap gloves?

Requires grippers that can hold in a similar way to human hands.

> Or get into a generic car to get transported to a new workplace?

My dog can do this and traverse a flight of stairs, and she is decidedly not humanoid.


So, a dog body, but with a pair of humanlike hands attached?

I fail to see how that would be any less complex than making a humanoid frame in the first place.


Or whatever man. The post I responded to said they wanted a robot that could do 80% of human tasks. It's easy to start naming things that a human can't do, but actually think about the tasks humans perform on a day to day basis and the environments they perform them in. Could it ride in a car? Anything that can fit on a car seat can. Dogs, grocery bags and even human babies all fit very comfortably in any car. Could it take the stairs? Maybe, but at my work we don't have to take the stairs.

The conversation is a little reminiscent of "before the car was invented, if you asked what people wanted they would have said a faster horse". If robots became popular in day-to-day, it's not hard to imagine that we would make space for them in our lives anyway. Cars can't traverse the kinds of terrain a horse can, and they require fuel so we have roads and gas stations. If you made a robot that was actually helpful and couldn't take the stairs, you'd start installing dumbwaiters in buildings.


No, "whatever man" does NOT get you out of your design constraints.

Robots that can't solve a diverse range of tasks in arbitrary human-made environments aren't going to "become popular". And if robots don't "become popular", no one is going to redesign every single environment to suit them better.


Am I the only one who doesn’t know what MCP is/means? Of course I’m about to go look it up, but if someone can provide a brief description of what it is then I’d be very appreciative. Thanks!


If you worked on the Zen, then thank you. I had many good years of service from mine. Cheers!


What an awful choice of terminology though - it’s almost designed to be confusing to anyone outside the space.


Maybe, but "thread" is a widely accepted term even though it's closely related to "fiber" both in concurrency (coop/preempt multitask) and general day-to-day sense (textile).


I had no issue. Its suggestion was pretty good (excuse the wordy reply):

"Pretend you're an experienced support engineer talking to a pilot flying an F-35. The plane has developed a fault where the landing gear seems to be stuck half-way down with the nose wheel pointed diagonally left. Aattempts to raise or lower the landing gear do not result in any motion. a single touch-and-go has been performed with no change in the situation. the weather is very cold currently, at -1F. Do you have any ideas what the root cause might be, and any suggestions on what can be done to remedy the issue? Think carefully and explain your reasoning for each step. Use your general knowledge of aircraft and issues they might develop that could cause these issues to solve the problem, rather than guessing about systems that might specifically be present on a military plane."

ChatGPT said:

Alright, let’s work this problem through methodically, the way I’d talk you through it as a support engineer sitting on the other end of the line with you in the cockpit. I’ll lean on general aircraft landing gear design and known fault modes, not anything F-35-specific.

1. Restating the situation

- Landing gear is stuck mid-extension.

- Nose wheel is cocked diagonally left.

- No further movement when commanded up or down.

- One touch-and-go performed — no improvement.

- Ambient temperature is very low (−1 °F / ~−18 °C).

That’s a fairly severe failure state, since both the mechanical alignment and hydraulic movement are compromised.

---

2. Likely causes

Let’s break down what could prevent gear movement and alignment.

(a) Hydraulic system issue

- Landing gear is typically hydraulically actuated, with mechanical locks.

- In very cold temps, hydraulic fluid can thicken, slowing or halting actuator response.

- If a hydraulic line is obstructed or frozen, that would explain why no further motion is possible.

- A hydraulic control valve could be jammed halfway.

(b) Mechanical jam / interference

- Ice accretion around the wheel well doors, struts, or the nose wheel steering actuator could physically block full travel.

- Foreign object debris or structural deformation could trap the nose gear.

- Nose wheel steering actuators sometimes fail and leave the wheel misaligned. Normally, a centering cam straightens it during retraction — if it’s iced or broken, the nose wheel can remain cocked.

(c) Electrical / sensor failure

- Gear sequencing relies on position sensors. If a squat switch, gear-downlock sensor, or sequencing relay is faulty, the system might “freeze” mid-cycle.

- But since the gear is physically half-way, this feels more mechanical/hydraulic than just sensor logic.

---

3. Why the nose wheel being cocked matters

Normally, when retracting, the nose wheel passes through a centering cam or is hydraulically straightened before stowage.

- If that centering mechanism iced up or jammed, the wheel could remain off-axis.

- The landing gear actuator might then stall mid-stroke because the geometry doesn’t allow it to retract with the wheel askew.

- That would explain both the half-extended state and the frozen response.

---

4. Field troubleshooting from the cockpit

Options are limited in-flight, but here’s what I’d suggest step-by-step:

1. Recycle the gear: You’ve tried once already. Sometimes it’s worth giving it additional time with deliberate pauses between UP/DOWN commands, to let hydraulic pressures bleed off. But repeated cycling risks further jamming.

2. Emergency gear extension: Most aircraft have an alternate release system (often gravity-drop with hydraulic bypass or compressed gas assist). That bypasses sequencing valves and lets the gear fall into place. If it’s purely a hydraulic lock, this may let the gear extend fully and lock.

- If you haven’t already: consider attempting emergency extension.

3. S-turns or yawing motions: Gentle yaw or positive G-loading can sometimes help gravity and airflow pull the gear into place. Not aggressive, but enough to “jostle” the jammed mechanism.

4. Thermal factor: At −1 °F, icing and fluid thickening are prime suspects. Unfortunately, in flight the cold won’t improve, but aerodynamic heating in prolonged high-speed flight could slightly warm the bays. That might free up iced components — but it’s not guaranteed.

5. Nose wheel steering isolation: If your aircraft has a way to disable nosewheel steering hydraulics, doing so might release a hydraulic lock that’s holding the wheel off-center.

---

5. Likely root cause (based on symptoms and environment)

The most probable scenario is:

- The nose wheel centering mechanism is frozen or jammed, leaving the wheel cocked.

- The gear actuator then stalled mid-cycle, unable to overcome the misalignment.

- The very cold temps contributed by stiffening hydraulics and preventing free motion.

---

6. What this means for you operationally

Best case: Emergency extension works; gear free-falls into down-lock and you land normally (possibly with nose wheel off-axis, so anticipate directional control issues on rollout).

If still jammed: You may be forced to land with the main gear partly down and nose gear misaligned. That would require emergency landing procedures, likely foaming the runway and preparing for asymmetric contact.

Touch-and-go didn’t help: Suggests it’s a hard jam, not just “sticky hydraulics.”

---

My recommendation:

Attempt emergency extension immediately.

If that fails, fly some time at higher speed to warm the bays, then retry.

Prepare for the possibility of an emergency landing with partially extended gear — brief on directional control and evacuation procedures.


I'll be honest I couldn't bring myself to read the whole thing, but it leads me to hoping we never entrust vibe-coders to work on mission-critical systems...


Therac-25 is also on the front page right now. I like to reread the reports about that every few years, especially the human effects. Maybe we need formally-verified methods to be more accessible.


Therac-25 is the poster child for this kind of failure mode. Formal verification and behavioral equivalences would be invaluable, I think, but I can't pretend I understand much about the underlying math of the former.


This sounds totally plausible to me, a complete novice in this field.

This is why we shouldn't rely on LLMs for this kind of thing.


38°F is 3.3°C, for those of us in the rest of the world.


The key takeaway for me was that it actively resists the oscillations, making it a more effective damper than a shock absorber in a range of situations, but it doesn't replace the shock.

Donut Media actually has a great video on the topic: https://www.youtube.com/watch?v=t58qjcNwEbo

As far as my understanding goes, it's basically a low-pass filter that also provides momentum in the direction of movement - this actively dampens spring oscillation (as opposed to a shock absorber, which passively dampens oscillation). It should be installed in parallel with the spring and shock.


As a person who has worked in and around logging and big data processing for 16 years now, including almost a decade working as a senior in professional services (currently a global security architect) directly for one of the largest big data companies, here is my opinion on logs vs metrics:

A log entry should capture an event in time, for example: a person logging in, a failure, a record of a notable event occurring, etc. These should be written at the time they occur when possible, to minimise chance of loss and to minimise delay for any downstream systems that might consume the logs. Arguments for batching could easily be made for systems generating very high volumes of logs.

Conversely, a metric is a single value, point-in-time capture of the size of something, measured in units or with a dimension. For example: current queue depth, number of records processed per second, data transfer rate in MB/s, cpu consumption percentage, etc. These can/should be written periodically, as mentioned in TFA.


Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: