Hacker Newsnew | past | comments | ask | show | jobs | submit | more MrManatee's commentslogin

There's a lot of information, data, and software out there that is available to download for free. Yes there are hosting costs, but there are also people and organizations that are willing to pay them because they believe that it's worth it.

I'm absolutely convinced that if copyrights weren't an issue, there would be enough governments, foundations, universities, corporations, and individuals willing to pay the costs of making scientific publications available to everyone. It wouldn't have to be a paid service.


Indeed. The author's appreciation of Lisp is well known. If he really is convinced by this abstract argument, it would have been nice to know what other weird languages besides Lisp it has inspired him to learn. APL, Prolog, Smalltalk, R, Haskell - perhaps?

I don't mean to be too dismissive. I think this short piece was thought-provoking enough to be worth reading, and it was not a bad argument in favor of Lisp. Maybe I really should learn Lisp. But if the heuristic was generalized from just one example, it might overfit to just one particular kind of weirdness.


This is making me wonder if the experience is intentionally so bleak.

It reminds me of how nowadays when I do an incognito Google search on my phone, I need three taps just to accept the terms of service. Same with YouTube. Maybe this level of cumbersomeness is somehow legally required now, but I find it more likely that this is an attempt to subconsciously encourage people to not browse incognito—so that they can be tracked.

My understanding is that being logged in in your Google account often allows you to bypass captchas. If captchas are a miserable experience, this would have a similar effect of subconsciously discouraging incognito browsing.


It does feel like a similar sort of thing to how fag packets are this horrible murky brown with bleak pictures in them in the UK.


fag is British slang cigarette, for any scandalised US folk reading this :-)

(Does this still need saying?)


There’s always someone who is learning this for the first time!


Lucky 10k


And for those in the lucky 10k learning about the lucky 10k today, https://xkcd.com/1053/


It doesn't have to be linked every time someone learns something.


Google for: friction ux


I wouldn't say it makes "little sense". Just like we can talk about the year 776 BC even though no one at the time called it that, we can extend the Gregorian calendar backwards to dates when it wasn't used anywhere. The Wikipedia article on the proleptic Gregorian calendar lists some use cases. [1]

And in any case, 15 October 1582 isn't some hard cutoff point where we can stop worrying about calendar conversions. Only four countries adopted the Gregorian calendar on that day, and even in Europe there are several countries that only switched in the 20th century. If a piece of software needs to support historical dates that go anywhere near 1582, it needs to be aware of the existence of different calendars.

[1] https://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar


The article says that "it should be pretty straightforward for law enforcement to disprove an accusation about the Cellebrite machine", because they can perform the same extraction with another vendor's machine and compare the results.

But if some app actually decided to use this hack, then wouldn't it be likely that in addition to modifying the contents of the data dump it would also modify the on-device data? In that case it wouldn't matter if the other vendors have vulnerabilities, since the device itself was already compromised.


The most interesting version of this exploit (to me) would be one that wiped the device being examined.

Edit: changed disruptive to interesting. There could be many many more disruptive versions...


Quite the 'aesthetically pleasing' side-effect for sure.


Tell it to the jury I guess. "Yes, of course there's evidence of a crime on my phone, but actually I put it there just to trick the police."


Or: "If there is any evidence of a crime on my phone, it was probably planted there by a version of Cellebrite that got infected with a virus when you scanned someone else's phone with it."


The sentence would be true iff your replace "probably" with "possibly". But - as the original article states - that's not sufficient. The defence may try to assert that this is the case, which may cause that possibilty to be investigated in more detail, but such a statement would not automatically disqualify the evidence without something more substantial, merely asserting that such a possibility exists isn't enough.

E.g. such a claim might result in a forensic analysis of that Cellebrite computer, and if the analysis indicates that it indeed got infected with a virus when scanning someone else's phone, that's likely cause all the evidence to be questioned, but again, even in that case there may be other ways than the Cellebrite logs to confirm that this evidence was indeed on your phone (the original article asserts this as well).


I might be misunderstanding you, but if you're referring to things such as ζ(2)=π²/6, then that doesn't strike me as a good example of "nothing to do with circles" and "in those places tau does not do better". This value is a special case of a more general formula that specifically features (2π)^(2n), so on surface tau would seem more natural here [1]. Also, the most intuitive explanation that I have seen for this particular case (the value of ζ(2)) was in a 3Blue1Brown's video, and it did involve circles. [2]

[1] https://en.wikipedia.org/wiki/Particular_values_of_the_Riema...

[2] https://www.youtube.com/watch?v=d-o3eB9sfls


I've always interpreted "under-promise and over-deliver" as being about keeping your promises despite future unknowns. The simplest example I can think of: If you think some task will probably take 2 days, you say you'll do it in 3 days. If your original estimate was right, you'll be early, and others will just be pleasantly surprised (you over-delivered). If something unexpected comes up and your original estimate was too optimistic, you might still be able to do in the time you promised. Do this consistently, and you will get a reputation of delivering what you said you would.

Research article titles are descriptions of work already done, so I see them as "promises" of a different kind, and that's why the advice wouldn't apply. But if you said that you're going to write an article called "The Riemann hypothesis is true" before you have found a proof, then you're probably over-promising.

Campaign promises, on the other hand, are about future unknowns. I don't know much about campaigning, but I suspect politicians can get a way with over-promising better than most people, because the feedback cycle of elections is so slow.


But it’s not enough to steal a blank YubiKey from the office storage room. You would have to steal some specific person’s activated YubiKey, and that person will notice it if they need the key regularly to do their job.


I can also report a positive experience with Jamulus. There's probably people in this discussion who have only experienced the latency through Zoom or Skype, and assume it's about as good as you can get over the internet. It's not even close.

If you have special software like Jamulus, non-wireless internet, players geographically close to each other, and an external audio interface, the latency is surprisingly good. If you have most but not all of that, it can still be usable. Our end-to-end latency was around 30 ms, so not as low as parent's, but we were still able to play even "jam songs" where just followed each other for chord changes instead of having agreed them beforehand.


Tree-sitter is the library that Atom uses to parse as you type. It's incremental: if you just add one character, you don't have to parse the entire file from scratch. And it's robust: it tries to provide useful results even if there are syntax errors.

If you're more interested in the theoretical side of how it works, there are some talks and articles that cover it.

https://tree-sitter.github.io/tree-sitter/


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: