hogehoge51

riscv has mtime. it is somewhat implementation defined, but it should be a single hardware timer shared by all harts. The Zicntr extension defines user space rdtime psuedo instruction to acesss it from userspace.

aarch64 has cntvct_el0 status register that can be read from userspace.

Hierarchical state machines are common in hardware development. I've also used them for embedded systems, and dug my way out of spaghetti nightmares in distributed systems by reworking a system into a set of state machines.

Is it clean? Not always, it gets messy. On the other hand it is deterministic and traceable to specifications. Specifications as state machines can be easier understood and shared than raw code or raw prose.

I also think more effort is needed to synthesize a clean set of state machines with hierarchy for a system at scale and I'm sure there are times when that effort is not warranted.

Japan also tends to leave many contextual and obvious things unstated, and relies on group concensus and information exchange between in group peers over top down authority, so may consider the ultimate group concensus, language, not needing to be codified.

Although i do wonder what my son's 国語 text books teach if Japanese is not the official 国語.

Unfortunately, tbis may be the simplest and most cost effective way to clear the backlog. It's unfortunately for people who in good faith made honest mistakes or were victims of honest mistakes. But it also may be a low cost way to filter out bad faith applicants who were never planning to pay pensions/taxes fully. An assymeytry of information means we never see the balance of honest mistake vs dodgy excuse makers.... Alos, Japan tends to play the grey zone of rule interpretation as a buffer zone for signalling hard feedback. it is generally periodic and ends after a while.

With agentic coding the real bottleneck shifts from typing to clearly expressing intent. High-quality, versioned documentation becomes the key fulcrum: externalize your ideas completely so the agent can generate code without endless human reruns.

The point I was trying to make was I'm not sure it was ever about making something happen completely, but being prepared on all fronts for whatever the outcome is.

Kaizen and JIT are not good for revolutionary change. So I expect by bootstrapping different options early enough they can act on real market pressure once the condition to accurately assess the evidence is available.

For hydrogen getting to that point was a multi decade lead time.

I suspect most western commentary on this topic comes from people not understanding both how numerical/empirical based Toyota are, how self aware of their potential weaknesses they are, plus the ability of a Japanese business to hold to a multi decade hedging initiative.

WTF , you are commenting about FCEV - these things dont have engines!

The strategy clearly stated by Akio Toyoda is multiple power train technology. You can listen to his interviews on the subject, some are in Japanese, but as you have stated a clear and unambiguous interpretation of Toyota's policy I will assume you have that fluency.

(Automotive OEMs are assemblers, the parts come from the supply chain starting with Tier 1 suppliers. In that sense TMC does not do "making engines", but possibly the nuance and consequences here of whether not it "wraps it's head" to "makes things", vs if it has the capability to specify, manufacture distribute something at scale with a globally localized supply chain AND adjust to consumer demand/resource availability changes 5 years after the design start - in this context i ask you, can you "wrap your head" around the latest models that are coming out in every power train technology fcev, (p)hev to bev)

it's not base-level. it shifts the margin, at low skill base-level and your marginal level may be similar. but if you have enough experience and know the complete SLDC , having done each role during your career it, the margin is a massive wedge. if you know a niche, you now know all the adjacent niches and technolgies IF you are open minded to want to know them. that has powerful leverage.

Would you prefer dc-shell scripting?

(I still remember the excitement of EDA tools _starting_ to support TCL and replacing the custom scripting engines they used to have)

My ignorant question: They did bias and variance noise, how about quantisation noise? I feel like sometimes agents are "flipfloping" between metastable divergent interpretations of the problem or solution.

My thought too. To extend this coding agents will make code cheap, specifications cheaper, but may also invert the relative opportunity cost of not writing a good spec.

Interesting. I read the article and situation completely differently.

I suspect the author has failed to explain enough to get readers outside of their preconceptions based on their experience.

In particular I think management and leadership have been conflated in most interpretations - his inaction is a form of leadership to promote personal growth for line manager and IC. The absence of management is the application of this leadership.

(But who really knows...)

you need flexible organziational glue logic at this scale, and the so called wolve can help, so this office of wolves can be the ones patch wires and to reprogram the organzational FPGA's or rewrite the organizational routing table (or what ever it is distributed software people use as glue logic...)

> This become apparently quickly to anyone thats worked in a rapidly scaling company, switched from megacorp to startup, or vice versa.

exactly! my frame of reference...

you need to think in a different plane of isolation. i would say the pure machiavellian manager is a lone wolf in that the relationships hold no weight as interpersonal relationships, only as functional relationships - no different to how you would manage and integrate code.

my point was the efficiency from bypassing/cutting corners is different to the efficiency from understanding and synthesizing problems and solutions differently.

the "obviousness" in the first is seen by everyone, the "obviousness" in the second is seen only by people able to break out of a collective mindset and unground their thought processes.

in the first the "wolf" is missing some obvious things, in particular the negative externality of their action. in the second the "wolf" is generally working on maximising the positive externality by generalizing problem space and solution space outside of the conventional fitting.

You are confusing concepts.

What the original article described is an engineer who could not stand by and let a painful problem with an obvious solution not be solved. the key point of the so called wolf is the obviousness of the solution. it was. ot obvious to anyone else, and to anyone else it would have been a major investment. the 10x does not come from frantic coding, it comes from a comprehensive and unique understanding that translates to code quickly due to motivation and understanding.

Process does not make an org more efficient. it makes it more consistent. if the baseline efficiency is low, the consistency of an improved set of work practices will ofcourse improve efficiency.

What a process often does is overfitting. Overfitting to the most common buiness need, sometimes overfitting to the noisiest patholgies seen.

The problem with process overfitting is that it excludes efficient solutions for problems that don't fit the previous set of business needs, or are not at risk of the previous set of pathologies. sometimes the process has a good pressure valve for this, pull the andon cord. do some kaizen, fire up the CMM level 5 KPAs. but sometimes just applying bespoke judgment is better.

I have been the wolf he describes. I also have been the manager he describes who lets the wolf have space and stand up for themselves. i have also been the manager who creates process and worflows and alignment and blah blah to dampen the noise of individual agency.

tech debt is an orthogonal concern.

Whether or not the natural world has such wolves, its a well formed fictional archetype.

You assume "lone wolf" types are "one trick ponies" who can't learn. You also assume the only interesting problem space for these people is technical/code.

The lone wolf has a big limitations in transitioning to scale: 1. managers do what the article suggested, and stay out their way. The lone wolf never gets the experience of being managed, so it is difficult to transition to manage others. 2. they don't get why others don't "get it". e,g the solution is clear , the code can be done in a day, the comprehensive system model in their head should be shared by everyone.... it takes time to understand that the average engineer works slow and steady on a small scale understanding.

I will suggest there is a lone wolf type manager too. This is not a productivity skill, but an adaptivity and mobility skill.

lone wolf. maybe he missed the significance of lone in that phase when he heard it first and thought it could be dropped. That is my working assumption, it happens.

Whether or not the natural world has such wolves, its a fictional archetype.

It is a particularly common theme in Japanese fiction, where the deviation from the social hierarchy requires a stong force of individual will. Interesting it is also common in Japanese technology breakthrough documentaries.

Ogami Itto - Lone wolf and cub is the first thing that comes to mind when the author says wolf.

The point is the wolf does not need managment. He has built up a model in his head of the problem and solution space better that a team of 1x specialists. T expose it to "managment" , "oversight" and "accountability" is to destroy it, especially for the article that shows an innnovative solution to an organizational pain point. They may be poorly managed, but they may be well managed, either way the managment style likey does not match the particular problem and/or solution the wolf is adressing. One of the key premises of The Innnovators Dillema is that well managed companies are well managed in sweet spots of operation and struggle outside of that sweet spot.

Now, the wolf may benefit from hands off managment, but they will need leadership support. The author seems to have proposed a style of leadership centered around hands off managment and letting the wolf sink or swim. I would hope thismstyle of leadershio includes him holding a life support by the sidelines. (leadership != management)

Whats the practical benefit of fine tune training on a local repo, vs putting the summary of local infomation in the context? i.e every team has their own style and preference for coding patterns that could be generalized - but i imagine a large scale model has seen fhem all so they could be described in the context, or are there specific domain level patterns that can be generalized that would never be seen outside an org so are difficult for a model to infer without fresh tunning?

They are still capable of being described with math, we are just not capable of doing the math, or probably better put is there is a diminishing return of doing the formalisation of those systems as our cognitive abilities are limited and couldn't reason about those models. It leaves them using very approximate models based on human language descriptions that can be reasoned about.

Which means, the language of some fields can’t be math.

However, I don’t think the original presenter was asserting those fields aren’t science, that’s an unreasonable interpretation. More so , ideally they would be use math as it is a language that would help prevent the silly argument “so, Y is not X?, or is Y only X provided Y is in the subset of X that excludes Z? “

(Even in Engineering, we hit this cognitive limit, and all sorts of silliness emerges about why things are or are not formalised)

Taito was founded by a Ukrainian guy called Michael https://en.wikipedia.org/wiki/Taito

Level 2 is simpler and more mature, so it should be easier to specify, package and integrate.

It can follow the traditional OEM outsourcing route, where OEM has high-level models and gets suppliers to implement the details. e.g. I can find public information that Subaru use Veoneer cameras, Xilinx chipsets, but defines their own algorithms. I would speculate they have an outsourced company convert algorithms to FPGA netlists/embedded code. (On the other hand, I know other OEMs have a more complex mesh of joint ventures)

Most traditional OEMs in the automotive industry are integrators. They write a specification, and a Tier 1 supplier provides a black box matching that spec. (Tier 1 in turn provides a spec to its suppliers and integrates their parts)

This has several consequences - Tier 1 suppliers are waiting on input/approval from OEM before proceeding with projects - Tier 1 suppliers don't necessarily have the capital to do work "at risk", even if they could build the part without approval/specifications. (TBH - some do) - Each layer of the supply chain lacks context on the whole project and product line and cannot achieve efficiencies outside of the scope of its contract.

These haven't really been a problem for mechanical parts and E/E parts that have well-defined functions and interfaces and have a lot of re-use from previous generations. It works really well with Kaizen (incremental innovation).

To outsource it, a traditional OEM would need to completely specify the behaviour of said self-driving system, baseline the specification, put out the requests for quotation, etc. Tier 1 then needs to analyse the spec, estimate it, break it down in to sub work packages, work with its suppliers, etc. From an optimisation point of view, this is really inefficient partitioning of the problem space. For greenfields development, an emergent specification via experimentation may be better - but that won't fit in traditional V-model sub-contract OEMs/Tier 1s use.

That flow doesn't need to be followed; the suppliers could raise/allocate capital and build the self-driving stack "at risk" - and this seems to be done (Tier IV, Waymo, etc). But as it's new technology, I assume Rivian think they can do better by themselves and can get the capital for the development as part of an integrated solution while they are smaller it might seem they should not waste limited capitial that way - but integration will save a lot of inefficiency in sharing specifications across boundaries, full system integration and deriving emergent specification via experimentation rather than some MBSE folly.

It can be hidden away in SoC IP blocks, like DisplayPort blocks, too.

I have personally ported a usb c usbpd stack from 8051 to cortex m0 to rv32ec. I can’t talk for gate count, it for code size the biggest factor was the compiler, with ARMCC giving the smallest code. As the rom was larger than the core, that was a bigger factor in gate count.

Now I think of it, WSL can generally call out to Windows tools - you would need to run in a Windows file system mounted into WSL. It just won't port to a Linux-based CI job without Wine. The ideal is a build and test run that is reproducible in CI and locally.

Can I build my embedded firmware with nix using a Windows only toolchain?

(Fyi I just used something like the solution from the article, with the hash embedded in the binary image to be burned to ROM masks. The gaps in toolchain versioning and not building with dirty checkouts can be managed with self discipline /internal checks)

AFAIK ClearMake intercepted file system access and recorded the version of everything touched during your build.