HN user
Well actually...
We're doing a pretty good job of making it a lot less common: https://www.unep.org/news-and-stories/story/problem-our-dwin...
There's even such a thing as Sand Theft: https://en.wikipedia.org/wiki/Sand_theft
When claiming copyright, you should mention the date of first publication and if applicable, the last significant revision. Not the current date.
These are the settings you're looking for:
* PrivacySandboxAdMeasurementEnabled
* PrivacySandboxAdTopicsEnabled
* PrivacySandboxPromptEnabled
* PrivacySandboxSiteEnabledAdsEnabled
Sent you an email!
Thanks for the suggestion! Unfortunately, all their "on call" features are coming soon, so it doesn't seem like a PagerDuty alternative just yet.
A lot of off-the-shelf consumer smart home products do suffer from the drawbacks you've listed, but they do not generally apply to the smart home concept. My home is automated using components that use the KNX standard, and although the initial investment is higher than a conventional electrical installation, I'd argue maintenance is actually simpler and cheaper – as pretty much all of it is in the software.
Additionally, there's quite a few benefits: - It's all wired, so it's been rock solid; - It's vendor agnostic; - It's entirely local, so there's no subscriptions or even an internet connection dependency; - There's a ton of gateways available that allow me to interface with non-KNX products;
Overall, I'm pretty happy with it. It is just a matter of convenience however, it's hardly a must-have.
Ubiquiti has a doorbell in their UniFi range. No cloud required. Not that interesting unless you're looking to use the other UniFi products as well though, as it's a bit of an investment to get into that ecosystem.
Quite happy with Backblaze for exactly this reason, as it allows you to set your own private encryption key.
That they're quite reasonably priced doesn't hurt either :)
Signal jamming will trigger high-end car alarms as well.
Also, if the alarm is connected to a security provider, a disruption in communication with the car will also cause them to follow up on it.
For us nerds who want to effect change, and who are convinced data should be all you need, the book "Switch: How to Change Things When Change Is Hard" by Chip and Dan Heath is a highly recommended read. It'll tell you all about the story, or as they call it: the elephant.
NI's products such as the S8, D2, F1 and X1 are mostly targeted at DJs playing electronic music, particularly house and techno. Genres where there's a lot of room for live experimentation with many different layers, due to the easily quantisable nature of the music. I doubt they had Stevie Wonder and Metallica in mind while developing this ;)
For production purposes you'd probably want a lossless file format anyway.
Most tracks can be split up into four distinct components: drums, bass, melody, and vocals. Of course, they could have taken it a step further, by splitting a track up into its individual instruments, but I doubt that would be very usable in a live performance setting (although some performers actually do go this route, usually relying on software such as Ableton Live for this purpose).
The four channels are also quite similar to the EQ section of a DJ mixer which generally controls three frequency ranges (low, mid and high). EQ-ing is heavily used to mix songs together, so by sticking to a similar interface, DJ's can easily pick up this format.
You're violating SoundCloud's terms of use:
(i) You must not copy, rip or capture, or attempt to copy, rip or capture,
any audio Content from the Platform or any part of the Platform,
other than by means of download in circumstances where the relevant
Uploader has elected to permit downloads of the relevant item of Content.
Ah, my bad, I misunderstood. Thanks for clarifying!
Let me clarify, by non-HTTP I mean "not defined in the HTTP/1.1: Semantics and Content RFC" (RFC7231) and therefor not likely to be commonly implemented.
Could you elaborate on what you consider to be "bad REST" with regards to using POST in this case? The RFC clearly leaves the definition of the semantics of POST up to the implementation of that particular resource.
The only argument I could come up with, is that POST is not guaranteed to be idempotent or safe, whereas a search query would be. But a lack of guarantee doesn't exclude use cases where it would be.
I believe they're right in using POST, and here's why:
- Using GET with a request body:
Per RFC 7231, Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content, section 4.3.1 [1]: "A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request."
Although you can argue whether or not you should be able to define the semantics of such a request body within the context of the resource, it quickly becomes moot in the face of reality: there's a good chance it won't work due to whatever client or intermediary is involved.
- Using non-HTTP verbs (i.e. REPORT, SEARCH):
Again, one can argue over their validity, but since most clients or intermediaries will not support them, there's little practical use. In this particular case, I'd recommend against them since most developers will not be familiar with them, making your API less user friendly.
- Using POST:
Per RFC 7231, Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content, section 4.3.3 [2]: "The POST method requests that the target resource process the representation enclosed in the request according to the resource's own specific semantics."
In other words, do whatever you want – such as executing a search query contained within the request body. This is semantically valid, widely supported and common practice. The only downside would be that caching of POST requests is not widely supported, although still possible. The spec even suggests an alternative solution: "Responses to POST requests are only cacheable when they include explicit freshness information (see Section 4.2.1 of RFC7234). However, POST caching is not widely implemented. For cases where an origin server wishes the client to be able to cache the result of a POST in a way that can be reused by a later GET, the origin server MAY send a 200 (OK) response containing the result and a Content-Location header field that has the same value as the POST's effective request URI (Section 3.1.4.2)."
In other words, you can implement a caching mechanism for your query resource that exposes itself through a URL structure, available for GET requests.
As long as it's just a better product, there will always be those willing to pay a little more. Even if the product is part for part the same as a competitor's, better customer service might still warrant a premium price. Not having to go through the hassle of dealing with a horrible RMA process for example, is worth the extra money to me.
The nice thing about customer service, is that its monetary value is very hard to quantify, making objective comparison difficult. So there's always room to charge extra.
Good to see they're taking the resiliency issues as those pointed out by Aphyr in his Call me maybe series (http://aphyr.com/posts/317-call-me-maybe-elasticsearch) seriously.