Linux/Unix just trust that if you want something persisted with certainty you'll do an fsync, if you do it will absolutely guarantee you're not losing that. It will absolutely make sure that your filesystem doesn't get corrupted by a power loss but if you didn't fsync your write you had no place believing it was persisted.
Doing that IMHO matches real world use much better.
If I do a compile and get a power outage I don't care
if some object files get lost. If I do an INSERT in a DB I do care a lot but the DB knows that and will fsync before
telling me it succeeded. So making sync explicit
gives you both great performance and flexibility.
As for kernel panics, with iOS likely sharing most if not all of it's kernel code with macOS I'd be surprised if Apple hasn't had an iPhone macOS build since before they released the first iPhone.
Yeah I know about 1 e.g. also MicroPython, no idea if that's used outside DIY though.
I agree about rust but I would think that with much stronger type safety and static compilation it should be able to remove a lot more of the overflow checks and most that remain would be needed in correct C too. At least that's what I learned from my compilers prof who worked on Ada compilers for many years and that should be quite similar.
But maybe that's my biased hope as I really really hate working with dynamic languages.
Instead of fusing them, shouldn't it be possible to speculate that it will not overflow, process the check on a separate slow path and do a roll back in case it did overflow?
I wonder how this interacts with branch prediction. Since overflows should happen very rarely I guess the branch on overflow should almost always predict as non taken.
So wouldn't it be possible to have a "branch if add would overflow" instruction or even canonical sequence that a higher end CPU can completely speculate around and just use speculation rollback if it overflows?
I think an important design point here is that the languages that need a lot of dynamic overflow checks are primarily used on beefier CPUs so if you can get around the code size issue, making it performant only on more capable designs is fine since the overflow check will be rare on simpler CPUs.
I would argue that the stable syscall interfaces is one of the main drivers behind Linux success. Containers as we know them would be quite different if they needed to somehow merge the kernel version appropriate .so files into the fs. They would forever remain just sandboxes of the essentially the same distro as the host just like they are on Solaris/FreeBSD.
Maybe I'm missing something but e.g. on the Android clock you can dismiss an upcoming alarm. So now if you wake up, dismiss it and it never rings that kind of proofs you really woke up before, right?
I think the most expensive isn't the address translation itself but TLB housekeeping when mappings get remapped or invalidated. This is especially true with virtualization where the hypervisor often needs to do extra work like (un)pinning guest pages, translating guest real addresses to host real and reissuing TLB flushes.
Afaic the upcoming Porsche Taycan has a two speed transmission. In the Taycan it's used for more efficiency at >160 kph or so something an American car really doesn't need and it costs them a slower 0-100 kph. Tesla uses another trick to get better acceleration to 100 kph. They have two motors and one is geared for high efficiency at US highway cruising speeds (so ca 120 kph).
In general electric motors have a very wide band of excellent efficiency and an even wider band of great efficiency and they are orders of magnitude more efficient than ICE in any part of their operational torgue/speed range.
I deleted my account when they purposefully made their Linux version not launch on any other FS than ext4. I use btrfs and that supports all the features they use, still Dropbox refused to work with it. I complained to their support and then deleted my account. Then again I guess having a private server with NextCloud means I'm pretty privileged.
I hear this claim almost every day yet its been years since I've actually felt my normal work computers being slow. Hell, even booting an OS in an emulator running in a browser proper software still runs blazingly fast. It's just that some people seem to use an awful lot of terrible software but I don't seem to be one of those people
Docker also has support for user namespaces which makes it so that the root inside the container is e.g. nobody outside. In general I'd say docker (with user namespaces) is quite a bit more secure than running as a normal user without containers when it comes to escaping the container/the app being breached. However this is very distinct from the fact that it basically ignores all multi user aspects of Unix when it comes to using the docker command. So while the application inside is more secure, using docker is insecure. Now in the typical deployment scenario the latter doesn't really matter since an admin deploys and the developer only creates the image locally.
SpaceX is landing rocket stages on a drone ship after having them drop from 7400 km/h at 100 km altitude. JPL has a city car sized rover craned from a hovering lander on Mars and DeepMind has a computer win against the acting Go champion. Pretty sure that rules out the "today's engineers are bad" hypotheses.
I'm such a space enthusiast and I'd absolutely love a Biodome 3. That said, I think that people tend to confuse "sustainable colony" and "self-sustaining colony". If it ever comes to it, we will have a sustained presence on Mars for decades before it becomes self-sustaining. That said even with supplies from Earth a Mars base will need a lot of sustainability tech that can be applied on earth too.
But without saying "this is a test for Mars" such a colony will never be built. Even in Antarctica shipping in supplies once a year is just sooo much easier.
I don't see why this realization should be regarded as a counter argument to establishing a Mars colony. It's really really hard and a lot of problems need to be solved.
The most important thing for me is that most if not all of these problems are extremely relevant on earth and for dealing with climate change and overpopulation. Now one could say that we should then solve them for Earth first, but that's not how things work. We only have solar panels today because there wasn't any better way to power satellites. Earth makes things so easy that we won't go for >99% water reclamation, 0 waste green houses and so on.
I really don't use Windows all that often but when I do I now really prefer to use WSL and a proper OpenSSH or mosh. Even running in the default Terminal it's still nicer than PuTTY, if I have the choice though (and when the next version fixes input of AltGr (does not apply to US keyboards)) I prefer to use the Windows version of alacritty.
But Ibuprofen isn't necessary for most of its users survival and is still much cheaper. More importantly, with both a social safety net and public health care close to no one in Germany will die because they could not afford medical care. So you're comparing a $10 drug that most people take against head ache, cramps or light pain with a drug that, where its unavailability will kill many diabetes patients within weeks or months.
They're definitely not the only ones, saw a presentation on a University team working on this just yesterday. After all, vision is the only system for which we know that it can be used to drive a vehicle as that's what we have been using all along. Also Tesla's do also have radar to detect the most important obstacles in front.
Why shouldn't a camera based system be able to do that. Dirt for example won't easily match up in a stereo vision system and even then dirt on a lense has a pretty specific look
And then there are those of us that really can't work on a Windows machine because it just doesn't mesh with how we work. With Windows Subsystem for Linux I can finally at least get some work done on Windows but honestly it still feels like swimming with my arms tied behind my back.
Windows has abysmal performance in its equivalent of the VFS layer i.e. path handling, directory listings and so on.
Funnily enough the main reason is probably that compiling the Linux kernel is one of the most filesystem taxing workloads and also one of those kernel developers care most about.