How do you discover the principles in the first place? You can discover them once and then apply them in all applicable places precisely because you generalised them.
You have a point that the result may very well be more easily explained in concrete terms to practitioners of a given field in which you applied it, though.
It's a pretty neat feature! I think it's in beta but it works flawlessly in my experience. Sure is a lot easier than setting up a separate (W)LAN with iptables rules to force redirect traffic.
A server is someone else's device. Your phone is your own device. So no, doing the scan on your own device and making your device your potential adversary is not better than doing it on the server. You can always choose not to use the server.
Apple only ever scanned images being uploaded to the server. They were only ever going to scan images (even if it was done on the local device) if they were uploaded to the server.
On the one hand you have:
- do the scan in private, get a pass (I'm assuming we all get a pass), and no-one outside of your phone ever even looks at your images.
On the other hand, you:
- do the scan on upload. Some random bloke in support gets tasked with looking at 1 in every 10,000 images (or whatever) to make sure the algorithm is working, and your photo of little Bobby doing somersaults in the back garden is now being studied by Jim.
If you never uploaded it, it was never scanned, in either case.
So yes, you've lost privacy because faux outrage on the internet raised enough eyebrows. Way to go.
lnav is amazing and I use it often. I do have a list of gripes where I think it could be improved, so I'm just going to dump them here in case you're interested:
- regex101 support for quickly defining custom formats is just awesome. Versioning support is slightly broken however, probably because regex101 changed something, so there's no easy way to update the format once you've initially imported it.
- I feel like there's missing opportunity for integration between various features.
- There are lots of different filtering capabilities, but there is no unified treatment of them. For example, `:hide-lines-before` and `:filter-out` are at their core the same type of operation: filtering. I should be able to pull up a list of all filters that are currently active and easily add new ones and toggle or delete existing ones.
- I would expect to be able to create a new view of the data using SQL `SELECT`. A select statement is fundamentally about filtering out some rows (log lines), which feels like a filter, and selecting some particular columns (log fields) and hiding others. The latter point seems like it could be something that should be handled when https://github.com/tstack/lnav/issues/1274 is resolved.
> - regex101 support for quickly defining custom formats is just awesome. Versioning support is slightly broken however, probably because regex101 changed something, so there's no easy way to update the format once you've initially imported it.
There is a `pull` sub-command and it looks like it still works. Running the following will generate a patch file with the updated regex:
lnav -m format <format-name> regex std regex101 pull
It creates a patch file since the original file might've been modified.
> - There are lots of different filtering capabilities, but there is no unified treatment of them. For example, `:hide-lines-before` and `:filter-out` are at their core the same type of operation: filtering. I should be able to pull up a list of all filters that are currently active and easily add new ones and toggle or delete existing ones.
> - I would expect to be able to create a new view of the data using SQL `SELECT`. A select statement is fundamentally about filtering out some rows (log lines), which feels like a filter, and selecting some particular columns (log fields) and hiding others. The latter point seems like it could be something that should be handled when https://github.com/tstack/lnav/issues/1274 is resolved.
It has (lots of) non-standard models. Or, to put it another way, there are statements that can neither be proved or disproved. This extends to any theory containing "enough" arithmetic and certainly any containing Peano Arithmetic. So ZF set theory is also incomplete in that sense.
You can "solve" this in Second Order logic, because you have a more powerful induction axiom, but how exactly you define that logic is tricky. There's no proof system that defines it completely, so you have to do this via a semantics that relies on knowing which models are or are not OK.
I don't think it solves the problem that you can't define all the "truths" (as most logicians would put it) of Peano Arithmetic.
Pure terminology. In some areas "Peano Arithmetic" is short for "first-order Peano arithmetic". In first-order logic, Peano's induction axiom can't be properly formalized, which means the resulting theory isn't categorical. For other people "Peano arithmetic" just describes the usual Peano axioms in natural language, which includes the proper induction axiom. Which can only be formalized by using at least second-order logic. That theory is categorical.
It's not a "lost" key if it's found hardcoded in an easily available place (e.g. an application). It's a negligently placed key leading to a vulnerable place that is going to get into the hands of a malicious person.
Your machine regularly uses that key to access what's behind the door on your behalf; there is no reason you shouldn't be able to access it yourself.
If you don't find the key and realise it's actually a lost one, leading to a potentially dangerous place, someone else will and they won't be benevolent.
You have a point that the result may very well be more easily explained in concrete terms to practitioners of a given field in which you applied it, though.
reply