149 karma · joined April 25, 2014
I see this all the time with VPNs. By having everything behind the company VPN, application security isn't taken as seriously. As a result, lateral access becomes trivial at these companies.
Keeping everything public internet exposed from the start actually results in better security.
This gives you a key benefit of protobuf, without needing external schema files: you don't have to pay the space of the keys of your data.
This is simply not something you can do with JSON, and depending on your data can yield substantial space savings.
The maintenance burden for Stack cannot have been significant, and yet I guess I am unsurprised to see Google add another good app to their graveyard.
What do others use for this purpose?
My approach with my kids has been to use antibiotics only if there's no progression (better or worse). I figure as long as it appears the immune system is doing its job, that's enough for most cases.
So far, we've given our 3-year antibiotics on two occasions. Once for an ear infection that wouldn't clear and for when he had pneumonia.
Specifically, we noticed lack of support for these features:
- session trunking (and, in general, multiple channels)
- multiple concurrent requests on a channel (ala ca_maxrequests)
- callbacks
ca_maxoperations was quite low (10, I think?), and they limit the number of parallel clients that you can access EFS with at once.
What this amounts to is that you can reach acceptable performance on file reads/writes, but metadata heavy access patterns have no hope of reaching the advertised IOPs. It's a shame because frankly metadata performance is something NFSv4 excels at.
Is this limited to their higher end models?
There's nothing wrong with fixing a bug you discover upon inspection. Forcing tickets for every change discourages code maintenance.
Incredible.
1. As you suggest, there's no equivalent to the `select` mechanism. To perform the equivalent, you must busy loop and call `csp_chan_try_pop`.
2. It appears you cannot nest coroutines.
3. The mutex implementation does not provide an RWMutex.
4. `csp_yield` seems somewhat necessary for practical applications.
Normally I would not use another language as a basis for comparison to a C library, but that's precisely what the author of Libcsp appears to be aiming for.
All that said, there's a really slick implementation of a lock free RB queue backing this library, and It's a neat project. I think it would stand on its own better than as a "go style in C" library.
The only time I ever find myself using the !g escape hatch is when I'm searching something brand new (e.g. a breaking news story). Duckduckgo has a recency filter but it seems to take them a few days to ingest the content.
For the rest though, it may be worth pointing out that the first $100,000 in qualified stock options _per year_ are not taxed. If you're in a situation where the taxes on $(your annual options) - $100,000 are significant in comparison to your rent, I'd wager you're doing pretty well.
I think the decision was wise - it prevents user code from relying on ordered iteration behavior, which allows the go team to switch to different map implementations without fear of breaking user code.
If the order had been unspecified, but iteration was still ordered in practice, there'd undoubtedly be (incorrect) user code that relied on that behavior.
Amusingly, I now run into engineers who are under the misconception that map iteration is random, and proceed to use maps as an RNG. That's an unfortunate mistake because Go's map iteration is quite non-uniform - it's shuffled just enough to appear random to the untrained eye, while be performant.
After all of that, you look at your coworkers' code and realize they either (1) picked a different subset than you did, or (2) PHP is their first language and they have no idea what they're doing.
I mostly stay away from web development now, but if I were to do a new web project, I might still choose PHP if I knew I'd be working with a small, experienced team. It's a highly productive language.
Modern chess engines usually have a notion of "contempt". I've found that if you turn contempt way up and limit the number of concurrent lines, in combination with adjusting the target rating, you can get a reasonably good approximation of real play. At casual (< 2100 maybe?) levels of play, this simulates the human tendency to make blunders while fixating on a plan.
The last sentence in the recommendation emphasizes this: use them with scrutiny.