Yeah, there are a lot of similar bad takes everywhere, not just on this website. This particular one seems to be reasonably common in finance type spaces. I think it presuposes a "correct" outcome to the war and then just tries to take shortcuts to that outcome despite that outcome not being desireable for the parties that get a vote. Its especially frustrating when it ignores the instability of the outcome, which is true in this case. After all both sides have already demonstrated a willingness to fight to try to change the outcome.
I feel like you are deliberately misunderstanding me. I’m not saying that these define a microcontroller vs application processor, but rather that they stem from differing design goals. Presence or absence of features is illustrative not proof. All you need to do is look up what the A in cortex A stands for, or look at the data sheet of the S31 to see it is classified as an MCU by the manufacturer. I do admit that the feature set of this MCU blurs the lines somewhat at 500mhz with cache hierarchy and psram, but the ability to run from on-chip sram with dedicated performance budget keeps this from losing suitability for true realtime tasks.
It’s like a front backpack where the baby is facing the wearer and is supported up to the neck. Something like this https://share.google/cGaL54ZtqoxDq18zv
> If you think about it the war could have ended years ago and all the Ukranian/Russian lives lost could have been avoided if EU leaders were not so arrogant.
How exactly is Europe to blame for Russia continuing its war in Ukraine? Russia has clearly demonstrated a lack of interest in peace on any terms that could be acceptable to Ukraine.
One key frustration is it’s typically not possible to have an arm distribution that boots across most arm boards, because they have incompatible boot loaders. Ie you have a raspberry pi image and a banana pi image and an orange pi image and the rock pi S image that are all different from each other. There have been some attempts at UEFI on arm that would address this, but it’s nowhere near as consistent or compatible as on the x86 platform side.
A single board computer contains an application processor, not a microcontroller. They have very different design goals.
A microcontroller is a type of processor that offers very fast startup, predictable timing and direct access to hardware peripherals. In contrast to application processors that are intended to run an operating system, a microcontroller will not have OoO execution, multiple tiers memory (eg cache and dram). Usually they also lack an mmu and multiple privilege levels of execution (although that seems more common on riscv microcontrollers). All this means microcontrollers aren’t designed to run Linux (even if someone does figure out how to do that) or clock in the gigahertz, but instead provide very predictable low latency execution required for managing real time systems. For example they might need to operate a set of mosfets with microsecond accuracy to efficiently and safely control a motor.
Ah it looks like the editor does, but the run screen does not. My guess would be since it’s emulating dos programs, probably the keyboard should always be visible.
in the context of CPU performance / architechture `IPC` pretty much always means "Instructions per clock". That's a measure of the internal parallelism a given CPU core is achieving. Most of the time code is not able to get very close to the theoretical maximums a core can achieve for very long, so the numbers the OP is quoting are incredibly impressive.
I believe most of the 8bit microcontrollers from this era have no good optimizing compilers that get close to what competent practitioners achieve with assembly. I think it has to do with having complex addressing modes making the C stack fairly inefficient.
You are arguing against a very well known phenomenon. Technical people often avoid getting promoted to management precisely because they love doing the thing themselves. Despite the higher potential for impact in a management position, losing the detailed view of a practitioner is a real loss. This phenomenon is less obvious in big tech because there are so many people who really wanted to be managers the whole time, but had to be engineers first or never really cared about the work, but want a promotion for the better pay.
The missing piece that makes it not a tautology is that two apps side by side have the same aspect ratio as one app full screen (but 90 degrees rotated)
Equivalence on what metrics? In theory what you are asking for makes sense, but I think it is very hard to actually specify what equivalent means in the context of an optimization process that needs to emit code with observably different behavior. Sometimes (although admittedly rarely) speeding up sections of code can even be undesirable for example branchless code for constant time algorithms that avoid timing or energy side channel leaks, or the much more mundane elimination of signed overflow checks or other undefined behavior quirks.
Listening to eskil’s talk from the better software conference, he said in order to stand on the shoulders of giants they must first stand still. I really like that metaphor, because it basically suggests today’s apps that have sprawling unaudited dependency graphs that change all the time is effectively teetering on the shoulders of stumbling giants. The visual seems very apt for the how brittle our current software industry feels.
I think you could make a case for that, especially when landing in water. Quite a few dense urban areas people might need to get to have water nearby suitable for landing seaplanes. I think you would end up creating communities further from the urban areas dedicated to this mode of transport. It’s definitely not a simple or guaranteed idea, but it is actually feasible politically and technically.
This! Anything unproven makes the flight certification process longer. They already have to get their electric side certified, might as well make the backup generator as easily certified as possible.
Regular aircraft are required to have enough fuel to be able to divert to the alternate airfield in their flight plan plus all the margins for taxiing and waiting for a landing clearance. If a plane is low on fuel they can declare an emergency and get priority over other traffic, but that obviously is disruptive and should not happen on well planned flights unless something pretty significant happens after takeoff.
I am struck by the fact that arguments for or against within this thread are only about perceived safety (something hard to know at a distance) and not the substance of the law involved. Does Virginia actually have laws prohibiting unsupervised 5 year olds? If so what is the minimum age at which children are allowed outside unsupervised? Does it also apply to leaving children at home unsupervised? The charge of “contributing to the delinquency of a minor” would suggest the minor’s behavior had to be illegal, which does not appear to have been discussed.
It is quite long, but I thought it was worth it if you can find the time. Short of that I think just reading the Knuth article the quote is from might bring similar insights.
I think the theory was that when each weight will be needed is predictable, so the latency can be hidden by fetching earlier (or more likely building the data in such a way that streaming it linearly brings the right weight at the right time)
what even is the alleged crime? If there was any protected IP they would be able to use the courts to sue. But that isn't happening, which suggests they know they don't have grounds. Am I missing something? Patents seem to be very much still grounds for lawsuits (even relatively baseless patents)
People take much more time off during the summer in the USA than during other times of year. It’s somewhat regional, but it’s been true in all the place I have lived. Probably July is the most common month though because in some regions schools start sometime in August. It’s not uncommon for people to take 1-2w off during that period. More than 2w often requires extra approvals, so is less common.