These robots weren't really "walking" in the sense that humans walk through continuous dynamic balancing, i.e falling forward.
These used quasi-static walking, where the zero moment point (like a moving centre of gravity) is kept within the support polygon of the footprint. This is what gives them their weird swaying gait and extremely conservative movement characteristics. You could never make a bipedal robot run, jump or respond to large and sudden external forces using this method. It's essentially a balance free movement hack.
Ya, they walk like old people. By keeping thier cog over thier feet they are able to stop at any moment without tipping over. That's how old people with diminished motor neuron function walk. Both play it safe because they know they lack the reaction time to prevent a fall once cog is outside their footprint. It is also how one walks when on very slippery surfaces.
Computer science research tends to look like this. Take a seemingly ambitious idea, then spend eons making a version of that idea which doesn't scale and probably doesn't work. But no one is really sure how far this incomplete idea will go. After demonstrating it we realize what the limits and next steps are.
There's no robot that aren't built around hardcoded algorithms.
They use neural networks these days, which is just a different kind of hardcoded algorithm, that require bazillion node-hours on NVIDIA GPUs to compile instead of requiring humans doing diagrams with pens and paper. The resultant binaries are still 100% static and hardcoded.
Some humanoid demos incorporate LLMs. So what. GGUF is always static. They don't change or improve as you interact them. So still 100% hardcoded.
Go back to Win98 UI, I know it will never happen but can you imagine...
At this point I genuinely think people would be blown away at how much of a functional improvement it would be.
There would also be a lot of bewilderment for the younger generations, and people who aren't interested in actually using computers who don't think it looks "sleek" enough or whatever. But in terms of day to day quality of life, those old UIs just got the fuck out the way, and were obvious when you had to interact with it. I have some earned hate for the underlying windows OS, but in terms of UI and desktop, we didn't know what we had until it was taken away.
If hung SSH connections are common it's likely due to CGNAT which use aggressively low TCP timeouts. e.g. I've found all UK mobile carriers set their TCP timeout as low as 5 minutes. The "default" is supposed to be 2 hours, you could literally sleep your computer, zero packets, and an SSH connection would continue to work an hour later, and generally speaking this is still true unless CGNAT is in the way.
If you are interested there are a few ways you can fix this:
Easiest is to use a VPN, because the VPN's exit node becomes the effective NAT they usually have normal TCP timeouts due to being less resource constrained. Another nice benefit of this method is you can move between physical networks and your connection doesn't die... If you use Tailscale then you already have this in a more direct way.
Another is to tune the tcp_keepalive kernel parameters. Lowering the keepalive timeout to be less than the CGNAT timeout will cause keepalive probes to prevent CGNAT from dropping the connection even while your SSH connection is technically idle. For Linux I pop these into /etc/sysctl.d/z.conf, I have no idea for Windows or Mac:
This is really a misuse of these settings, they are supposed to be for checking TCP connections are still alive and clearing them up from the local routing table. Instead the idea is to exploit the probes by sending them more frequently to force idle connections to stay alive in a CGNAT environment (dont worry the probes are tiny and still very infrequent).
_time=240 will send a probe after 4 mins of idle connection instead of the default 2 hours, undercutting the CGNAT timeout. _intvl=60 and _probes=120 mean it will send 120 probes 60 seconds apart (2 hours worth) before considering the connection dead. This will keep it alive for at least 2 hours, but also allows us to have the best of both worlds so that under a nice NAT it keeps the old behaviour, e.g if I temporarily lose my network the SSH connection is still valid after 2 hours, but under CGNAT it will at least not drop the connection after 5 mins so long as I keep my computer on and don't lose the network.
There are also some SSH client keepalive settings but I'm less familiar with them.
Check Mosh. It supports these kind of cuts and it will reconnect seamlessly. It will use far less bandwidth too.
I successfully tried it with a 2.7 KBPS connection.
Depends on whether your sockets survive that, though. Especially on Wi-Fi, many implementations will reset your interface when sleeping, and sockets usually don't survive that.
Even if they do, if the remote side has heartbeats/keepalive enabled (at the TCP or SSH level), your connection might be torn down from the server side.
Yes, by generally I really mean all the defaults are pretty permissive, but I understand some people tune both TCP and SSH on their servers to drop connections faster because they are worried about resource exhaustion.
But if you throw up a default Linux install for your SSH box and have a not-horrible wifi router with a not-horrible internet provider then IME you can sleep your machine and keep an SSH connection alive for quite some time... I appreciate that might be too many "not-horrible" requirements for the real world today though.
Yes, this makes your connection more likely not survive client suspends. (ClientAliveInterval, which makes the server ping the client, will make it fail almost certainly, since the server will be active while the client is sleeping.)
Well, for different reasons, but you have similar issues with IPv6 as well. If your client uses temporary addresses (most likely since they're enabled by default on most OS), OpenSSH will pick one of them over the stable address and when they're rotated the connection breaks.
For some reason, OpenSSH devs refuse to fix this issue, so I have to patch it myself:
--- a/sshconnect.c
+++ b/sshconnect.c
@@ -26,6 +26,7 @@
#include <net/if.h>
#include <netinet/in.h>
#include <arpa/inet.h>
+#include <linux/ipv6.h>
#include <ctype.h>
#include <errno.h>
@@ -370,6 +371,11 @@ ssh_create_socket(struct addrinfo *ai)
if (options.ip_qos_interactive != INT_MAX)
set_sock_tos(sock, options.ip_qos_interactive);
+ if (ai->ai_family == AF_INET6 && options.bind_address == NULL) {
+ int val = IPV6_PREFER_SRC_PUBLIC;
+ setsockopt(sock, IPPROTO_IPV6, IPV6_ADDR_PREFERENCES, &val, sizeof(val));
+ }
+
/* Bind the socket to an alternative local IP address */
if (options.bind_address == NULL && options.bind_interface == NULL)
return sock;
I'm not sure what happens to the socket, maybe it's closed and reopened, but with this patch I have SSH sessions lasting for days with no issues. Without it, even roaming between two access points can break the session.
It would also seem to break address privacy (usually not much of a concern if you authenticate yourself via SSH anyway, but still, it leaks your Ethernet or Wi-Fi interface's MAC address in many older setups).
Not anonymous, but it's pretty unexpected for different servers with potentially different identities for each to learn your MAC address (if you're using the default EUI-64 method for SLAAC).
This is a very common misconception. The issue is not IPv4 or CGNAT, it's stateful middleboxes... of which IPv6 has plenty.
The largest IPv6 deployments in the world are mobile carriers, which are full of stateful firewalls, DPI, and mid-path translation. The difference is that when connections drop it gets blamed on the wireless rather than the network infrastructure.
Also, fun fact: net.ipv4.tcp_keepalive_* applies to IPv6 too. The "ipv4" is just a naming artifact.
Mobile carriers usually have stateful firewalls for IPv6 as well (otherwise you can get a lot of random noise on the air interface, draining both your battery and data plan), so it's an issue just the same.
The constrained resource there is only firewall-side memory, though, as opposed to that plus (IP, port) tuples for CG-NAT.
Or my predecessor/address space neighbor, or that of somebody using my wireless hotspot once, or that of me clicking a random link once and connecting to 671 affiliated advertisers's analytics servers...
I think a default policy of "no inbound connections" does makes sense for most mobile users. It should obviously be configurable.
> It’s who’s looking at your profile; it’s the profiles that you’re looking at. That was the holy grail
Facebook actually implemented this as a user facing feature.
I think it was very early days, but I used it, it was fucking creepy, and everyone hated it. I think Facebook probably removed it because it drove people away. It made you feel like a creep for checking on your friends page.
But that's an unpopular approach these days where many companies are obsessed with minimising the bus factor to the point that their IP is as replaceable as their employees.
That only works in world regions where being a developer isn't seen culturally as yet another office job, and there is actually a job market that allows jumping easily across companies.
> I cannot think of a technology more diametric to 'plug n play' than VR, which is very unfortunate.
Ironically that's exactly what the Quest solved with SLAM, it really is plug and play, otherwise I would not have bought one... and it sucks that Meta now owns it, but it really is still the best "just works" VR.
I also don't think VR has much potential to solve real world problems for enough people, but it doesn't have to because it's pretty good entertainment as a gaming device (albeit still fairly niche).
Not Maybe, I owned a 2009 MBP. Everyone with a macbook from that period that I knew had the same issue, they were absurdly bright, you could not keep it anywhere near a bedroom without putting very thick tape over the light.
It was a poorly thought out design of aesthetics over ergonomics.
nope. actually I remember I had that model first and yes I still don't care. simply the least annoying light compared to other bright color leds in a room. doesn't stand close to liquid glass chaos.
loved battery level indicators on old macbooks too, they kind of brought it back with led on magsafe except this new led is more annoying.
> I started making deliberate grammar and spelling mistakes in professional context.
I've also noticed an increase of this in myself and others, I used to edit a lot more before sending anything, but now it seems more authentic if you just hit send so it's more off the cuff with typos, broken sentences and all.
I'm sure an LLM could easily mimic this but it's not their default.
> the number of bus stops might matter at the margins, we’re not talking about a system where marginal improvements will matter
The central argument of reducing stops is increasing bus speed, not reducing margins, It's in the second paragraph.
[edit]
Top comment is a straw man, attempt to correct course downvoted... I'm not sure how much value HN has left for useful discourse, who the fuck are you people, if you even are people.
You're being downvoted because you misunderstood the post you're replying to. They aren't referring to profit margins, but marginal utility—i.e. incremental improvements to stop spacing (purportedly) would not be enough to fix a fundamentally broken system.
I have the same fears. Last year they have publicly stated they are not interested in acquisition [0]
> Pennarun confirmed the company had been approached by potential acquirers, but told BetaKit that the company intends to grow as a private company and work towards an initial public offering (IPO).
> “Tailscale intends to remain independent and we are on a likely IPO track, although any IPO is several years out,” Pennarun said. “Meanwhile, we have an extremely efficient business model, rapid revenue acceleration, and a long runway that allows us to become profitable when needed, which means we can weather all kinds of economic storms.”
Nothing is set in stone, after all it's VC backed. I have a strong aversion to becoming dependent upon proprietary services, however i have chosen to integrate TS into my infrastructure, because the value and simplicity it provides is worth it. I considered the various copy cat services and pure FOSS clones, but TS are the ones who started this space and are the ones continuously innovating in it, I'm onboard with their ethos and mission and have made use of apenwarrs previous work - In other words, they are the experts, they appear to be pretty dedicated to this space, so I'm putting my trust in them... I hope I'm right!
Just note i doubt Tailscale were first popular vpn manager as i remember many hobby users are Zerotier converts and also much older products like Hamachi.
Tailscale have build great product around wireguard (which is quite young) and they have great marketing and docs. But they are hardly first VPN service - they might not even be the most popular one.
Yes, I ambiguously said "started this space"... and to be honest even in the most generous interpretation that's probably incorrect, maybe ZeroTier started "this space", in that it had NAT busting mesh networking first.
As far as I understand Tailscale brought NAT busting mesh networking to wireguard + identity first access control, and reduced configuration complexity. I think they were the first to think about it from an end to end user perspective, and each feature they add definitely has this spin on it. It makes it feel effortless and transparent (in both the networking use sense and cryptography sense)... So i suppose that's what I mean by started, TS was when it first really clicked for a larger group of people, it felt right.
These used quasi-static walking, where the zero moment point (like a moving centre of gravity) is kept within the support polygon of the footprint. This is what gives them their weird swaying gait and extremely conservative movement characteristics. You could never make a bipedal robot run, jump or respond to large and sudden external forces using this method. It's essentially a balance free movement hack.
reply