joosters

Now when you say 'but it's only going to be used by the sex industry', you're adding another area of high fraud on top. It's hardly surprising that financial companies want nothing to do with two high-risk sectors sandwiched on top of each other.

Wifi isn't practical for all use cases either.

Very kind of them to offer the freedom of choice to all those users who don't want to protect themselves!

Unfortunately, the profitable use of AI will be to do the exact reverse...

"ChatGPT, generate a how-to video by ripping off the content from https://pierre-couy.dev/tinkering/2023/03/turning-rpi-into-e... - and don't forget to insert adverts for three different VPN providers in there too"

Please try not to paint everyone with your own colonial-era assumptions.

To make matters worse, this means that the camera defaults to the microphone being disabled, and you need to download their proprietary software to enable it. Which is Windows-only. I've got a mac. So I ended up having to install Windows in a VM just to let me enable the microphone on my webcam. (Fortunately the setting is persistent and you only need the VM once)

I think the auto light settings on the camera need the Windows software too, it's a remarkably bad camera. Avoid!

Execs just feel like they need to retreat to the safety of euphemisms in these kind of announcements, after first boasting about how well the company is doing, of course.

That's just a truism, regardless of the stablecoin or the state that it's in. No-one should ever expect a $1 stablecoin to trade significantly higher than $1, since the creators of the coin can easily arb the difference to pocket some free money.

(Yes, this is a gross over-simplification)

[edit: I might be too harsh, I'm reading through the archive.ph link and maybe that is dropping some of the images?]

"Acceptable variants include:

- The letter c with a parenthesis over the top

- The letter c with a parenthesis under the bottom

- (c

- c)

- (c)

- The letter c with an unenclosed circle around it."

That sounds like there was some kind of dispute once about a hand-written © where the writer didn't complete the circle, and the copyright office is covering all bases here!

Interesting that [c] is not acceptable.

It sounds ... plausible? But I've never heard of any legal case that ever covered this. Is it a myth?

Kraken can't pretend to unstake customers' ETH and stop paying rewards because they have no way of returning the underlying coins to them.

I don't know whether it's true or not, but I remember a chemistry lecturer telling me that you don't need to worry about terrible smells in the lab, our noses are sensitive to extremely miniscule levels of chemicals. It's when the levels are so high that they have overpowered our senses and knocked out our sense of smell, that's when you need to worry! A wonderfully paradoxical piece of advice...

While it is probably a bug, it's probably not a serious one that many people would run into nowadays. Now that https is ubiquitous, there aren't many caching proxies around to cause grief. Probably the only proxies people will experience are where they are behind a paranoid company's firewall, one that is configured to decrypt (and then re-encrypt) all their web traffic. And in those situations, they don't tend to do caching much now. (Because even though you can cache HTTP, you'll hit problems with misconfigured sites and users will blame your proxy for it.)

But programmatically, how do you advertise alternate representations? I'm not sure. Suggestions appreciated.

Sorry, I don't have a good answer for this. I only nit-pick problems in web comments :)

You could set a HTTP header to list the available variants, but there isn't a standard AFAIK so it would only help developers who spotted the header.

But the other thing is that the HTTP client you use could decide to change it's default Accept header. If curl changed to "application/json,q=0.9;/" then suddenly you'd get json (I didn't mention in the blog post but that is also implemented)!

That's cool! Aeons ago, I was involved in developing a web server, where we added support for properly handling all kinds of content negotiation (Accept-Encoding, Accept-Language, etc), where you could configure it to deliver the right file based on the user's language, file type preference, etc. It was a large chunk of code, but in the end, nobody really used it. In theory, web browsers and sites could co-operate to deliver the right page in the right language for all their users automatically. In practice though, it never works. No-one sets up their web browser to pick the language properly (who even knows how to change it?) As a result, multi-lingual sites offer to switch languages by clicking on a link, and if they choose a default language, they mostly do it based on IP address (and assumed location)

That's my main usability case and I wanted that to be as smooth as possible.

I think it's the right choice for csvbase, my original comment reads far too critical in retrospect, it's neat that if you curl a URL, you get the csv. But if I was writing code to scrape some csv data, I would still always prefer to download URLs with a .csv extension, because you know what you are getting 100% of the time, and you avoid any unpleasant surprises if some 3rd-party library or tool changes its behaviour.

A 'Vary: accept' response header gives a hint that it could have supplied a different response had you given a different Accept: header. But I don't think that there's a way to actually list the variants available in the HTTP spec?

My reading of the HTTP spec suggests that csvbase.com is behaving incorrectly by not setting the Vary header properly (it sends: 'Vary: Accept-Encoding', but it should also list 'Accept' in there too). Potentially, a proxy server could decide to cache the CSV or HTML response, and then serve that version back to another client instead of the 'right' one, because the server didn't correctly report that the response varies based upon 'Accept'. In practice, this isn't likely to happen unless you've got a caching proxy that is also unwrapping the encryption between itself and your HTTP client.

1) The discovery of the different response formats. How do I know that I can get csv files from that URL, other than by hoping that the website documents this somewhere?

There's nothing in the underlying HTTP response from https://csvbase.com/meripaterson/stock-exchanges that tells me I can get an HTML or CSV version. Is there a JSON version available? What other variants exist? How do I know that this URL will deliver different responses?

2) Will the website always default to csv files or will my app break when they decide that XML is superior? (Well, obviously not, especially for a site called csvbase!)

But if your program expects CSV data, it is probably best to always request that, and a URL that ends in .csv gives you far more certainty that the data is going to be in that format.

Have you really launched a website, or just started one? Since the same article rejects the use of 'drive' and 'land', I'd say that 'launch' is fairly comparable.

My one gripe with Youtube's own transcript box is that it is too narrow, so it is a shame that a website designed to specifically make the transcripts more readable also displays the transcripts in a narrow box.

Even if Changpeng Zhao owns the majority of binance.com, the coins might be held by some other legally-distinct entity.