335 karma · joined September 18, 2021
Can mathematics borrow from coordinated vulnerability disclosure? I’d propose a registry that records work as it develops, with timestamps that others can verify, together with circles that gradually widen before public release. This would give people a record of their contribution without having to rush an unfinished proof out. But it only helps if we also give credit to ideas and partial results.
This link (edit: I link to https://github.com/NixOS/nixpkgs/pull/522245#issuecomment-45... but probably the anchor is stripped automatically?) is the clearest that I can find to point out what's the problem in a neutral tone with links to issues you can track yourself.
There is other less civic discussions around the issue that I decide not to cite.
One comment describe the situation aptly: 3.4.1 contains security bugs, later versions fixes it but contains regressions. So choose wisely.
*Apparently* both are AI related: the security bugs are probably discovered by AI. Rushing to fix lots of these results in the use of AI, which leads to regressions.
I experienced both kind of sessions, one kind is like very complicated thing and it finish thousands of lines on its own for quite a while (long horizon problem), another kind is like a seemingly simple task that the agent done in a minute but then I need a few back and forth to get it right easily taking me 30 minutes of my time.
The former kind of experience can make us misjudge how much time we think a task would take us (with agents) to do. And then when the second kind happens, it would be quite disrupting as now we felt like it is delaying our progress.
So tracking the time taken when the second kind happens can help us calibrating what we can expect. I mean if we’re lucky it might take us no time but then we can’t expect being lucky all the time.
The reason I an ask is, it would felt like a 5 minutes task, but I track my time and found out often time I thought I’d just quickly check the progress made by the agents and it would easily becomes a 10, 15, or even a 30 minutes task.
To be a bit picky, there’s no unprocessed photo. They start with a minimally processed photo and take it from there.
The reason I clicked is that when I saw the title, I’m tempted to think they might be referring to analog photo (ie film). In that case I think there’s a well defined concept of “unprocessed” as it is a physical object.
For digital photo, you require at least a rescaling to turn it to grayscale as the author did. But even that, the values your monitor shows already is not linear. And I’m not sure pedagogically it should be started with that, as the authors mention later about the Bayer pattern. Shouldn’t “unprocessed” come with the color information? Because if you start from gray scale, the color information seems to be added from the processing itself (ie you’re not gradually adding only processing to your “unprocessed” photo).
To be fair, representing “unprocessed” Bayer pattern is much harder as the color filter does not nicely maps to RGB. If I were to do it I might just map the sensor RGB to just RGB (with default color space sRGB) and make a footnote there.
For me personally, I built my “data centre” as cheap as possible, but there’s a few requirements that the computers you’re using would not cut it: storage server must be using ZFS with ECC. I started this around a decade ago and I only spent ~$300 at the time (reusing old PSU and case I think).
There are many requirements of a data centre that can be relaxed in a home lab settings, up time, performance, etc. but I would never trade data integrity for tiny bit of savings. Sadly this is a criteria that many, including some of those building very sophisticated home cluster, didn’t set as a priority.
Nix is for reproducibility. Nix and docker are orthogonal. You can create reproducible docker image via nix. You can run nix inside docker on systems that doesn’t allow you to create the nix store.
But if we relax it to be a slowly varying constant, then it is not dead. That constant has been changed (by consensus) for a few times already.
Your mistake is to (1) take that constant literally (ie using the strong law) and (2) uses the boundary points to find the “average” effect. The latter is a really flawed argument as it cannot prove it hasn’t been dead (a recent effect) because you haven’t considered it’s change over time.
This article is the shallowest I have read from quanta magazine. I expected more, give there articles in mathematics.
He also frames it as a different goal too: normally when we (as a physicist) talks about the random variables to combine, we think of it as different measurements of the same thing. But he didn’t even assume that: he’s saying if you want to have a weighted sum of random variables, not necessarily expected to be a measurement of the same thing (eg share same mean), this is still the optimal solution if all care is minimal variance. His example is stock, where if all you care is your “index” being less volatile, inverse variance weighting is also optimal.
As I’m not a finance person, this is new to me (the math is exactly the same, just different conceptually in what you think the X_i s are).
I wish he mention inverse variance weighting just to draw the connection though. Many comments here would be unnecessary if he did.
I've been designing my own one-handed keyboard for 3 years. My main problem is that both of my wrist suffers from RSI and either wrist can ocassionally acts up with different levels of pain. (I also have shoulder problem.) They can become practically disabled temporarily for a few weeks, or just quite painful for me to avoid using it. So my desiderata are a bit different from permanently one-handed people.
Interestingly my right wrist is acting up in the last couple weeks so I've been going through a iterative redesign phase recently. I probably will write up a blog post in the future when I have the final design, I'm going through it briefly below:
Desiderata: (first three are directly from the temporarily and random disabled hand criteria)
- primary used for two hands - each hand should be able to single-handedly control the computer - skill transfer from two hand to one hand: since one hand use is oacassional, retraining time should be minimal - based on the research in http://www.tandfonline.com/doi/abs/10.1207/s15327051hci1101_... which eventually becomes a producten https://matias.ca/halfkeyboard/ , the concept of a mirror key becomes a requirement: with the hold of a mirror key, the key at the mirror image position is active. An implementation detail is that the mirror key is a dual function key: on tap it is space, on hold it is mirror. I've implemented other possibility but find that the design in this research is better than others I come up with. - symmetric keyboard would facilitate this, where many split keyboards already is. - I must be able to buy them off the shelf. I do not have the skills to design it from scratch, nor do I afford to put more strain to my hand to assemble it from parts. - ergonomic must be one the of the primary goal of the keyboard, to minimize RSI. Speed is not important at all for example. - from my empircal experience, split keyboard, espeicially true split keyboard would encourage a better wrist and shoulder ergonomics. Hence I require split keyboards.
Based on these criteria, I bought ZSA Moonlander (QMK based) personally and Kinesis Advantage 360 Pro (ZMK based) for work.
The mirror key based design is currently at
- Moonlander https://configure.zsa.io/moonlander/layouts/QwA3z/latest/0
- Adv360 Pro: https://github.com/ickc/Adv360-Pro-ZMK/tree/dev
The key concept are that the mirror key can be implemented as a layer, and shift also functionally acts like a mirror.
Thumb cluster are then dual function, where on hold a key could be the mirror key (via layer), another key could be the shift key. And since mirror+shift is needed, you either hold both (which is a bit less pleasant for the thumb), or have another layer serves as the shift-mirror key. Over there, every key is implemented as holding shift+key at mirrored position.The ZSA training site is useful to iterate this design process: after each iteration I'd train per single hand and see if it works. For example in my earlier design I mainly focused on testing single left hand use and later found it doesn't quite work for single right hand.
Finally, macOS sticky modifier is used to hold modifier with a single hand. I.e. Ctrl+Opt+A becomes Ctrl+Opt, release, A. This is because OSM in QMK cannot handles one-shot of multiple modifiers well. Without doing fancy thing, you need to do Ctrl, release, Opt, release, A.
Same design working across Moonlander and Adv360 is important. Layout differences is not that much thankfully, but firmware difference can be a pain.
Lastly, I recently bought a Silakka54 for the ocassions where the setup hassle of either is too high. Basically either lap use or going to a meeting. I think my current layout design is adaptable to it but I'll see.