Bear in mind that this doesn't apply to charter airlines, only public passenger ones.
Given there are about 200 countries in the world, you'd need 5 large airlines per country, which is a lot! Most of them don't have any and rely on other countries. Still more have a single national carrier.
> I use Linux daily and don't want to switch to Windows just to connect to the printer's FTP service
I wonder if the author tried using their file manager to connect? I haven't needed any kind of external file management system since switching to Linux, Dolphin just handles everything (sftp, ftp, samba, etc) for me natively in the same window.
My favorite way to connect to FTP servers on Linux was with lftp from the command line. I say was because I don’t really use FTP anymore. I do use Linux still though.
lftp is available in every package manager I know.
When you have a highly competitive market with plenty of actors lower cost does trickle down. Otherwise you’re talking about an extremely complicated cartel which cannot exist.
That's very different to sites like tomshardware that pops up a "hey why don't you check out this extra slop you didn't ask for" when you try to navigate away
Yeah most of these "issues" are surely caused by programmers trying to be too smart. The dumbest possible solution which messes around with the input at little as possible is almost always the best solution. Which implies the browser-provided elements are the best because they have probably been designed and validated more than you can do.
If I use an app and it fucks around with the cursor: instant hatred. It's just so annoying. And if you can't get basic human interaction done well in 2026, what else is messed up in your app?
If I can choose the US specifically, then sometime in the 1950s. I think Baby Boomers in the US will go down as the single luckiest generation on earth in terms of socioeconomic opportunity.
Yeah, I don't disagree, but if we're talking about how our species (which I took "civilization" to mean) as a whole has fared, I think you shouldn't get to pick the where, just the when. If we care about all humans everywhere, and whether fewer of them are starving or dying of preventable diseases or whatever, then I think you have to consider being born as just a random human, not just a random American.
I would argue that "abundance and growing the pie for everyone" is even more unfathomable given how things are structured currently. The wealth gap will continue to widen until something gives.
Why do you think that the fact that the alternative is unthinkable is a reason it won't happen?
Are you also sure that it is unthinkable to those running these companies? I wouldn't be surprised if these models end up being used for internal security-- that people would try to keep an extremely unequal society stable by surveillance and massive analysis capabilities. I think it's apparent that some use of this sort already occurs and that these companies are already participating.
Well then given that one side is "the situation remains neutral or very slightly improves" and the other side is "unthinkable atrocities", I think it's only rational to focus on the "unthinkable atrocities" part. Ideally, we should be focusing all our energy into making sure that doesn't happen.
> This makes it possible to write simple code that’s both concurrent and safe.
Yeah, great, my hello world program is deterministic.
What happens when you introduce I/O? Is every network call deterministic? Can you depend on reading a file taking the same amount of time and being woken up by the scheduler in the same order every time?
This is about durable execution -- being able to resume execution "from the middle", which is often done by executing from the beginning but skipping external calls. Second time around, the I/O is exactly replayed from stored values, and the "deterministic" part only refers to the async scheduler which behaves the same as long as the results are the same.
Coincidentally I have been experimenting with something very similar in JavaScript in the past and there the scheduler also has the same property.
No, but determinism reduces the number of stones you need to turn over when debugging hairy problems such as your program occasionally returning different results for the same inputs. You may not have control over the timing of I/O operations or order of external events (including OS scheduler), but at least you know that your side of the innovation/response is, in isoaltion, behaving predictably.
I go the opposite approach for this sort of thing, since I would much rather flip and remove the stones: I explicitly randomize order of containers during development and testing, and always in my unit tests, so depending on order can't be a problem. No luck required!
You want both. More specifically, you want to be in control of which one you're actually doing.
Randomization is great at avoiding erroneous dependencies on spurious cause-and-effect chains. Determinism is needed to ensure the cause-and-effect chains that are core to the problem actually work.
If it's not required, then you must plan for it NOT being deterministic, with any accidental determinism being ignored (to be safe, forcefully so with an intentional randomization/delays within the library). If it is required, then my random input should always (from the tests perspective) come out the same as I put it in.
If possible, force the corner case if the corner case is a concern. That's the purpose of testing. If there's a concern with timing, force bad timing with random delays. The alternative is relying on luck. I try to make my code as unlucky as possible, during development/testing.
That's the cool thing about this behavior--it doesn't matter how complex your program is, your async functions start in the same order they're called (though after that, they may interleave and finish in any order).
Only for tasks that are created in synchronous code. If you start two tasks that each make a web request and then start a new task with the result of that request you will immediately lose ordering.
reply