well well well, I'm pretty sure the more than 800$ dollars won't be accepted as I already go to Hepix (a conference for computing in high energy physics) 2019 in Amsterdam in October. But still would be very interested.
I would say that most tends to describe state of the art (which is often not implemented ) so interessting to know what you should or could do, but the bouding to know that you're not the only one with a problem to share with other it's priceless
the conferences I enjoy the most are those where you can go to a talk, discuss it with the people involved, and even start hacking on stuff in the corridor straight after
DebConf is the best conference I know of but its audience is somewhat limited ;-)
Well now I'm working with centos, I loose a bit my interest in Debian and I have to admit the adoption of systemd was kind of an unpleasant move from my pov
as long as code review doesn’t happen in the same bar at 4am ;-)
Kernel patches tend to go through a bunch of iterations, so even if the initial stab is at 3am in a bar, follow-ups (if needed) won’t happen in the same context...
I was joking of course, I've been doing some dev from time to time and I exactly know how some Idea could be the best at 2:00 am and be the worst the day after when your eyes align with your orbit
I guess it also applies to my marvellous plans to enslave the whole human race...
isn't it a question for Kusa ? https://unix.stackexchange.com/q/538674/53092
I feel someone's trying to parse gene sequence with regexp
You can generate more combinations by using the same division approach after incrementing; this would give 6 5 4 again, then 7 4 4, then 8 4 3, 9 3 3, 10 3 2, etc.
If you only increment in the same direction, you end up with fewer dupes to deal with, assuming number order isn’t important.
@FaheemMitha I'm making a random password generator that will just string together words from the dictionary file. I want it to pick random length words based on a given maximum password length
If you’re generating passwords using a dictionary, the simplest approach is to pick n words at random, and if they pass the length criteria, keep them, otherwise restart.
Length is very important, but dictionary words don’t count. Basically, if you’re looking at length, you should consider that one word counts as one character.
I think the odds of my password being brute forced are next to zero regardless of how complex it is, and all passwords will likely eventually be compromised one way or another due to vulnerabilities in the system they are stored, keyloggers, or something similar. Also regardless of complexity
But nowadays hashing speed is insane, so if you’re trying to resist that (i.e. the password database is leaked) then you need passwords made of random chars
r_sum () {
local total=$1
local remain=$total
local temp
local arr=()
until (( $remain == 0 )); do
if (( $remain <= 3 )); then
arr+=( "$remain" )
break
fi
temp=$(( RANDOM % remain + 1 ))
(( remain -= temp ))
arr+=( "$temp" )
done
echo "${arr[@]}"
}
Has issues with being random when generating extremely long passwords. I changed the random number function to make temp = 24 if temp was greater than 24 since the largest words in the dictionary I have are 24 characters. That causes it to choose 24 character words more than anything else if you are generating a password that is much larger than 24 characters
Had the same thing today. Turns out it's caused by grub-probe trying to access partitions through /dev/sda, which is not cache-coherent with /dev/sda1 (and sda2 etcetera).
You can fix it using
blockdev --flushbufs /dev/sda1
(repeat for other partitions as necessary).
@FaheemMitha It's the latest fad in multi-factor authentication: (1) something you know, (2) something you have, (3) something you are, and (4) something I made up
randomize () {
local input=$1
local length=${#input}
local index=0
local char
local string
while [[ $index -lt $length ]]; do
char=${input:$index:1}
if (( (RANDOM%10) < 4 )); then
case $char in
a) char='@';;
l) char=1;;
o) char=0;;
s) char=5;;
*) char=${char^};;
esac
fi
string="${string}${char}"
((index++))
done
echo "$string"
}
@StephenKitt That's not quite right. /usr/share/dict/words here is 654895 lines, so ~19 bits of entropy per word, if picked entirely randomly. Quite a bit more than the ~6 bits from a random character.
So something like hieroglyphing incombustible unrestorative warrantability's is ~75 bits of entropy (lost a few bits because I rejected a bunch of ones until I got something half sane), which is AFAIK well beyond hash attacks even on something quick like single MD5.
@FaheemMitha Maybe it's a rock or something? You can put hieroglyphs on those, they don't burn, and they're not very comfortable to sleep on. Not sure where you get a warranty on one, though.
I wonder if there is a brace expansion to include all special characters
Also I wonder why I can do {A..z} to wrap around uppercase (through some special characters) and then all the way through lowercase, but I can't do a similar thing with numbers to letters
@Jesse_b Brace expansion in bash only works if both the start and the end of the expansion is of the same "type" (alphabetical or integer). It will not work if either is different of different "type" of the other, or if either is non-alnum.
(I checked: if you use cp -a on a single file, it makes a copy, which isn't linked to any other copy. If you use it on a directory, which contains two names for the same file (hardlinks), then the copy of the directory it creates also does that.
@Jesse_b I wrote a passwd generator like that. It picks multiple random words (with -w, -m, and -x options for number of words, min word length, and max word length. defaults 4, 4, and no maximum), and joins them together with spaces and random 1-3 digit numbers and/or punctuation. It also randomly capitalises some letters in each word. output is the generated password, followed by the length. e.g.
words alone are probably easily cracked (although more words is better). words plus random punctuation and numbers is far less easily cracked. I never bothered writing a script to do this until after the "correcthorsebatterystaple" xkcd comic, but I've been manually making multi-word passwords separated by numbers and/or punct since the early 90s. easy to remember, and once you type them a few times, your mind automatically associated the words with the numbers/punct in the right order.
these days most things that require passwords don't impose stupidly short (8 or 12 or 16 characters) password length limits....but back then it was a challenge to come up with a good password that fit in the limit.
catdogfish is a crap password. but cat 43doG 1 fIsh 77! at 20 characters is good enough to defeat current brute-forcing. The longer the better. and use a password-safe program. e.g. pass to store them in a gpg-encrypted git repo.
for truly random passwords, i just use pwgen to generate passwords with 32 or more characters. e.g. pwgen -c -B -y 32
Had the same thing today. Turns out it's caused by grub-probe trying to access partitions through /dev/sda, which is not cache-coherent with /dev/sda1 (and sda2 etcetera).
You can fix it using
blockdev --flushbufs /dev/sda1
(repeat for other partitions as necessary).
