Show HN: A tool to sign PDF files. With Linux support
https://github.com/svenssonaxel/pdf-sign
We are here referring to the visible, non-cryptographic squiggles.
https://github.com/svenssonaxel/pdf-sign
We are here referring to the visible, non-cryptographic squiggles.
It failed badly. While it's easy to construct sentences that way, it puts immense cognitive load on the receiver. Probably because you don't have any structure in which to put all these terms thrown at you, we reasoned, so we reversed the order to get structure (connectives) first, followed by the terms.
It wasn't better. Turns out, receiving a structure with a bunch of holes to be filled later also results in high cognitive load.
Why? My guess is that the cognitive load mainly comes from the number of unfinished structural connections. To minimize that, you need to transmit a tree in such a way that the terms come as close as possible to the connective. In other words, not bottom or top first, but "side first".
I believe this is why infix notation is so popular. While you parse "A and B" or "X + Y" you never have more than one open connection. When you parse "(+ X Y)" you have two open connections after reading the "+". Five levels deep that begins to matter a lot.
I like the purist lispy idea of operation-first expressions, but I struggle to make my mind actually work like that. If you like clojure-type threading macros, consider that they do something similar to infix notation: they reduce the number of open structural connections during parsing.
In philosophy, theories of time are categorized in A- and B- theories [1].
In B-theoretic time, the difference between past, present and future is only subjective. Objectively, all points in time exist and are equally real. I view this to mean that there isn't any particular difference in the degree of reality between our reality and any mathematical model or imagined reality. Only with A-theoretic time are you objectively more real than Donald Duck.
The README lists alternatives and why I find them insufficient. Okular allows free-hand annotations, but not saving those for later use. It allows inserting custom saved stamps, but these will not be visible in other PDF readers.
Then it converts 231 in^3 to 0.99999994293884 U.S. gal, while 1 U.S. gal converts to 231 in^3.
When backup excluded some files, they blamed antivirus software and recommended to go without.
They actively deleted their only backup because the client couldn't read the original files (which was due to disk error).
They admitted that there isn't any guarantee or even effort to make the backup consistent - after asking me to explain the concept.
The only reason I still have my data is because of the very expensive cleanroom disk rescue that they of course refused to pay for - because why try to do what you can to compensate for failing at your only job?
As the rate and quality of AI-generated content keeps increasing, it seems inevitable that it will become easier to create fake content and harder to verify/refute it.I keep thinking that "someone" could use cryptographic time-stamping as one line of defense. As a philanthropic effort, it seems relatively easy, cheap and valuable to do so. I imagine a web archive could save a stream of hashes...
Do an image search for "Samsung group ownership structure"
As an example of just how arbitrary Gödel numbers are, consider the expressions `((3*n)+1)` and `((n*3)+1)`. Those expressions are clearly equivalent, yet the Gödel numbers for those two expressions are wildly different, with a relation that is rather complex.
IIUC Gödel himself never "used" or analyzed Gödel numbers as such, only the idea that they could be constructed.
One way of scaling it that has already been done is to use the customer's humanness, by selling a book. That scales. Now, if the price point is $500 for a small but high quality business idea validation, what can you do that's better than selling a book on how to do it? Could you train coaches, who then can bill over $100/h and let the customer execute on it? Willing customer right here.
This is a fairly big undertaking, including at least:
- A standard for representing and installing grammar information. Perhaps a file in /usr/share/grammar/ for each programming language, packaged in each language's own tools. Since not all languages are context free, the format must support more advanced grammars as well, at least indexed grammars, maybe more. Perhaps grammars should be able to depend on and extend each other (e.g. HTML can have a JavaScript node), perhaps they definitely should not.
- A new text-based diff/patch format that is less line based so that the difference can be communicated on a more semantic level, while still retaining exact reproduction i.e. B = patch(A,diff(A,B)). Add and delete should probably still be the only supported operations, but maybe not.
- A standard for representing semantic weight. The patch operation is deterministic but diff is not, i.e. given A and B, there are many possible patches that, applied to A, would correctly produce B. The job for the diff tool is to find a patch that both is guaranteed to correctly produce B, and as closely as possible describes the difference the same way a human would. Example: In Python, removal of an If condition and promotion of the contained 100 line code block should not be represented as delete 101 lines and as 100 lines. Rather, it should be represented as delete 1 line and delete 100 indents, on the correct level. The semantic weight information that allows diff to choose the best representation in most cases, might be produced using ML. Imagine a collaborative effort to produce training data using commits from open projects, where in most cases a human would simply select the patch candidate that is most easily understood. The semantic weight representation would probably have concepts for other operations than add and delete.
- The actual patch and diff tools. Patch implements only the patch format and has no dependency on grammar or semantic weight data. Diff is where the effort lies. Perhaps some languages are not best served by the generic approach with grammar and semantic weight. In these cases, diff should be pluggable. Perhaps /usr/share/diff can contain configuration for each language e.g. whether it uses a certain grammar and semantic weight file or a custom binary. It also needs some way of detecting which language to use for a certain file.
The vast majority of version control information (including git) is snapshot-based, meaning that among the many possible patches from A to B, none is preferred by the version control data. We are completely free to improve the way our tools select these patches, and it will be completely backward compatible with the existing wealth of version control history. We'd just be able to look at it with more clarity.
You propose to make web protocols/standards and national laws tightly coupled for the long run, to solve a usability problem in the short run. That's the wrong hammer for this delicate ceramic vase. Can you imagine what it would take to evolve web standards if they have to do so in tandem with the laws of dozens of different countries? If the law says cookie acceptance can be a browser setting without giving details, that's not too little detail. Even mentioning cookies might be too much detail for a law.
I am annoyed too, but I direct my annoyance at the entity that made the wrong usability and privacy decision, which is the organisation behind the website in question. Website owners (should) have every incentive not to annoy their users. Designing websites without cookie consent pop-ups is possible, legal, and a competitive advantage. As a user, removing the pop-ups automatically is also fairly simple. Let it play out. It's gotten worse before it gets better, but I believe GDPR is ultimately a force for good.
Example: Integers. Add 5 jugs of water with a gallon each and you end up with almost 5 gallons. You call that a measurement error, not a leaky abstraction. The jugs are wrong and the math is right. Play on words really, since you could as well say that the integers are a leaky abstraction that fails to take into account inexactness. Point is, people don't tend to think of it that way.
10⁰: Axiomatics
10¹: Logic
10²: Mathematics
10³: Computer Science
10⁴: Software Engineering
10⁵: Group Psychology
10⁶: Politics
10⁷: Crisis Management