Remember how 1Password used to install itself as a custom keyboard that could "type" your passwords into arbitrary text fields anywhere in the OS, before password management specific hooks were added?
It would be nifty if your phone could just connect to other devices as a BT keyboard and type in passwords there too. Probably not worth the actual fuss of pairing a BT device, but if that part were not so painful it could be quite a nice solution.
One major flaw in this approach is the one-way channel (keyboard input) prevents the password manager from knowing if it is supplying credentials to the correct recipient. Phishing attacks are relatively common and users expect a password manager to know these things, even in situations like you have described where it’s clearly impossible. I think this is why this approach hasn’t succeeded in the marketplace and FIDO2/WebAuthn support seem to be table stakes.
Yeah, certainly a proper security module / passkey-type approach is ideal, it would be hard to justify all the bother of developing a bluetooth typer if really the only use-case for it is legacy devices that are old enough to not have an OS supporting the client app, but new enough to still pair with a device pretending to be a bluetooth keyboard.
I've long wanted a hosted Git service that would help me maintain long lived fork branches. I know there's some necessary manual work that is occasionally required to integrate patches, but the existing tooling that I'm familiar with for this kind of thing is overly focused on Debian packaging (quilt, git-buildpackage) and has horrifyingly poor ergonomics.
I'd love a system that would essentially be a source control of my patches, while also allowing a first class view of the upstream source + patches applied, giving me clear controls to see exactly when in the upstream history the breakages were introduced, so that I'm less locking in precise upstream versions that can accept the patches, and more actively engaging with ranges of upstream commits/tags.
I can't imagine how such a thing would actually be commercially useful, but darned if would be an obvious fit for AI to automatically examine the upstream and patch history and propose migrations.
I was going to say, ideally you’d be able to funnel alternates to the LLM, because it would be vastly better equipped to judge what is a reasonable next word than a purely phonetic model.
If you just give the transcript, and tell the LLM it is a voice transcript with possible errors, then it actually does a great job in most cases. I mostly have problems with mistranscriptions saying something entirely plausible but not at all what I said. Because the STT engine is trying to make a semantically valid transcription it often produces grammatically correct, semantically plausible, and incorrect transcriptions. These really foil the LLM.
Even if you can just mark the text as suspicious I think in an interactive application this would give the LLM enough information to confirm what you were saying when a really critical piece of text is low confidence. The LLM doesn't just know what are the most plausible words and phrases for the user to say, but the LLM can also evaluate if the overall gist is high or low confidence, and if the resulting action is high or low risk.
old ASR systems (even models like Wav2vec) were usually combined with a language model. It wasn't a large language model, those didn't exist at the time, it was usually something based on n-grams.
In the end they're probably run into the same issues that killed WSL1 for Microsoft— the Linux kernel has enormous surface area, and lots of pretty subtle behaviour, particularly around the stuff that is most critical for containers, like cgroups and user namespaces. There isn't an externally usable test suite that could be used to validate Microsoft's implementation of all these interfaces, because... well, why would there be?
Maintaining a working duplicate of the kernel-userspace interface is a monumental and thankless task, and especially hard to justify when the work has already been done many times over to implement the hardware-kernel interface, and there's literally Hyper-V already built into the OS.
I'm in that camp— I was an Intel Mac user for a decade across three different laptops, and switched to WSL about six years ago. Haven't strongly considered returning.
I grew up going to the Omnimax theatre at the Ontario Science Centre; that image of the giant projector going up the angled elevator is a very familiar sight. I loved the little short films they showed there, but it's obvious it was an incredibly bulky and obtuse format that was unlikely to be of much competition against digital alternatives.
Sadly the OSC as a whole is now being demolished after years of under-investment and mismanagement, and the Cinesphere (IMAX) at Ontario Place is likewise in dire straits.
It was briefly renamed Common Markdown as well, and John hated on that as well, so it became CommonMark.
And now we're in an odd position where Github and friends all validate their implementations against the CommonMark suites, but refer to the result as "Markdown" to their users, which makes the work they're doing maintaining that stuff especially thankless.
At the time of the SM/CM/CommonMark kerfuffle a decade ago, Gruber was quite explicit that "X Flavored Markdown" was perfectly fine with him— Atwood even includes the relevant podcast snippet:
Thing is, the keypad isn't used 24/7 (though it was great for multiplayer on same keyboard), and the mentioned variant is portable. This allows flexility. For example, (assuming right handed mouse here) it can be put on the right side of the mouse instead of the left. Or it could be used on an armchair of a sofa. It is perhaps a cheap one, not caring about dirt or wear, but you could buy a mechanical one or a physically more nice one.
If people can use one Azeron Cyborg with one hand (or two with two hands) as a way against carpal tunnel syndrome then 80% and 60% keyboards are likely just a hack to keep backwards compatibility whereas the better long term solution is likely a proper alternative (with e.g. chording).
That said, I'm happy with my 80% (not with the 60% due to it missing arrow keys which I sometimes use, for example with a shell). But vertical mouse with a lot of buttons are rare (Azeron Cyro is an exception), so for now I'm using a Logitech Vertical MX.
Oh I'm sure that's true! I've never had to do enough data entry to learn the muscle memory for it, so for people like me it's just perpetually in the way.
I'm rocking an MX Mechanical Mini and I'm overall quite satisfied with it, though it's frustrating that the single-touch switching between multiple paired receivers doesn't take the MX-series mouse with it; this seems like really obvious functionality to have left on the table. At the same time, it doesn't seem like any of the other premium/gaming peripheral makers have tried to integrate anything like this. It's just 1:1 peripheral to receiver dongle, and "get a KVM" if you have more than one device to control.
Full keyboards with numpad are great but I wish the numpad was on the left side of the keyboard so that it doesn't fall between the alphabetical keys and the mouse (right handed). I always feel my right arm travels unnecessarily long distances to switch between the keyboard and the mouse.
Absolutely this. Everyone fixates on the language but the hard part is really the packaging ecosystem and how-do-I-X type questions where Nix has ten answers that are all better than what Debian or Arch can do, but it's not obvious which is the best between them or how they compare.
See things like Python packaging, how to make ISOs/installers/containers, how to override a scope, how to maintain a dev environment, how to do package testing, how to set up your own CI with caching and binary delivery, etc.
Yea, IME the best manual for nixos/nixpkgs is the repo and the manual for git, grep etc.
I clone or save every public repo or article or whatnot i find that helps me or seems interesting.
These two examples come to mind: the page that made what the config/options system really is [0], and the post that really drive home to me it’s all just configs! A config language all the way down! [1]
Yeah, and that's obviously pretty hostile when the best guide is reading the source.
I think the deeper problem that maybe isn't always considered in the "Nix needs better docs" discourse is that there are many tasks that simply don't have an optimal workflow in Nix (yet). It can be weird documenting how do some particular thing, but having to frontload that doc with a bunch of caveats about which particular set of tradeoffs the suggested approach is embracing.
For example with Python, a huge one is around how much you want to leverage the Python packages already in nixpkgs. If you want to use them, which makes sense if you don't really care about versions or you've got a lot of things with tie-ins to non-Python such as bindings packages, then you probably want the conventional buildPythonPackage workflow, where you manually package any missing deps, perhaps assisted by pip2nix: https://wiki.nixos.org/wiki/Python
But if you have a self-contained app that already has everything locked and you just want minimum friction, then you almost certainly want uv2nix: https://github.com/pyproject-nix
A lot of things in Nix are like this. Same story with containers where you've got dockerTools.buildImage but depending on your workflow nix2container is almost certainly the better choice. Nix's limitations around IFD are finally being addressed by https://tvix.dev/ but that's a rewrite and brings yet another potential split.
Nix is the epitome of being perpetually stuck in the 1000 flowers blooming [1] state of things, and in some ways that's beautiful, but it needs people to build a cathedral or two within the bazaar. Determinate [2] is trying, but they've also taken some heat from the community for concerns around OSS and governance.
That's an excellent way to put it! Also, never read the 'Let 1000 Flowers Bloom' article, thanks.
What I find extremely interesting, is I would give (and have given) exactly same advice to someone asking me about python or docker packaging. Which means that we both ended up with the same long struggles and rabbit holes independently. It would certainly be excellent if those cathedrals in the bazaar were more centrally known and documented, to concentrate efforts, and to help others avoid having to spend so much time doing the same.
The Nix world is not a huge place. I was largely self taught for about a year and then heavily influenced by working with Numtide, so a bunch of my tools experience comes from them.
It would be nifty if your phone could just connect to other devices as a BT keyboard and type in passwords there too. Probably not worth the actual fuss of pairing a BT device, but if that part were not so painful it could be quite a nice solution.
reply