That's _very_ unlikely. The AI craze cured me from my imposter syndrome. Since I only saw marginal gains (~20% increase in velocity on average, if we don't count the increased in PR reviews and production bugfixes), I participated to a few 'AI is the new stuff' presentation with 'ai professionals' that presented my already existing workflow (still improved it a bit, but not much). However, listening to them, I found out that they just aren't very good devs and work on rather easy subjects.
I took a class at his workshop in Tokyo and highly recommend the experience. So much thought and detail goes into preparing the wood blocks and even into "just" printing them.
> However I concede that it might be advantageous for certain plants
Plants are highly dependent on their climactic settings, upending a climate equilibrium is awful to the average plant. And looking at past climactic change events, "another climate equilibrium" is something that happens on kiloyear scales (ages, in geochronologic units).
> Remember, a hash is a "one way function". It isn't invertible (that would defeat the purpose!). It is a surjective function. Meaning that reversing the function results in a non-unique output.
This is a bit of a nitpick and not even relevant to the topic, but that's not the reason cryptographic hashes are (assumed to be) one-way functions. You could in principle have a function f: X -> Y that's not invertible but for which the set of every x that give a particular y could be tractably computed given y. In that case f would not be a one-way function in the computational sense.
Tracking people is dystopian. But only collection of data allowed us to train the AI. I don't think EU has issues with tracking people unless a private party does it.
Bypassing CPU for NVMe-to-GPU transfer is clever. The bottleneck for running large models locally has always been the memory hierarchy — this essentially treats NVMe as extended VRAM with direct DMA.
I wonder how this compares to Apple's unified memory approach on M-series chips for similar workloads. The M4 Max can fit 70B models entirely in memory without any offloading tricks, though at lower throughput than a 3090.
Would be interesting to see comparative benchmarks: this NVMe approach on a 3090 vs M4 Max native, especially for batch inference where the NVMe latency might be amortized.
The separation of planning and execution resonates strongly. I've been using a similar pattern when building with AI APIs — write the spec/plan in natural language first, then let the model execute against it.
One addition that's worked well for me: keeping a persistent context file that the model reads at the start of each session. Instead of re-explaining the project every time, you maintain a living document of decisions, constraints, and current state. Turns each session into a continuation rather than a cold start.
The biggest productivity gain isn't in the code generation itself — it's in reducing the re-orientation overhead between sessions.
The reading is the done with a high-resolution video camera and the image is processed to extract the data.
This can be easily done many times faster than the writing, which is why the article is focused on the progress that Microsoft has achieved in increasing the writing speed, in comparison with their prototypes from a few years ago.
The most important limitation of this device is the current very high cost of the lasers used for writing. Had they been cheaper, the writing speed could be increased by adding more lasers.
Microsoft argues that if this kind of short-pulse lasers would be mass produced, they could become much cheaper, like it has happened with the many lasers that are used now everywhere in optical fiber communication and with optical discs.
The form factor discussion is fascinating but I think the real unlock is latency. Current cloud inference adds 50-200ms of network overhead before you even start generating tokens. A dedicated ASIC sitting on PCIe could serve first token in microseconds.
For applications like real-time video generation or interactive agents that need sub-100ms response loops, that difference is everything. The cost per inference might be higher than a GPU cluster at scale, but the latency profile opens up use cases that simply aren't possible with current architectures.
Curious whether Taalas has published any latency benchmarks beyond the throughput numbers.
The way modern Nvidia GPUs perform inference is that they have a processor (tensor memory accelerator) that directly performs tensor memory operations which directly concedes that GPGPU as a paradigm is too inefficient for matrix multiplication.
My favourite 'thing' in the modern world is that 'we don't process and store your data' has taken to mean - 'we don't process and store your data - our partner does'.
Which might not even be stated explicitly, it might be that they just move it somewhere and then pass it on again, at which point its outside the legal jurisdiction of your country's ability to enforce data protection measures.
Even if such a scheme is not legal, the fact that your data moves through multiple countries with different data protection measures, enforcing your rights seems basically impossible.
I find people tend to miss the productive aspects of Chinese state led investments because they don't consider their value at scale. Take the HSR system, it has been derided time and again as being wasteful, and too expensive, and so on. Yet, now it's become a key artery for trade and commerce across China. It allows goods to move at an incredible speed, boosts tourism, and helps overall development of many regions which otherwise wouldn't see much economic activity.
Now that code is cheap, I ensured my side project has unit/integration tests (will enforce 100% coverage), Playwright tests, static typing (its in Python), scripts for all tasks. Will learn mutation testing too (yes, its overkill). Now my agent works upto 1 hour in loops and emits concise code I dont have to edit much.
That's kind of a mean and not very relevant response.
The point is that if anyone wanted to reform English spelling, they would have to choose a particular dialect to standardize around.
There is no standard English dialect. There is a relatively standard version of American English ("Walter Cronkite English"), and there is Received Pronunciation in England, but then there are all sorts of other dialects that are dominant elsewhere (Scotland, Ireland, India, etc.).
Which one should we choose to base our orthography on? Or should we allow English spelling to splinter into several completely different systems? Yes, there are already slight differences in British vs. American spelling, but they're extremely minor compared to the differences in pronunciation.
And after this spelling reform, will people still be able to read anything written before the reform, or will that become a specialized ability that most people don't learn?
Light weight has become a marketing term that targets software developers who have gotten sick of bloat and want their software to run fast and take less resources. It used to mean a trade-off between feature rich and speed. It's been so over-used now that i automatically ignore it unless there's demonstrated reason(s) for it being called light weight.
I don't think it's necessarily true, compare the BSD utils to the GNU utils and the style difference is very visible.
On the other hand, I don't think the comparison between jails and docker is fair. What made Docker popular is the reusability of the containers, certainty not the sandboxing which in the early days was very leaky.
