Are they? I did an interview with one of them a few months ago, passed hiring committee, and have been told everything is frozen. The other one just cancelled my interview.
That is pretty lame unless it is for a very specialized role. But for whatever reason it seems like many companies go through the whole song and dance even if they have no intention of hiring.
It looks good to investors to see a lot of openings, so some companies that are not growing (that is they are in a great market that is small and won't grow) will go through that act of looking for people without hiring anyone. That is they get the job description of existing people, and post ads for that job, collect resumes, (they might do an initial phone screen interview for practice) but never hire anyone.
Careful. Exact same situation, company reached out to me, I went through interviewing and they told me after the third that they have no open spots currently.
> it helps that you don't fall into the trap of "one IDE for all programming languages"
I don't see this as a trap at all. I use IntelliJ for practically everything, and switching languages frequently (currently between Typescript and Scala several times a day) has not been difficult. I get way more benefit from developing increased familiarity with my environment.
RISC OS Programmer's Reference Manual. It's very well laid out, clearly written and consistent. In fact, I even bought myself a copy all these years later to peruse for nostalgia.
Interesting. Is there no distance limit? I don't know how 5G works, but in 2G there was a limit of about 30km, since that's as much as the timing advance would allow for (sending the signal early so that it arrives in its timeslot despite the speed-of-light delay).
I'm also pretty out of date, but I believe in LTE (4G) the max distance was closer to 100km, with the timing advance controlled in the radio protocol. As I understand it, the 5G radio protocol should be fairly similar to 4G, it wasn't completely reinvented for once.
Based on my read of the summary of a couple Mbps per cell and focusing more on low bandwidth services like texting makes me suspect they're right at the limits of what the tech will allow. Since they're advertising compatibility with existing hardware, makes me suspect there is an extension somewhere in the standards that allows the timing window to be increased, or maybe there's some clever hackery going on, like only scheduling every other timing window and cutting bandwidth in half.
Which might work on the uplink, but on the downlink I think it's more complicated to support something like paging, where the UE is mostly idle, and only wakes up occasionally, that things don't get out of sync with the moving satellite.
There's a system using LTE to backhaul Internet traffic from planes (WiFi in cabin, with a LTE to the ground), working with larger cells of up to ~900 km from memory, but it doesn't use standard LTE for example. It uses a modified variant made to support the possibly larger propagation delay coming with larger cells.
For 5G (NR), the max cell size has been increased and depends on the OFDM subcarrier spacing. For a 15 kHz SC, same as LTE, the max cell size is 300 km. This value is halved each time the SC doubles.
There's work on-going to extend NR to non-terrestrial networks. I don't know where it stands right now, but it'll likely add larger cells support. But it's not there yet for sure.
I'd think that the distance limit for _terrestrial_ mobile networks comes from the guard interval of the OFDM modulation [1]. I.e. on longer distances the time-offset between different different reception paths (due to reflections) of the signal becomes so long that you cannot compensate those with just a complex gain-factor of the OFDM vectors.
AFAIR LTE (4G) even uses different guard intervals depending on rural vs. city setting because that time-offset is larger in rural areas (less base station density).
I would not expect those problems to be relevant for satellite communication as ground<->satellite does not suffer much of the multi-path signal propagation of terrestrial systems. (IIRC DVB-c sat-TV broadcasts did not even use OFDM, at least not for the older "v1" DVB-c standard).
Nitpick: You probably mean DVB-S (and S2, S2X..) rather than DVB-C, and you're correct that they don't employ OFDM (they're just a straightforward single wideband channel mostly employing variations on phase-shift keying), and aren't particularly concerned with multipath interference.
In 2G GSM there was this limit, because GSM used very strictly managed timeslots for each call. If a phone was too far away, its signal would arrive out of bounds of the timeslot and this was the reason. The protocol didn't have any compensation built in.
However 3G and onwards were based on CDMA tech (which was the competing 2G tech to GSM), which is very different. CDMA doesn't have strictly managed cells, but rather the basestation picks the signals out of a cacaphony (very simplified). So the same issue doesn't apply.
2G was much more static than CDMA, it had a strict capacity of a number of calls per cell. But the range (up to this 30km) was pretty good because when a phone transmitted the air was clear. CDMA cells used to 'breathe': Have much lower reach during busy times (because weak signals could no longer be identified) so gaps could drop in the network. ON the other hand, 2G got busy with a fixed capacity.
2G did have prioritisation though when the network was full. If you called 112 (the international emergency number) it would kick someone else off to make space for you.
I think the actual answer is that it only works in languages where you can eagerly execute async code disconnected from the Promise/Future construct. It would've worked in ES3 using a Promise polyfill. (Which is notable because it does not fit the aforementioned criteria—it had no real async support.)
It isn’t. The first implementation of promises I worked on was in Java. We used it as part of verifying certificate chains. If you use threads it doesn’t matter if the operations are blocking, as long as you move them off-thread.
