wbolster

the git repo has more info about the 15.11.2 release: https://gitlab.com/gitlab-org/gitlab/-/commit/d5dc7d794ce2fc...

- Only maintainers of projects should be able to assign runners to them (gitlab-org/security/gitlab@c52abfffad2c06c2a49788e3db473f14923c3926), merge request (gitlab-org/security/gitlab!3234)

- Authorize access to vulnerabilitiesCountByDay resolver (gitlab-org/security/gitlab@8e78aecb9a6c248099a043f181de3c8f6d4417ce)

and a bit of further digging shows the commit for the first issue mentioned above, adding a permission check: https://gitlab.com/gitlab-org/gitlab/-/commit/c52abfffad2c06...

i doubt there's a noticeable difference after applying any "dumb" file compression scheme, e.g. brotli/gzip

this can be solved on the file system layer below.

on my laptop with btrfs this requires no special effort: simply copying the files and renaming them suffices. nautilus (gnome file manager) uses copy on write, and coreutils "cp" also defaults to "reflink" these days.

not sure about mysql, but in postgresql an update on a table with a foreign key will take 'FOR KEY SHARE' locks on the referenced table, which is a weaker type of lock. updates on the referenced table that do not update (primary) key columns (changing a pk is very uncommon anyway) will suffice with a 'FOR NO KEY UPDATE' lock, which does not get blocked by 'FOR KEY SHARE' locks. in fact, the main reason postgresql has these weaker 'FOR KEY SHARE' and 'FOR NO KEY UPDATE' lock types is for handing of foreign keys.

nit: the suffix -um in latin typically indicates a neuter grammatical gender. -us is usually masculine, and only in its accusative form it becomes -um. there are exceptions though, e.g. feminine 'manus' (hand). https://en.m.wikipedia.org/wiki/Latin_declension

in a similar spirit, i wrote "sanest", sane nested objects, tailored specifically for json fornats: https://sanest.readthedocs.io/

it does not have the exact same feature set though. my focus was mostly on both reading and modifying nested structures in a type safe way.

thank you, random stranger, for sharing your gnu/extremism.

while i am in no way defending software patents (which I don't like at all), i find the full-frontal attack attitude that you and many other gnu/zealots exhibit towards random strangers on the internet so infuriating that i am writing this comment here to let you know that people like you are exactly what prevents me (and many others) from getting involved in some free (libre) software projects.

thanks so much for your contribution to the advancement of libre software.

yuck.

this is a very important point. i tried swiping in my phone using the colemak keyboard layout which i use on normal keyboards, and found it utterly unusable because the prediction quality dramatically goes down. this is most likely caused by the lack of shapes made with the swiping gestures: colemak has the most common letters on the home row so on practice you're mostly swiping left/right.

thanks for writing this down. i completely agree with you.

i am a happy emacs and magit user. i contribute to emacs packages, and maintain a few myself (emacs-direnv, evil-swap-keys, evil-colemak-basics, evil-text-object-python).

i do all this DESPITE emacs being a fsf/gnu project. i strongly dislike the old-fashioned processes, the extreme stances on things that i do not consider problems, and last but not least, the very negative and non-inclusive community.

the remarks by rms that a magit alternative/competitor would be welcome is POISONOUS. advocating for an unnecessary community divide is destructive for the goodwill of many (potential) contributors to the emacs ecosystem (myself included).

that project did not exist since i switched to colemak only recently, and that made my evil-mode setup (vim editing on top of emacs) completely unusable for me, which is why i started this project.

for a similar vim-based implementation (which served as inspiration for my remappings), see https://github.com/ohjames/colemak

keep in mind that normal keyboard activity is completely different than typing a piece of text from the first letter to the last letter in one go. being efficient with navigation, moving text around, and so on, is just as important, so invest in learning vim, emacs or any other editor that makes sense for you. unfortunately keyboard layout analysers do not capture those key presses, making the results very skewed.

many consider it best to touch type your normal layout (colemak, qwerty) and to use hunt-and-peck when forced to use qwerty. it helps not messing up muscle memory for the normal layout, since hunt and peck is a conscious effort.

you mistake speed as the dominant factor and then you claim you are fast enough so switching is not worth it, while you should instead focus on comfort. you will only fully realise this after experiencing pain.

also, while vim hjkl navigation was designed for qwerty, emacs shortcuts are not.

(for a vim + colemak alternative see the rationale for the layout i use: https://github.com/wbolster/evil-colemak-basics#design-ratio... )

if you are interested in vim ergonomics and alternative layouts, i wrote extensively about the vim + colemak layout i use on a daily basis: https://github.com/wbolster/evil-colemak-basics#design-ratio...

among some other differences, colemak has better shortcut compatibility. a z x c v are on their qwerty position so "select all", undo, cut, copy, and paste are one-handed shortcuts for which many people have muscle memory.

if you are using dvorak, switching to colemak may not be worth it.

the bottom line is that any layout that is not qwerty will likely be an improvement. differences between alternative layouts are small compared to the differences with qwerty.

perhaps you should give a split keyboard a try.

the historical reason for staggering are the metal arms on mechanical typewriters, which obviously does not make any sense nowadays, but unfortunately the design stuck, as did the qwerty layout.

non-staggered keyboards, such as the kinesis advantage, better match the shape of the hand, sometimes even with vertical "staggering" instead of horizontal.

additionally, the thumbs are the strongest fingers but are only supposed to hit the (huge) space bar. this is the problem that alternative physical layouts like the ergodox and the kinesis advantage try to address.

also, split keyboards allow you to use wrist and arm angles that match your body instead of the keyboard.

different letter layouts like colemak (good, especially modern computers) and dvorak (also good, but designed in the pre-computer era) significantly reduce finger travel and improve on finger and hand alteration. for me personally, colemak works great to prevent strain.

Logging in means granting access to all kinds of private data, including deploy keys. This doesn't seem right.

The benchmark at https://github.com/facebook/rocksdb/wiki/Performance-Benchma... states that for LevelDB, "in 24 hours it inserted only 2 million key-values", and that "each key is of size 10 bytes, each value is of size 800 bytes".

I might be missing something, but that took just a few minutes on my ~2 year old desktop machine. Sample code: https://gist.github.com/wbolster/7487225

I think the name is triple A, and so is the spelling. :)