may I recommend the 3M 6000 Series Full Face Respirator?
since the feds are using projectiles on random persons, something that is shatter resistant / impact tested for eye protection should be prioritized. pair with some 60926 filters and you should be good to keep resisting.
Have you tried the non-over-the-ear cochlear devices? The kind that have everything built into the part that sticks magnetically to your implant — I don’t know what the term is; I don’t use them myself.
I know somebody who really dislikes the over-the-ear type devices and swears by the all-in-one kind.
She seems to get a full day of battery out of hers, but I don’t know what kind they are and I imagine usage patterns make a big difference.
> Have you tried the non-over-the-ear cochlear devices?
No, I have not, but from what I've heard, the sound processing isn't as strong because with the BTE (Behind the ear) models, the microphone is unobstructed and can pick up sound coming from the front. With the all-in-one devices, the microphone sits slightly behind the head and has a horizon (and hair) obstructing the audio.
If I'm wrong and the sound processing is actually decent, I'll be willing to give it a shot provided my insurer decides to carry Med-El.
Yeah, I’ve wondered about that. Apparently it works for her, but… everybody’s different.
I actually know a number of people with CIs, but everyone else is at ASL club, so we’re not doing a lot of speaking. I’ll have to ask folks what they’ve tried, if only for my own curiosity.
that's the Med-El's Rondo processor they referenced (there's also the Cochlear Kansu), so presumably they know of them and have tried them
For what it's worth in the UK the NHS no longer provides the off the ear models (at least for children) as they say they have too many problems with them
I’ve been surprised how infrequently I need to explain this — definitely fewer than 10 times in the last 20 years of doing some variation if this consistently.
I keep expecting to have to explain, but the vast majority of the time people don’t ask.
Similarly, I used to stress about loading the dishwasher when I was a teen. I would spend so much time loading it that I have myself a neck ache from leaning over and I could have saved time by washing the dishes by hand.
I still try to be somewhat efficient about loading the dishwasher, but… if I notice myself stressing I just say “screw it”, run it, and wash the rest by hand.
The other thing I’ve realized is that sometimes things don’t get clean if you load them properly. For example, tall glasses that had smoothies in them. It’s a little gross if you don’t notice it until you’re about to use it, but… you can just look at them and wash them by hand when you unload the dishwasher.
I guess this is all to say that sometimes the best optimization is to not think about it too much.
This is a matter of operator precedence and tokenization. Tokens are single characters in this language, and there is an invisible operator between them.
If the operator were explicit (let’s call it ~), the example would look like this:
There is a hidden operator of concatenation as for usual regular expressions. In the code I denote it as lower dot '.' (as in the old Thompson's implementation).
Cool, I’m interested to see where you go with this.
I found the operator precedence unnatural, and it looks like a lot of other folks in this thread did too. I would naturally assume `cat:dog` would be equivalent to `(cat):(dog)` rather than `ca(t:d)og`.
This is a very interesting idea for a few reasons.
> I would naturally assume `cat:dog` would be equivalent to `(cat):(dog)` rather than `ca(t:d)og`
It was confusing to me too until I remembered that we all kind of use regexes sort of wrong. They're "really" supposed to be considered as generators and not matchers. So IIR cat|dog as a "regular expression" (not a regex) is supposed to formaly expand to
{catog,cadog}
For matching, this set of strings can then be substring matched against some larger text.
The problem is that almost no regex matching engine actually does this, and so now they'll do all kinds of strange things either to meet our expectations, or for efficiency or something.
If you go and try a bunch of different regex tools you'll get variations that either service (cat)|(dog) or (cat)|(dog)|(ca[td]og) or something else.
So from a more formal conceptualization I think cat:dog should produce ca(t:d)og not (cat):(dog). But our experience with "regex" tools has subverted that formalization and now everybody just puts parens around expressions they want to alternate.
My real minor issue with this proposal, as interesting and well thought out as it is, is that it feels like it's just trying to get back at regular expressions as generators, which they actually are and it's coming from a place on the other side of a few decades of how we've been abusing them as regexes for user expectations. In other words, the problem is the tooling, not the syntax.
source: I've worked adjacent to this space in the past and if you've never thought of regexes as string set generators you can toy with the idea here
but again, how these generator tools works is also very specific. The ones I used to work with had a variety of ways to specify constraints on closures and such to restrict the generators.
There’s no reason to say that “ca(t:d)og” is a “more correct” parsing than “(cat):(dog)”. You did hit the nail on the head insofar as that you realized that we as programmers have built strong habits and make assumptions on the basis of those habits. But you didn’t take it to the logical conclusion and didn’t realize that having a text-based syntax to represent regexes is also such a habit/assumption.
In pure theoretical computer science, regular expressions exist as an abstract concept independent from syntax or parsers. They are an “algebra”, which means they are composed of elements connected with operators, but they are not inherently tied to a syntax. In the most fundamental formulation of regular expressions (the one in the Chomsky hierarchy), the only operators are alteration (which modern syntaxes express as “|”), the Kleene star (“*”) and — notably — concatenation, which modern syntaxes simply omit, in a way comparable to how modern mathematics notation omits the multiplication operator when you write “2x”.
In the same way that maths needs rules to define whether “2x²” means “(2x)²” or “2(x²)”, regex syntax needs such rules too. This is called operator precedence. I’m sure you’ve heard that before, but you just might not have realized that the regular expression “ab” has an operator in it because it is typically not written.
Now I’m not going to argue that the operator precedence in maths notation is haphazard or without reason — but it is arbirary. It was arbitrarily chosen to be the most useful to mathematicians using the notation. And it turns out that giving exponentiation higher precedence than (invisible) multiplication (meaning: “2x²” means “2(x²)” rather than “(2x)²”) is more useful.
So coming back to the original example, whether “cat:dog” means “ca(t:d)og” or “(cat):(dog)” is simply a matter of defining the precedence of the “:” operator relative to the concatenation operator. You can argue (and I would agree with you) that one is more useful than the other, and therefore preferable (in the same way that “(cat)|(dog)” is more useful than “ca(t|d)og”), but neither of them is more fundamentally correct or primal or, as you put it, “supposed to formally expand to”.
I agree with the point that precedence is arbitrary. The current version looks like this:
1 Escaped characters
2 []
3 ()
4 * + ? {m,n}
5 :
6 . (implicit concatenation)
7 |
I have some reasons to put it that way. I want : to be somewhat 'atomic'. If you think about '*' or '+' they can be lower in the table as well. Anyway, I will try to put : lower in the next version and see how it goes.
Thank you for the feedback. Yes, the precedence is a question for me. Maybe I will change this.
If I shift it behind concatenation there could be another problem. E.g. with non-associative : should be illegal. And I am not sure how to treat this:
cat:dog:mouse
In the current version I inject the epsilon (empty string). It looks natural E.g. to remove every second letter I could run '..:' which is technically '.(.:eps)':
echo 'abcde' | ./trre '..:'
result: 'ace'
actually ':' association could have a meaning as a composition of regular relations; but I found it too complicated for now.
I do not understand the rules by which you inject the epsilon and I think this is a source of confusion for many people. I had thought that an epsilon could be injected anywhere REGEX can appear (effectively allowing epsilon as a REGEX) but of course that just leads to infinite number of parses. Manually injecting epsilon is a highly hacky thing to do; better to consider that when you design the grammar.
I would not worry about "cat:dog:mouse" because intuitively it is clearly correct and it means replacing cat with mouse. With parentheses it could be written as "((cat:dog):mouse)".
Epsilon injection appears whenever right or left side of ':' has no operand. E.g.
(:a)
(a:)
a:|b
a|b:
etc
I will try to change the precedence and see how it works.
Btw what do you think about explicit operators '>' '<' where '<' works as usual regex matcher, and '>' as a generator. For example to change 'cat' to 'dog' there could be something like '<cat>dog' where '<cat' part is a parser and '>dog' is a generator. Thanks.
Yeah. Similarly, for the range transformations, instead of `[a:A-z:Z]`, I would suggest `[a-z:A-Z]`; and instead of `[a:b-y:zz:a]`, something like `[a-y:b-z;z:a]`, perhaps.
I would suggest simply [a-z]:[A-Z], inspired by tr.
Then there is no syntactic special case. This is just EXPR:EXPR; the special case is that both EXPR are character class syntax, and so the tr-like range mapping applies.
[a-z] is a semantically equivalent regex to a|b|..|z, but the two are not equivalent syntactic forms.
Distinct syntactic forms can be given distinct semantics, as long as there is rhyme and reason.
Moreover, the right side of the colon is not the normal regex language, it only borrows its syntax. So there, we may be justified in denying that the usual equivalence holds between character class syntax and a disjunction of the symbols denoted by the class.
The right side is a normal regex language syntactically. Semantically it is a generator instead of a parser (consumer).
But I got your point. Maybe there could be some ways to do it in consistent way. Just straight tr-like syntax won't work, e.g I really want it something like this to be valid:
I just sent a feature request[1] to Signal with the following text:
I understand that Signal does not consider this
https://gist.github.com/hackermondev/45a3cdfa52246f1d1201c1e8cdef6117 to be
a valid security bug, but it would be helpful to at least be able to
mitigate it.
Please add an option in settings to disable automatically downloading
attachments.
That should be enough to change the attack from 0-click (just opening the
conversation) to 1-click (click the attachment). Most people won’t care
about this, but for some every little bit of privacy is important.
Hold on, someone else in this thread noted this does exist
"
You can disable the auto-download. Settings > Data and storage > Media auto-download, you can choose what to auto download for mobile data/wifi/roaming."
So, that part is there, but my question is, it's still aissue when they manually download the image, right? Unless something never accepts images from someone they aren't expecting, who 's number or unique created ID has never been seen before
> I decided it was finally time to build a file server to centralize my files and guard them against bit-rot. Although I would have preferred to use OpenBSD due to its straightforward configuration and sane defaults, I was surprised to find that none of the typical NAS filesystems were supported.
Theo is, perhaps rightfully so, against importing what is effectively a paravirtualized Solaris kernel into the OpenBSD source code in order to run a file system.
Too sad, because the partitioning of OpenBSD is why i don't use it, with ZFS you could just do a dataset throw x^w,nosuid etc on them and give them a quota, with ffs one can bet that you run out of space (earlier or later), in one of the partitions (Workstation NOT Server).
I doubt it. Even for ports you can still symlink /usr/ports to $HOME/ports, for Scummvm with --enable-all-engines or Eduke32 (Build/GPLv2 license clash, can't be shared as a binary).
I think they're trying to say is you can just link stuff to $HOME if some filesystem runs out of space (not an endorsement of that view, just an explanation).
They also have a YouTube channel that adds images and video to the same audio track. A lot of it is just stock footage, but I like the images of ruins and the renders of what cities might have looked like in the past. It’s especially helpful when they’re discussing artwork.
Just so you know, the last two (or so) videos have had expensive custom images, video, reconstructions, illustrations, self shot on-location imagery, etc. He mentioned it in an intro awhile back. That's the reason for the long delay between recent videos.
The stock stuff earlier really adds value though. It's not some generic background pan and zoom. If it's in the background it's probably being activity talked about and being used as a visual aid. Having a map of an area or seeing the ruins as they are today or quotes from sou fe out of books etc really elevates the experience.
I honestly don't listen to the non-video ones they are such an essential element.
Given the number of services that turned out to use plaintext or trivial password hashing (e.g. MD5), I would bet there are a bunch of services out there that do not effectively limit OTP attempts.
It’s been a long time since I did any work on a real authentication system — since before TOTP was common, anyway. I appreciated the post and found it interesting.
I have no personal experience with Mira; I’ve been looking for a respirator myself because I live in Portland.