On the rust side, it doesn't seem like they have gotten to benefit too much from the ecosystem yet (one crate for XML deserialization). But I am sure now that it will come with time.

Comments URL: https://news.ycombinator.com/item?id=39687979

Points: 40

# Comments: 18

An open carry in addition to the dog would probably keep you safe outside a war zone.

For an efficient core context switch the scheduler must accurately predict that the source (current) core won't be free for the duration of the full core context switch time and that the sink core will be free by the time the meta context gets there and will have been free by the time the rest gets there. Otherwise, the scheduler ends up thrashing the cpu (it is actually a bit worse as future task might need same context so you have to be aware of the future). So, for the scheduler to know this it would need to be:

- Global: The only scheduler on the system or basically rafting with all the other schedulers on the system

- Prescient: The scheduler(s) would need to be able to predict all tasks, thier context, and work time per task perfectly. Which could really could only happen when everything is static and hence deterministic.

For example, I think most tasks people are throwing at async are web requests. Most actually take the core an order of magnitude shorter time to compute then the time it takes passing the context from one core to another and they are all unpredictable to the scheduler. In this scenario I could see the scheduler taking up the majority of computational time on the system. So turn on multi-threading + async on a quad core and you will get worse bandwidth and latency(always) for all your pains.

EDIT: Although this single data point would tell me I am wrong (see description):

https://www.youtube.com/watch?v=IG-wGXENTt8

This should be more ergonomic as this should get rid of everything needing to have send/sync traits. I also suspect it may be more performant as I am not sure how good the async runtimes are about keeping scopes pinned to a particular core so its not constantly jumping around and busting the l1 caches (which would be extremely detrimental to compute latency and bandwidth)... Happy to be schooled on any of this.

The best chance of success will come from having more development time. So don't spend your money. You could also find partners, but make sure there is a peaking order (one of the founders has a plurality). So join someones existing project or sweat enough over your own that other founders would be willing to join at a lesser cut.

I would not register a business. Waste of money (dev time). You can wait till there are other founders or you have revenue and want a tax advantage. Assuming you are in the US you default to a sole proprietorship under your name anyhow, so no worries there. If you want a cool sounding name you file for a "Doing Business As" I would not using the big cloud providers. Waste of money. Run it on k8s/VM/Container on your desktop or your PI till you have users or use free tier services.

I would not hire. At 20k the best bang for the buck would be your time.

I would not move. Again, costs. If you want to meet people you already seem to have a knack for it. :)

Also, hunter321 and yuppie_scum are wise men, hahaha, and I don't see any bad advice on this page. Add a contact to your about and I would be happy to chat.

In regards to your general point I am making assumptions and it would be harder. But within an order of magnitude. A great place to use some basic machine learning.

In regards to LEO being harder... I agree the the latency analysis will have more moving pieces. But it being better in terms of resulting anonymity would depend on its implementation...

Okay, here is my understanding.

Lets say I control a few assets like a website, news.com, a DNS server, and relegram, a messaging app, and control the ASs that route to them.

Let's say the target posted something to relegram. I grab to logs and gain the IP. Cool, now I have the IP.

I add the IP to a list that instructs my controlled ASs to collect latency stats during handshake protocols (could do it from the end assets but this should be easier/better).

Meanwhile I also look up who owns the blocks the IP is from, likely finding their ISP.

If it a satellite provider I could go grab a a friendly dish in a known location and add that to list as well for the baseline. I could at this point double check my seconds/meter converter by moving said dish but it likely to track with physical constants.

After getting ten thousand hits or so I take the difference between the mean baseline latency and target latency and translate it to distance with my constant. Now I know the target should be within ~x of the satellite. I also have a map with terrain so the torus becomes a circle with a hole in it.

Now I take a plane and hopefully it can fly high enough between the satellite and the circler path as to 'shadow' a statistically significant portion of the area as it goes around.

- If they where clever they could time the latency and find how far you are on relative to the satellite. Giving a circle path to look at. Meaning plane could find you by flying along the circle. So I guess it could help them track the radio signal...

EDIT 1: https://media.defense.gov/2022/Jan/25/2002927101/-1/-1/0/CSA...

Seems like the NSA recommends a vpn to obscure VSAT use. They don't have much else to say about anonymity.

EDIT 2: Found this thread:

https://old.reddit.com/r/SpaceXLounge/comments/t5y67a/updati...

EDIT 3:

After some thought, I think Starlink will be robust against tracking. They should be harder to locate then VSATs which the author mentions in the Twitter thread. In comparison:

1. They are beaming to a constantly moving swarms of satellites rather then a geostationary satellite: a. So timing attacks can't be used to find a search path. b. The beam is moving to even he a plane pickup on a signal it would quickly lose it as the beam moved. Although there is a workaround I won't mention.

2. They are lower powered so the signal is weaker. I assume they are just as directional.

3. They are smaller and harder to spot.

4. They are much more numerous.

5. They are portable.

https://everydayastronaut.com/sls-vs-starship/

Time will tell though as they are both in late stage development.

Edit: SLS vs Starship is the correct comparison to make. Spacex does not intend to use Falcon 9 or the Falcon Heavy for lunar transport.

It seems that the Russians are having logistical issues. They are running out of gas. Not sure how but it seems like it.

We are hearing today about them sending in more armored divisions. These will re enforce the supply lines. But this is a really risky play. It is a double edge sword. Now that they send more in they need even more gas. And if they run out they suffer a larger loss. What good are 4,000 tanks without fuel? Suddenly your armored division are infantry divisions who are outgunned on foreign soil.

The less risky play would be to withdraw there armor pretty far back. But this means an extend war. Which they should lose do to basically endless international support to the Ukraine and their willingness to fight.

So the play would be to pull back and stick to claiming the small section of the separateness region they have capture so far. This is will happened when the last of the armored units cross the line to cover the retreat. Given Ukraine can last four more days and keep the supply lines broken.

Anyhow, seems like they think it is the concentration of melanin in the fungi. The melanin has been sequenced and it is the same type found in human skin. Maybe we will see this adaptation in space fairing humans... Wonder if current black astronauts are less effected by radiation.

EDIT: Probably something that will seem so obvious in hindsight.

https://scholar.google.com/scholar?hl=en&as_sdt=0%2C10&q=bac...

Probably specifically refers to "Concurrent cycle collection in reference counted systems" where Bacon is first author?

https://www.migadu.com/pricing/

You do lose the layer of encryption protonmail provides. But it is essentially boils down Encryption at Rest and e2e when between two protonmail users. It can be mimicked by pulling down the mail from the servers to your machine and using pgp.