It depends what you do with such bikes. My son at 5 y.o. rode green trails in a bike park with a woom bike (not a balance bike), and I have seen other dads bring kids with balance bikes to bike parks.
If that is your objective you are ok to spend a few hundred dollars on a kid bike if that gives you the hope you will be saving a lot more than that from the dentist.
This said, a dad like me whose passion are expensive bikes, is very likely to be willing to spend a few hundreds on a kids bike, especially if you have more than one kid and you plan to pass the bike to the other son when the elder one outgrows it.
I agree, my sons learned cycling on woom bikes. They were the only brand in Europe that offered brake levers for small hands and crank arms with appropriate length.
This is a balance bike meant to attract the dads who are fans of the brand rather than a balance bike meant to be good for kids.
First the handlebar is too large for small hands and comes with no grips, second the top tube is too wide to be comfortable between the legs and the whole frame is just edges.
If you want a good balance bike look for brands like prevelo [0] or woom [1] who have been designing kid bikes for years.
As a Firefox user, I make extensive usage of the location bar and the fact that Firefox allows you to search in history, bookmarks etc. etc.
It's so convenient to me, that I rarely use bookmarks. I keep a large history, and Firefox will efficiently allow me to find web sites I previously visited because it will effectively search in my browsing history when I type one or more words in the location bar, looking not only into the URL but also into the title.
This is something that I always miss when I try a different browsers. Also, while Mozilla Foundation has many issues, Firefox is opensource. I am looking forward into Ladybird but it will take time before it's usable. Until then, Firefox remains my favorite browser.
I think that there are several points in the article.
1. Bun had quality issues. The quality issues were known to the Zig maintainers because Bun was one of the most popular and biggest projects using Zig so they were closely monitoring it.
2. The Zig maintainers considered the quality of the Bun codebase itself not good (but it's also true that typically implementors of programming languages have high expectations for code quality).
3. Bun has been rewritten in Rust using Claude
4. The fact that the test suite for Bun passes now that the code has been rewritten does not guarantee a better quality, because the coverage of such test suite was not enough in the first place to detect the quality issues when the code was manually written in Zig. So how can it be sufficient now to certify the code quality of the Rust rewrite?
I was a point of two local bbses, my setup was Binkley Term as mailer, GoldEd as editor, plus a third tool, the tosser, whose name I cannot remember now. Everything running on OS/2 Warp.
Markdown is widely used but I agree that it's a mess, there are so many dialects..
A similar but better markup is ASCIIDOC; it's formally defined and comes with a Technology Compatiblity Kit (TCK) that can be used to certify the compliance of an implementation with the spec.
Imagine asking to your favorite LLM the following: "get the document attached to the most recent email from Joe and then upload it into my document management system in a new folder within archive 'Important', make sure to name the folder based the topic of the document following the naming convention already in place for folders in the same archive"
This could be possible for the average user after activating the appropriate "email" and "document management" MCP servers in their chat interface - maybe following an activation process similar to that of Alexa skills.
How could a regular user achieve the same via CLI? Where would the CLI process be running?
This reminds me the old days of Windows 95 when I found a software to burn CDs that had a trial version which was limited to 150MB of data or so. If you tried to create a CD bigger than that it would refuse to burn and it would instead open a popup and tell you that the image exceeded the limit of XYZ blocks allowed by the trial version.
So I first decompressed the executable program (Windows executable were often packed at that time [0]), then I opened a binary editor, looked for that specific number in hexadecimal notation in the binary and changed to something much higher. I was than able to burn CDs without limitation.
It used to be like that, computer had limited resources and desktop environments were light. Then at some point RAM became less and less of an issue, and everything started to get bigger and less efficient.
Coyuld anyone summarize why a desktop Windows/MacOs now needs so much more RAM than in the past? is it the UI animations, color themes, shades etc etc or is it the underlying operating system that has more and more features, services etc etc ?
I believe it's the desktop environment that is greedy, because one can easily run a linux server on a raspberry pi with very limited RAM, but is it really the case?
Is the intention of the author to use the number of years bugs stay "hidden" as a metric of the quality of the kernel codebase or of the performance of the maintainers? I am asking because at some point the articles says "We're getting faster".
IMHO a fact that a bug hides for years can also be indication that such bug had low severity/low priority and therefore that the overall quality is very good. Unless the time represents how long it takes to reproduce and resolve a known bug, but in such case I would not say that "bug hides" in the kernel.
How about switching from VS Code to VS Codium? Same experience without the microsoft telemetry. I suppose Copilot won't be included due to licensing constraints.