I mean, that sounds sorta like JWTs which are used commonly enough for this type of thing
brian
joined 2 years ago
why would you need to salt long random strings?
also if you salt them you have to have an id too so you can look up who's api key it is. otherwise you can just look up the key hash to get everything
why would you need to salt long random strings?
also if you salt them you have to have an id too so you can look up who's api key it is. otherwise you can just look up the key hash to get everything
things that store it as word size for alignment purposes (most common afaik), things that pack multiple books into one byte (normally only things like bool sequences/structs), etc
devil's advocate: other sellers would still do it if they didn't, which would make ticketmaster's tickets look more expensive initially. a law makes everyone equal again so they can compete on price/etc directly
yeah, if you bind ctrl c and ctrl v to copy and paste keys, you can get the same behavior in terminals and other apps that have weird default bindings for ctrl c and v for historical reasons
it is nice to be able to plug your keyboard into a new computer and have all your shortcuts and layout set up though. I do that so I have the same layout and shortcuts on my personal and work computers regardless of os
no, there are dedicated keycodes for copy and paste, and you can bind them to whatever
ctrl v is convention for paste, but plenty of things (ex terminals) use that for something else. this is a universal (wrt the app receiving it) keycode that means paste. it lets you bind a key, or a keyboard shortcut, to the paste key and paste in any app. without this it isn't possible.
it doesn't even have to be a new programmable keyboard. there exist software key remappers for linux.
you could remap a mouse button to paste, you could remap ctrl v to always paste regardless of the app, etc., all in software, all not possible before.
it seems like a new version of this kind of thing pops up often enough, but it seems like the people making them have never heard of AppStream. like I guess managing webapps too is unique, but everything else and more support AppStream, along with existing gui managers like kde discover, gnome software, etc
they're putting large amounts of binary data in git lfs, which is what it was designed for. lfs does have some rough edges though. if I had something really heavy on binary blobs, ex a large game or similar, idk if I'd be using git either. he extrapolates way too far though, most use cases don't run into any of these problems
and storing all that in a separate db is insane, it's stuff that should be versioned with the code. it's likely being created at a specific rev for the current code, and it evolves with it. if you git revert or create a pr, it should be part of that. it's not like they committed built binaries or smth. there should be tools able to handle this. git could be one of them if lfs was less rough
view more: next ›
sure, but if you have a single bool in a stack frame it's probably going to be more than a byte. on the heap definitely more than a byte