It's not even anything new, it's basically the mobile version of the DGX Spark. The two chips (N1X/GB10) are pretty similar in terms of architecture and specs. I don't get why this seems to be getting so much attention now.
But I like it. It's a copy of Apple's SoC design philosophy, same as AMD's Strix Halo, which I always thought was really cool both for laptops and home PCs. NVidia's traditional consumer cards pull way too much power and are too noisy to comfortably put them in a living or office environment.
I admit, I barely understand what the product does, much less how there's 50k people wanting this. This is a component you can use if you're building a DIY keyboard and want to make it wireless? Seems profoundly niche to me. Am I missing something?
Anyway, congrats on finding and reaching your market! The Internet at its best (although part of me wishes this nerd community had found a more self-hosted way of connecting online than Discord).
> Seems profoundly niche to me. Am I missing something?
As someone who dreams of someday starting a "lifestyle business", I love that it is profoundly niche.
It gives me hope that I can go out and solve a problem that is important to me, but too niche for investors to bother with, and earn some money from it.
Yeah, it sounds like there just legitimately are 50K people who are in this niche. Maybe the fact that people might assume there are fewer is why there was a gap in the market for the author to fill!
I think this is the Big Thing when it comes to making things - underestimating the market. Mechanical keyboards is a multi-billion industry, and building them yourself is a percentage of that.
That said, I wouldn't be surprised if this product managed to end up in the supply chain for a lot of the keyboard manufacturers, which would be a huge boost to sales volumes.
Given the acquisition, that fits with what I'd expect. 50k individual customers probably isn't going to be making a business worth over a million dollars for a product like this (a margin of $200 per sale seems quite high), but if it's an existing company buying it with the idea that they can integrate it into their existing stuff, the math probably works out a lot more.
True! "I am a user of this type of product" is a much less strong signal than "I'm going out of my way to solicit more information about what products are available for this and how to use them". This isn't the often-cited silly case of "I just bought X, and now I'm seeing ads for buying another X even though I don't need one anymore".
Custom keyboards are really popular - especially a few years ago. Most cases/boards are wired only. I think his product enables those to be wireless too
There’s a quite large community of custom mechanical keyboard enthusiasts. If you are familiar with the audiophile space they have similar spending habits.
It doesn't have to be for that, but yeah, that's the target. At the time, a lot of keyboard designs were based around the pro-micro formfactor, so this made it more-or-less a drop in replacement.
There are billions of people in the world. 50k is 0.005% of a billion, so 1 in 20000. This is the reason I think money/market-motivated thinking, that often leaves people pursuing something they're not especially personally enthusiastic about, is wrong for most people. If your goal is to be a billion dollar grow-fast multinational company, okay, but if your goal is to just live a comfortable life and create something neat - then it's much better to sell a niche thing that you enjoy, than a mass market thing you just want to make a buck off of.
For a gaming example of this, it's often cited somehow as a negative that "only" 14% of games released on Steam will earn more than $50k. The way I look at that figure is that there are now about 20,000+ games being released on Steam per year, and so that means that each year some 2,800 games will go on to earn $50k+ - that's more than 7 games a day, every single day. I'm a pretty big gamer, but don't think I could list 2,800 games in total across all systems and my entire life - yet that is how many new games go on to earn $50k+ on Steam every single year.
For most things, there aren't 50k reachable, aware, motivated, solvent buyers. Making enough people aware of your existence may be more expensive than the total profits made from your endeavour.
I am only pointing this out because I know people who would hear the first part of your comment and get their egos attached to an idea since they interpret it as 'there are billions of people, so I only need a tiny percentage, there is no bad idea, only bad execution' and lose years of their lives pursuing something where odds are stacked against them, if there were any odds in the first place. I'd urge people instead to also hear the 2nd part of your comment, and take it as 'experiment with many niche things, there are some that land and land well'.
I wouldn't agree there. One important thing that works in your favor is that there's an inverse relationship between marketing costs and market size, and a big part of that is because of a similar inverse relationship with word of mouth. Even the most fringe topic you could think of is generally going to have communities built up around it, and the more niche - the more 'airtime' ideas that cater to that community are going to get. Like in this case - his 'marketing' was a Reddit post and a Discord, for a total marketing spend of $0.
By contrast when appealing to a large market, marketing becomes a major part of breaking through simply because word of mouth is much more difficult to get going when you're vying for a market that a million other competitors, many quite competent themselves, are also vying for. To go with the games example again, if you're trying to create a platformer - you're probably going to fail, even if you create a pretty good game. It's just a completely oversaturated market, even if that market is massive. By contrast if you're making e.g. a Starflight clone - you're probably going to succeed if it's even remotely decent. It's very niche, but consequently also very underserved market with tremendous word of mouth potential.
I sit here typing on my DIY split keyboard powered by 2 nice!nanos. It's worth noting that a typical wireless split keyboard (separate left and right halves) uses 2 nice!nanos, so really it's only 25k people interested. That's assuming each person only builds one split keyboard, which... All the keyboard fans I know start with one, but don't stop there :p
Then we should take your word over mine. My assumption was that those A/B tests will lead to products that do increase the numbers they were measuring (retention, conversion,...) at the expense of enshittified UX (up to the point of things feeling objectively broken, like notification badges re-appearing for the same items, settings that reset after user changes, search results missing,...). At least that was my explanation for how products by major tech giants like LinkedIn, Facebook, Outlook,... could end up being shipped with such flaws. What would you say?
That's highly misleading to outright misinformation.
> Passkeys don't have to be remembered
Because you need an app for the login flow. You also don't have to remember passwords if you use a password manager app.
> don't need 2FA
Not true, a second factor in the form of eg a biometric ID or PIN is mandatory.
Phishing resistance exists, but only truly so if you completely surrender control over your device and access to your credentials. Something that the same organizations who you'll depend on for Passkeys are actively pushing for through various initiatives.
No it is not. You’re free to save passkeys in your manager of choice and it still won’t let you use a passkey on the wrong website. Users are freed from having to copy&paste TOTPs. No app other than a browser needed.
I agree with the author's general sentiment, but I would give Omarchy credit for some design features that I find either really innovative or well executed.
I find the launch menu the most interesting I've seen out of any desktop environment / OS. It puts easy access to your apps front and center and above esthetics, and yet it still looks great. It's not a sane request, but I'd love to be able to swap the launcher/start menu in another DE for a fully customizable version of that.
Omarchy also has a very smooth way to 'install' web apps. There exist packages that do that for you, but I've tested several and wouldn't recommend any of them. They're bloated (this should really only be a couple lines of bash, like Omarchy's [0]), some use web views (I really want an actual browser under the hood so I can have my extensions), and all that I've tested leave litter on your machine after removing apps or the software. I find web apps as .desktop files so useful that I'm actually using a hacky DIY script now (which I'm considering releasing under GPL if I ever find time to clean it up).
Also, whether you're a beginner or a pro, having a sane starting config for Hyprland is just convenient. Which tells you something about it imho. My conclusion would be similar to the OP's, if you're Omarchy-curious, try Cosmic on your distro of choice. Or at least a cleaned up version with the most egregious personal preferences (like a global keybind for opening Twitter/X) removed, if anybody cares to maintain that.
In some Asian countries electric scooters with swappable battery packs are very common, and they have roadside battery swap stations where (for a subscription fee?) you can take a freshly charged battery and leave your old one. Seems like a great idea.
Just went through Orlando airport and saw something called "power rod" that is basically that for small power banks: you drop your depleted bank and pick up a fully charged one. If I were a US-only traveller, I can see myself using it.
> - Not sure what they're called, but I've seen a lot of fully automated outdoor "locker stations" for packet deliveries
Drop boxes!
I was part of a team prototyping these some 20 years ago. I highly doubt we were the only team doing so, but we were certainly unaware of any commercially available/deployed stations at the time. I was writing the software, in particular the orchestration of the locks and event bus for the transmissions.
Lots of fun from trying to fathom how undocumented solenoids operated, to trips to various countries for remote and environmental testing, and destructive tests simulating someone driving a truck into an installation (i.e., by deliberately driving a truck into one!)
The nerdiest moment was taking a mainboard model that we were getting intermittent faults with and recreating the exact environmental conditions to recreate the problem. This involved incubating the mainboard in a sealed environment chamber to control temperature, humidity, and atmospheric pressure. The fault was bit-flipping because electrons were jumping rails when the microchip(s) were cold and damp.
One could hardly ask for a task better suited for LLMs than producing math in Lean. Running a restaurant is so much fuzzier, from the definition of what it even means to the relation of inputs to outputs and evaluating success.
I think Lerc is saying that LLMs will be pressed into service managing McDonald's restaurants long before they are actually capable of managing said restaurants successfully.
Branching strategies, do 10 things in parallel and evaluate for the best at the end or something along the lines of an evolutionary algorithms. Turn up the temperature on an LLM and have a survival mechanism, and generate solutions to the same problem over and over.
Regarding the first, parallel requests to the same loaded model seem to work pretty well, I'm trying to find time to look more into it myself, but this may be something that might already be within reach for local models.
Sure, it's possible, but you'd start to use it much more and in more advanced ways. Like "thinking hard" would consist of spawning a dozen different inferences from the same cached point and then picking the best one.
Obviously things will get expensive quick, but the main thing for me would be not dealing with the context switch every time I leave the agent to do stuff on it's own.
Feedback loops for prototyping could become even quicker.
In my experience, current agentic workflows are so slow, that for many cases it only makes sense to run them in parallel. So a lot of context switching. If we could have 10-100× faster token generation, we could have task delivery at the speed of human review.
Thanks for building what I'd hoped to find the time to build (and much better than what I would have made)! One question: do you think there is room for parallelization here, eg in the retry loop? Local models generally can handle a limited number (~ 2 digits) of concurrent requests pretty well, even on consumer hardware, which can give >10x boosts in the effective number of token/s. I've been thinking for a while about workflows that could take advantage of this, and 'fix this error' could be one (if not ideal) application. Would be curious what you think.
Interesting - so you're thinking give the model two parallel shots at the tool call and take the winner if there is one, or fallback to retry if not?
That would certainly work in theory, but I'm not as familiar with parallel calls.
- If you mean the model calls the tool twice, identically, in a batch call - that would work fine and Forge handles batch calls, but many small models wouldn't think to do that so you'd have to explicitly prompt it to do so.
- If you mean ask the LLM twice to call the tool and look at both answers, my only concern would be latency from doing 2 calls instead of 1.
- Unless you're truly running 2 instances of the model and aren't memory-bandwidth bound, then yes running parallel workflows would likely help. Especially if you could have them compare notes at certain steps or something.
But I haven't explored this much at all so if you're thinking of something else, let me know!
llama-parallel -m ~/models/Qwen3.5-4B-Q8_0.gguf -ns 4 -p "Fix this Python code, answer with code only: prnt('Hello World)" -pps
llama_perf_context_print: load time = 1181.90 ms
llama_perf_context_print: prompt eval time = 190.57 ms / 374 tokens ( 0.51 ms per token, 1962.49 tokens per second)
llama_perf_context_print: eval time = 3612.25 ms / 159 runs ( 22.72 ms per token, 44.02 tokens per second)
llama_perf_context_print: total time = 4302.84 ms / 533 tokens
llama_perf_context_print: graphs reused = 155
and four answers (3 of which are immediately usable), with -ns 1 I get :
llama_perf_context_print: load time = 1185.61 ms
llama_perf_context_print: prompt eval time = 187.55 ms / 305 tokens ( 0.61 ms per token, 1626.27 tokens per second)
llama_perf_context_print: eval time = 158.92 ms / 7 runs ( 22.70 ms per token, 44.05 tokens per second)
llama_perf_context_print: total time = 468.85 ms / 312 tokens
llama_perf_context_print: graphs reused = 6
Now this is probably not the right way to use it, you should probably also use vLLM instead and it's also not a good model to use for this. But there is a real effect here that others have demonstrated, that the GPU is apparently not always maxed out while handling a single request, so sending concurrent requests can yield substantial parallelization benefits. The idea with this application would be something like this: send off the same query in parallel requests, triggering parallel tool calls, and then filter the results (filter out all failing ones, rank the rest by some simple metric of code complexity). There are probably better applications as well, I'm basically just thinking what kinds of tasks could benefit from parallelization.
After the npm supply chain attacks people suggested automating delays before installing updates, now we're talking about automating update delivery... I'm afraid there won't be any easy or quick fix after decades of treating security as an afterthought.
Linux distros are not npm. It doesn't mean they are infallible to malicious actors, but I believe it is possible to make them infallible for some small set of packages at least.
Attacks are still possible, but if we look at xz backdoor attack[1] it was insanely complicated attack and it still failed. Its fail doesn't look promising, attack could succeed just the attacker was unlucky. Still it shows that the success is not guaranteed.
Theoretically npm can be improved in this way, if there were a separate "distro" for packaged, with dedicated maintainers for packages, who don't write code, just pull it from a mainstream and review it. It is not being done because of tragedy of commons, not because it is impossible.
Linux itself, major Linux distros, npm - none of these were designed with a security-first approach. Even the things that do help with security, like package maintenance or containerization, were more incidental to other primary goals like stability, reproducibility and so on rather than being born from a comprehensive security-first strategy. They could have been, but then things would have moved slower. They even exist, like Alpine, OpenBSD, RedoxOS, but the major ones, the ones we're talking about today, were the ones who moved faster and managed to take over. That's the fundamental issue I'm talking about, the mindset shift that would be required before we could even start the Herculean effort of rebuilding much of the existing stack with different architectures, in different languages and using different development models, always knowing that, in the past, the ones who moved fast and broke things instead tended to be the ones who succeeded.
I technically agree, but it seems too abstract to me. How could look a distro maintenance, if it was built with a security-first approach?
Maybe I have not enough fantasy and/or creativity, but trying to imagine it, I see just a bit more of oversight built into protocols of approving changes to repositories. I mean, it doesn't seem that improved security needs an approach "destroy everything and build it from scratch", some additions on top of existing structures would do. Am I wrong?
If we were to start from security first, we would be asking questions like 'how can we make sure that new code is safe?'. Manual review is great, but we can likely think of some desirable invariants for program behavior that could be tested automatically, or even formally verified. Those would come at the very start. The entire mindset right now is that the existing code is probably unsafe and we'll ship fixes as we discover its vulnerabilities. Not immediately applying updates is seen as a kind of moral failure. All major OS and most software projects were developed with this mindset of crossing your fingers at launch and then changing the tires while driving. So much so that we think of it as the natural state of software. If you start from a base of verified code, the mindset shifts. Not that there are zero vulnerabilities guaranteed in the existing code, but you become a lot more suspicious of new code.
Whenever you read about an incredibly unlucky criminal, there's a chance that the unlucky event is a parallel construction to the classified real reason why they were caught. Not sure how exactly that would have worked in this case.
Yes, it could be. But it is a hypothetical that smells like a conspiracy theory. I wonder why you think it is a good idea to go for these hypotheticals?
Are you arguing that the system may be more resilient than it seems? Like, maybe there is a conspiracy working on security. And they keep themselves secret so attackers would be susceptible to under-appreciate the real level of security and make mistakes that inevitable would caught?
It seems like a over-stretched explanation, doesn't it. Care to explain yourself?
I mentioned it mainly because I find it interesting. We are probably just slightly less lucky than it seems. This particular case doesn't look that much like a parallel construction to me.
>is a hypothetical that smells like a conspiracy theory. I wonder why you think it is a good idea to go for these hypotheticals?
Its always amusing to me when people use "conspiracy theory", a word deliberately popularized and weaponized by said agencies (CIA Memo 1035-960) to mock people for doubting and asking questions about there supposed operations and tactics.
But I like it. It's a copy of Apple's SoC design philosophy, same as AMD's Strix Halo, which I always thought was really cool both for laptops and home PCs. NVidia's traditional consumer cards pull way too much power and are too noisy to comfortably put them in a living or office environment.
reply