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


I asked "Which country has the most subway stations?" and got the query

  SELECT ?country (COUNT(*) AS ?stationCount) WHERE {
    ?station wdt:P31 wd:Q928830.
    ?station wdt:P17 ?country.
  }
  GROUP BY ?country
  ORDER BY DESC(?stationCount)
  LIMIT 1
https://query.wikidata.org/#SELECT%20%3Fcountry%20%28COUNT%2...

which is not unreasonable as a quick first attempt, but doesn't account for the fact that many things on Wikidata aren't tagged directly with a country (P17) and instead you first need to walk up a chain of "located in the administrative territorial entity" (P131) to find it, i.e. I would write

  SELECT ?country (COUNT(DISTINCT ?station) AS ?stationCount) WHERE {
    ?station wdt:P31 wd:Q928830.
    ?station wdt:P131*/wdt:P17 ?country.
  }
  GROUP BY ?country
  ORDER BY DESC(?stationCount)
  LIMIT 1
https://query.wikidata.org/#SELECT%20%3Fcountry%20%28COUNT%2...

In this case it doesn't change the answer (it only finds 3 more subway stations in China), but sometimes it does.


Wearing a tin foil hat is getting real world applications


But how do you stop the neutrinos?


Just make your tinfoil hat a few light-years thick.


You could also wear a black hole as a helmet!


The authors suggest black foamboard with cloth and a laser safety curtain is sufficient. Better safe than sorry though.

  To prevent light from reaching the detector from sources other than light 
  transmitted through the head, the experiment was performed in a light-tight 
  enclosure that surrounded the head. The enclosure was built using black 
  foamboard and covered with two layers of black cloth and a laser safety 
  curtain. 
https://doi.org/10.1117/1.NPh.12.2.025014


Not for neutrinos it isn't


In EXIF, you have DateTimeDigitized [0]

For ambiguous dates there is the EDTF Spec[1] which would be nice to see more widely adopted.

[0] https://www.media.mit.edu/pia/Research/deepview/exif.html

[1] https://www.loc.gov/standards/datetime/


I remember reading about this in a web forum mainly for dublin core fanatics. Metadata is fascinating.

Different software reacts in different ways to partial specifications of yyyy/mm/dd such that you can try some of the cute tricks but probably only one s.w. package honours it.

And the majors ignore almost all fields other than a core set of one or two, disagree about their semantics, and also do wierd stuff with file name and atime/mtime.


A german kids show investigated this and made a video about it[1]. Here you can see the 4th option of what can happen.

[1] https://youtu.be/-sYZEOftpw4?si=T4btvhTJpfSzA9q2&t=35


The most environmentally friendly is to not eat meat.


If you continue this ad absurdum, the only logical step would be to perform a variant of seppuku. I see relatively little sepukkus performed around me.


Your morbid sarcasm does not add anything to this conversation. GP doesn’t bring arguments neither but at least stays courteous.


That's because people don't get that absurd and just go vegetarian or vegan, or generally just try to eat a little less meat


As a vegan of four and a half year, I can confidently say being vegan is not similar to killing oneself.


Super interesting project. I also started once a project to index food and their ingredients via gpt. The inaccuracy let me abandon the project. But never tried the new gpts for that.

One great resource is also: https://world.openfoodfacts.org/


About not being worried, that someone could read your mail in the case you're dead:

Always bear in mind you're not writing mails to yourself. The other party writing mails with you, might not be that happy with third parties reading their mails. Privacy is not only about you


> Always bear in mind you're not writing mails to yourself. The other party writing mails with you, might not be that happy with third parties reading their mails. Privacy is not only about you

People mailing me after I'm dead because they don't know I'm dead, probably aren't very close to me. If a marketer decides to send me deep felt confessions he needs to get off his chest, meh.


Worth considering that they can use access to your email to get into other accounts. Someone getting into my Google photos account would definitely affect the privacy of others for instance.

Though I think the way to defend against this is dead man switches for services with sensitive data, not using gmail


I'm still sad because PGP/GPG couldn't make the UX work for signing and encrypting emails 20 years ago. It's still a huge pain to do, even if you're a hobbyist like me.

Encryption/decryption should've been a standard thing everyone does transparently when sending emails with one recipient. Multi-recipient mails should always be signed, automatically.

Maybe some day.


IMO, GPG for email was mostly a mistake, because email can't be secured enough.

GPG leaves all the headers exposed, and reveals who's talking to whom. That, right there, is a huge security problem. Turns out metadata is often plenty. And it can't even encrypt the subject, which is a footgun of enormous proportions.

Picture a high stakes situation like say, a resistance member in the Russian occupied parts of Ukraine. Yeah, the Russians can't see what you're emailing about, but they can see that 3 people of a given village are sending encrypted messages to each other, and then there's some outside contacts. Gee, what might they be talking about? What conclusions should we make if somebody else also sends mail to this outside contact.

Yeah, the encryption might be strong, but it won't do much to protect those people against the $5 wrench.

GPG for email only works in extremely narrow scenarios, and that makes it a bad tool.


Which communication methods leak no metadata?

If two people are communicating, the message always needs to know where it's going and in most cases where it's coming from.

Not encrypting the email subject is an implementation detail really.


> Which communication methods leak no metadata?

All leak something, but there are differences in what and how much.

> If two people are communicating, the message always needs to know where it's going and in most cases where it's coming from.

Yes, but in this case it'd be actually better to use something like Signal. You want something that's plausibly used often, is always encrypted, and is used for random chit-chat all the time, so that it's hard to tell if anything odd is going on from the outside.

GPG just screams "an important conversation is happening"

> Not encrypting the email subject is an implementation detail really.

And it's still unfixed, despite being a serious problem (it's easy to slip up and put something interesting in the subject).


> GPG just screams "an important conversation is happening"

is just another argument in favour of all email being encrypted.

And yes, there's side-channel/metadata still in the clear, and that's a problem, but still a smaller problem. The only crowd I know working on solutions to minimise/eliminate that problem is the Cwtch project (not product!)


> is just another argument in favour of all email being encrypted.

And that makes GPG unsuitable, because it's such a pain in multiple ways.

> And yes, there's side-channel/metadata still in the clear, and that's a problem, but still a smaller problem.

Absolutely not a "smaller problem". Using GPG in an actually serious scenario like in occupied parts of Ukraine is quite likely to get you imprisoned, tortured, killed or all 3.

GPG mail is only suitable for "polite society" -- situations where your only problem is to securely email documents and account numbers to your accountant, and nothing else.

And that's actually a very narrow application. It's trivial to run into situations where that becomes extremely inadequate.


Sure, but sometimes we don't care about knowing who is communicating. For example:

I don't care if someone knows my bank sent me a message, but I want the content of the message to be secure (not just in transit, but also at rest)

I don't care if someone knows my primary care physician sent me a message, but I want my lab results to be secure.

I don't care if someone knows I communicated with my CPA, but I want my tax and receipts to be secure.


True, but that's incredibly user unfriendly. The average person isn't good at doing that level of risk evaluation. What's important and what not isn't intuitive.

And we have a much friendlier than GPG system for that: putting that on a website protected by HTTPS.


But that puts all the data on a 3rd party site where I _might_ be able to make a copy of it for myself. It is annoying to get an email from my bank about an "important message", and instead of just sending me the message, I now have to go to the bank's app to read it. Oh, and it disappears after 30 days, so I have no way to archive it or look back on important messages from a year ago.

A government system could easily implement s/mime transparently for all emails sent within that system (meaning any other government agency or registered providers).


> Which communication methods leak no metadata?

> If two people are communicating, the message always needs to know where it's going and in most cases where it's coming from

Sure, but you can still do a lot of things to make it much, much harder for the same Carol to identify Alice and Bob.

SimpleX is a good example of how far you can go and how many obstacles you can pile up onto the same protocol:

https://simplex.chat/#how-simplex-works

https://simplex.chat/#privacy


IMO the privacy we might discuss in terms of government or community intrusion is different from the privacy you expect from friends with regards to discretion. If I send you an unprofessional email, it ought be your prerogative to make a judgment call for disclosure.


You can always have your password in a password manager with emergency access, if you (not you god forbidden) die, someone close can access all these domains/emails.


The problem is that someone has to squat your domain for you for as long as want to prevent an adversary from registering your domain and intercepting any emails still being delivered to it.


I can stop them from being mad as much as I can stop them from writing those mails, I'm dead.


I'm amused, that sometimes when you begin starting to learn something, you see resources for learning everywhere. (And I just learned it's called Fequency Illusion or baader-meinhof-phenomenon [0])

Thank you so much for publishing this book for free, I'm eager to dive in! Is there any chance you can also link it as ePub?

[0]: https://en.wikipedia.org/wiki/Frequency_illusion


I'm not the author, just sharing it here.

Ebook link is mentioned on the home page:

>This book is also available for purchase in ePub, MOBI, and PDF format from https://leanpub.com/how-query-engines-work


Youtube's algorithm really helps in that regard. I search some flight training videos for a day and then just get flooded with more and more (which is nice!).


The Superconductor would also store the Energy. It could instantly release and take in energy. So this would also be the battery


> It could instantly release and take in energy.

In that case, can it be used to create new type of explosives?


There's also a very nice simulation, where you can play with the very different parts of vocal chords:

https://imaginary.github.io/pink-trombone/


I made a fork with few more features, it might even work on your phone browser:

https://jmiskovic.github.io/voicebox


Thank you for this. I had a lot of fun scaring my cat in bed and it inspired me to become a late middle aged opera savant.


I actually am a late middle-aged opera savant but sadly I have no cat to scare


Unfortunately this webapp (along with the original Pink Trombone) produces super glitchy audio and consumes 95% of CPU on my Chrome v114.0.5735.198 running on Ubuntu 22.04 (which is running on my Thinkpad X220)


That's rather strange. The graphics part is lightweight (pre-rendering the background and then drawing few shapes), but if you could shrink the browser to very small dimensions and test we could eliminate this one.

The audio part is bit more involved. The vocal tract is simulated in segments, each segment receiving, filtering and reflecting the soundwave energy. The algorithm is computationally heavy, but it ran well on my mediocre smartphone.

Maybe if stuttering is detected it could lower the number of tract segments, which also lowers the quality. Increasing the buffer size would probably also help with glitches but I don't think it would solve the high CPU utilization.


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

Search: