There might be multiple methods and heuristics, but one way that I have encountered was based on packet TTL.
Android and Linux use 64 by default - the block could be circumvented by setting the laptop to use 65 TTL.
HN user
There might be multiple methods and heuristics, but one way that I have encountered was based on packet TTL.
Android and Linux use 64 by default - the block could be circumvented by setting the laptop to use 65 TTL.
What do you think the minimum pad clearance is for the clay?
You can dead bug an LQFP if you absolutely have to…
This assumption has unfortunately led to countless security issues, at least in the past. The nosniff header (see https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/...), was created because of this and should be added.
While this probably works, you should also add a restrictive CSP (using the sandbox directive).
Forcing the download (via Content-Disposition header) would likely be even better, but it is annoying for users.
It's still available, just hidden in the search tools.
Not sure what you're getting at, apart from the loss the same disadvantages also apply if the cable is superconducting.
Even worse, maintenance and running costs of superconducting cables are likely much higher due to the cooling (high temperature superconductors are "high temperature" in comparison to other superconductors - there's still lots of cooling needed).
That would be a best case scenario and I doubt that's what's happening.
And instead of bringing those services back locally, nearshoring will probably be considered first.
Obviously they're fucked. Luckily we are still in the hardware design phase, otherwise we'd be even more pissed.
I don't think anyone built a product with enough volume that Intel would reconsider the discontinuation.
Long-term component availability is a major issue for hardware products. Discontinuing a product basically over-night is not a nice move from Intel and I hope people will remember this when Intel launches their next IoT/robotics product.
There are virustotal clones that don't send back results to the vendors. This is specifically done to prevent that kind of problem.
Same here, no problems anymore for more than two weeks now.
You cannot skip FCC certification, you can just go through the "simpler" unintentional radiator testing when using pre-certified modules. That's still around 1.5k USD.
Also you can't use custom firmware on a pre-certified module, otherwise you'll still have to do the intentional radiator testing. You control those modules with an external MCU, which is cheap though.
TIs WiFi offering is horribly expensive compared to any ESP8266 based modules, still like 13$ @ 1k units on DigiKey. That's the main reason the latter got so famous.
You need to sell a few hundreds just to get those fixed costs down to a reasonable amount per unit. And then you still have to pay the engineers... Maybe 80-100$ per unit would be more appropriate, but then again I doubt they sell in huge numbers.
I agree it's overpriced.
However don't forget that when selling a product, lots of other costs arise. E.g. you'd need FCC certification (around 10k USD for intentional radiators) and make sure that no other standards are violated (mainly regarding mains voltage). The plastic case mold is another 3-5k. Then some margin for returns, marketing, etc.. It's a niche product, so the fixed costs make up a big part.
If it's popular someone will sell a simple DIY kit for 20$ and an open-source server. But I doubt there's much demand.
I doubt their "signal processing" involves anything more than a microphone and a peak detector.
A more practical side channel attack would probably be through radiated emissions over the mains power. However if you're willing to go that far, a laser microphone is much more effective and simpler.
Don't worry, they thought about that:
Guests' privacy is always protected. Our patent pending technology ensures that no content is recorded
It's patented, so it must be good.
Sarcasm aside, I really wonder what's in that patent... I mean it must (should) exist, otherwise it should be "pending".
Just checked again, we're still seeing issues. I can reproduce, simply by using my personal account in a private window, it randomly fails in at least one of our environments (e.g. prod, staging, localhost).
Ah yes, of course. I did miss that. The implicit (client-side) auth flow gets the access token directly and doesn't need another request to the API, that's the whole point.
This is indeed rather unwanted, even more so with the new more restrictive API usage policy and the sandbox.
It doesn't seem too bad when enforcing https (using the return address whitelisting in the developer console). Am I missing something?
Sorry, but this is definitely not a hardware, connection or session issue. Just check the rest of the thread. We're seeing issues over various links (broadband, mobile, datacenter) on different server locations (AWS vs. on dev machine) with or without private mode / logging out and then in.
I honestly wish it was something like this, at least then we could fix it.
The double POST requests you see is most probably because api.instagram.com returns a 302 response ("Found", i.e. redirect). This is a relatively recent change, but still weeks before those issues started.
By the way, your server refuses connection when you go to https://picodash.com directly (without www.). You might want to fix this.
Private mode wasn't enough to fix the error for us.
At least not in all cases, i.e. we tried production, staging and an instance running on localhost. Private mode usually changed in which places the login worked, but it never helped for all three.
Unfortunately we're seeing issues again. So it really didn't help or the effects have weared off by now.
It's a bit frustrating with no reaction from Instagram/Facebook and not even an entry on the status page.
Pretty much our experience. We didn't figure out what caused it, the same Instagram account sometimes works and sometimes doesn't without a change in code on different instances.
Apparently it happens from time to time, there are some posts about this problem on StackOverflow. No answers though.
We tried many things, including resetting our secret. It's working now, but it's hard to tell whether our actions had any effect.
Currently I'm seeing a lot of 400 errors: "Matching code was not found or was already used."
unless you use a adblocker that blocks analytics as well
Who on Hacker News doesn't? At least on the desktop (where you use brew) this is a matter of a few clicks and an essential security measure.
I would use Stripe, just because I trust them way more than PayPal and the conditions are slightly better. There's Stripe Checkout (https://stripe.com/docs/checkout/tutorial), it's not much more effort than a PayPal button (unless you're using it like a donate button).
Whether it looks professional or not depends on your clientele. If your service is good, whether you're using Stripe or PayPal doesn't matter. I'll need some convincing to put my card details into forms from other providers though.
I was finally able to try it out and this is exactly my observation too.
I've got a very similar score of 0.323 for an Angular SPA with a bunch of dependencies (1,276 kB, 44 requests) that basically shows 5 jpeg images.
Would be interesting to see the result when using JPEG instead of PNG. However it's still easy to gamble, just display some large JPEG images in full size and the score will approach 1.
Edit: By the way, here's a working screenshot link for the score above (image size 3,947 kB): http://www.webbloatscore.com/Screenshots/aeea9b6a-4852-4b01-... They screenshot the whole page.
In the same vein, Tesla offers unlimited free supercharging for its vehicles. This is a generous offer, that only works under the assumption that people use it responsibly. It would be quite unfair if someone ran his commercial fleet with it.
Of course this is easy to fix, but it would still result in either forbidding commercial use (without license) or metered supercharging.
It's a cool project and the list is already quite good. However I have some remarks.
First of all I find the UI a bit confusing. Especially the plain number fields, it's not obvious that they mean "at least this value".
The are some funds missing from the list. For example try Direxion funds, without any other filters the list shows 25 results. You're missing all their "bear" funds and some more - just their 3x leveraged offering has more than 25 funds. Check their website: http://www.direxioninvestments.com/
The filtering is a bit weak too. Expense ratio, how they pay dividend, etc. is important too. Also I'd like to select multiple currencies at the same time. YTD and custom date period performance would be nice.
You're missing the link. I'm very interested to give your filters a try.
There are hundreds if not thousands of different investment funds, you can't really list all of them. It's important to know where you got the data from, otherwise it's unclear what might be missing.
Sure, that's what you could do if you really wanted to know.
It's not really a "refreshing" experience though - their main selling point.
I agree with that. I have an alias for "git pull --ff-only", which I use often though.
It's faster than manually doing the fetch and then merge/rebase. If it succeeds you're at the newest version, if not you can still decide whether to merge or rebase. This should be the default behavior for git pull in my opinion.
Those two go hand in hand. You can't increase area arbitrarily. The more area your chip has, the less yield you get, which in turn makes it uneconomical to produce.
The reason is simple, even a single manufacturing fault can make a chip unusable. If you assume e.g. a fixed number of faults per wafer, you can easily see how increasing the chip area increases the area you have to throw away for every fault.
As you wrote, the semiconductor business is very capital intensive, so no one can afford to do that (except for some niche applications, like R&D, space, etc.).