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

I think part of it is that, especially at the kernel level, it can be hard to really categorise bugs into security or not-security (it has happened in the past that an exploit has used a bug that was not thought to be a security problem). There's good reason to want to avoid updates which add new features and such (because such changes can introduce more bugs), but linux has LTS releases which contain only bug fixes (regardless of security impact) for that situation, and in that case you can just stay up to date with very minimal risk of disruption.

At that rate Russia will have conquered Ukraine in about a century. The war is clearly going to be decided by attrition, not the current rate of land capture.

And density is limited. Starlink cannot more than a tiny fraction of a city.

Limited by the amount of satellite coverage? Or on the ground limitations from ever greater division of bandwidth? I guess those two are directly correlated, but they could in theory add microwave relays into the mix to help offset higher population dense areas from lower density ones with less used bandwidth.

I think it's mainly a limitation of the beam steering: terminals that are close together need to be seperated in bandwidth so that they don't intefere with each other, and there's only so much bandwidth available. Tighter beam steering could help but that is something that tends to bump up against physical limitations.

(and it's an area where it would need orders of magnitude improvements to address the density of cities, it's not really close at the moment)


Really interesting insight, thanks!

In the past I've worked on consensus based protocols like the ones used in modern cellular systems; basically edge devices register with a controller system that then coordinates time slots for distribution/use of bandwidth for the limited spectrum. Adds a lot of complexity and requires highly accurate time synchronization mechanisms to have any hope of working, but they certainly could leverage something like that to further increase support at higher densities. That is, if they're not doing that already.


That's another way to divide up the total amount of available bandwidth (common on any shared medium and they are almost certainly already doing this), but it doesn't increase the amount of available bandwidth in a given area.

You mentioned beam contention as the key problem, which consensus networks solve at the cost of latency at the high end. As for bandwidth, in theory, you get the full network speed when it's "your turn", so that looks somewhat "bursty" when cycle lengths are too high from high demand. Naturally it evens out at human perception timescales appearing as lower bandwidth though. And obviously there's a saturation point where it no longer makes sense to continue slicing the pie and more complex mitigation strategies like exp back off, priority queuing, varying cycle lengths, etc need to be added into the mix.

To decrease that latency in high density areas like cities they'd need to reach for something like terrestrial microwave relays to add more connection points from adjacent (in horizon) "freer skies"


Helium is actually pretty hard to keep ahold of, being a very light and small noble gas. It can diffuse through a surprising amount of materials, flow through far smaller cracks than you would expect, and is quite hard to filter out of a mixture of gases.

Also superfluid helium (a big chunk of helium used for refrigeration like in e.g. the LHC) has the weird property of flowing the same speed through a tiny hole as a large one and coating everything with a molecular coating. Superfluid helium is basically a bose einstein condensate but macro-scale, totally counterintuitive. Essentially a thermal superconductor. Zero viscosity.

Unless you need it to be less than 3 kelvin for some reason, helium doesn't do that.

I think it's a problem where the only solutions are worse, on the whole, than the disease.

Probably the best option would be the ability to lock down your own device somehow (i.e. put the toggle in the opposite direction by default). This at least lets others around someone vulnerable to this protect them (and probably much more effectively, as the controls can be a lot tighter than 'we once saw an ID we believed was real')


I wouldn't be surprised if the people at google implementing this genuinely believe this to be the case. It was the same thing with AMP, the people doing it really seemed to believe it was entirely a good thing and there were no negative consequences whatsoever. But it doesn't really matter when the thing also blatantly concentrates power within themselves that can later be used to their own interests.

(Here's another reason it's a bad idea: scammers tend to be very good at navigating the roadblocks you put in to do a thing, often moreso than the people who legitimately want to do the thing, so I wouldn't be surprised if the scammers still have a healthy supply of malicious apps now signed by google. If they can't keep malware off of the play store where they see the malicious code, why do they think they can stop scammers registering as developers to sign their malware?)


Didn't work so well in my experience: it's about as expensive as petrol (on top of the car being more expensive) and it takes longer than a grocery shop for a charge. You really don't get much benefit unless you can charge at home.

Works just fine for me in Prague, Czechia. The running costs of my EV are exactly the same as those of my previous car (a 1-liter econobox). And it’s a 200hp RWD.

This has been a big security/UX issue with github for a while. It extends to the web interface: you can link to a specific commit under an official github repo but the contents of the README on the page will be from a malicious fork, which makes it way easier to make links look legitimate.

Skip is british term for dumpster.

Most science is not automated like this in practice. You only see robotic pipetting and fluid handling when you're looking at something more like production or development or you have a truly ridiculous amount of variations to try that are otherwise extremely uniform.

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

Search: