ipodopt
Joined 7 years ago
Joined 7 years ago
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.
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):
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" <cool name" for under ten bucks and ten minutes of your time.
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...