They didn't really do a very good job of selecting marketing examples. The only good one, that shows off creative possibilities, is the knit elephant. Everything else looks like the results of a (granted fairly advanced) search through a catalog of stock footage.
Even search, in and of itself, is incredibly amazing but fairly commoditized at this point. They should've highlighted more unique footage.
An interesting problem for those who're good at e.g., geometric packing problems and space-filling curves.
I wonder about having an optional fill mode with more of a sphere-packing approach. I.e., instead of layering long threads of filament, what if you put down a bunch of dollop-drops in a checkerboard pattern and then staggered successive layers of dollops to fill the gaps?
Prior to computer-generated 3D animation, I can imagine it was very difficult to float and spin vector-arrows in mid-air with enough accuracy to show what goes on without having to resort to reams of explanatory paragraphs.
Eugene Khutoryansky is something of a lesser-known 3b1b that's more focused on physics than math. I found his animations very helpful for building intuition around Maxwell's equations:
Rust allows for higher stakes in terms of risk/reward while guaranteeing many aspects of safety. I'm not sure for this case if the scheduler would benefit from more complex/risky structures but if it did, that'd be a valid example of Rust making things "easier".
Rust definitely makes some easy things more difficult but on the flip side it arguably makes very difficult things easier (to get right with fewer guinea pigs).
When I use the word 'Simple' in e.g., a class name, I usually mean: ~"This is meant to cover the 80% of common cases--I haven't done extensive testing or development on it. If you need to cover something in the remaining 20% of edge and corner cases, you're going to need to write your own more complex code to handle those."
I.e., my code is simple--and that might make your usage complex.
Of course, things can evolve from the original implementation--especially if the code is maintained by a team. What was once 'simple' (from any perspective) can become terribly appendaged yet never renamed.
I think one part of the trick is that you find high-functioning people but in less-overlapping domains.
In one of the more successful teams I was on back in the day, I was a JavaScript developer and was paired with some Flash developers on a project where we had a lot of back and forth calls crossing the boundary. I'd ask them to implement a way for me to call their logic and then they'd ask me for a way to call my logic. We were both super-responsive to the other because neither side had much interest in imposing our preferences in the other's very distinct domain.
On the flip side, we were both quite capable in our own right and thus able to agree on the overall architecture pretty quickly. With some people, you'd probe, "it seems like you should have a way to do X, right?" and they'd respond immediately, "that's definitely not possible, you'll have to work around that". So you'd push, "do you want to check?" but they'd decline so you'd take it upon yourself to dig in and point them to relevant documentation. With these guys, their response to the first question was, "Of course we can do that and you can do Y for us, right?".
It's group of people A, who are conducting a [series of] transaction(s) with group of people B. It so happens that the wares being exchanged are currency vs. software but that's really besides the point.
Yep. The primary fault lies with the too-many people who abused the non-hostile system. "This is why we can't have nice things"--because trust is too costly in the societies where hostile architecture is prevalent.
It happens all the time, no tech required, any time someone is foreclosed on.
I agree it's wiser to avoid such situations but a lot of people end up delegating this kind of responsibility. If enough of them end up burning their own fingers, that could go badly for a provider. Even if frivolous lawsuits weren't a thing, a spate of ignorant but angry social media posts could be very damaging.
Again, I'm not saying I necessarily have a solution or that hardware owners should have hurdles placed in their way. I'm just pointing out that in some ways the provider may be damned in one way if they do and damned in another way if they don't.
I suppose the IoT sub-sector will end up in similar proportions to other, older tech: Some vendors, analogous to e.g., Red Hat or Linode, will specialize in catering to enthusiasts / power-users and have fairly noncommittal / at-your-own-risk / no-warranty license agreements. However, if the past is any indication, most people will end up doing a lot of business in walled-garden analogs of Apple or Facebook.
My favorite is being asked to estimate a bug fix before I've had any chance to analyze the issue.
It's like calling a mechanic over the phone and asking how much it will take to fix your car. The mechanic doesn't know if the engine just fell out of your Model T or if you're just trying to put the key in backwards. How about you bring it in first, then we'll look it over and go from there?
Sometimes you can ask some questions and get to, "Well it's probably X which would take Y but we'll need to see". Then they get Y stuck in their head and it turns out to be the one time out of twenty when the cause isn't actually X but something much more involved.
That makes sense to me but I'm not sure your average judge/juror would see it so simply--especially given that in most cases it'd be a lot easier to tell if/when a deadbolt has been modified.
I'm not saying owners should be completely barred from modifying their systems but there are security implications to bypassing their centralized / cloud-based authentication.
It'd be possible for a knows-enough-to-be-dangerous customer to modify their system in such a way that they unwittingly allow unauthenticated local access. From my point of view, Chamberlain/MyQ should be totally indemnified in such scenarios but I'm not sure how murky the legalities would be in terms of getting judges/juries to accept "caveat emptor".
EDIT: Maybe there's a way to ensure customers have signed an indemnification agreement before unlocking local API access? I guess there'd also need to be a way to ensure/promote a factory reset if/when ownership/rentalship changes.
That dovetails nicely with: “It is difficult to get a man to understand something, when his salary depends on his not understanding it.” --Upton Sinclair
Was actually thinking, once you've integrated it with a CI action and cheap static web host, this replaces Confluence in many ways. Looks like the basic editor is and will remain free.
This could be a pretty great approach. What should be especially nice is being able to blend automatically-generated documentation and e.g., automated testing reports, etc. in the same host/site as more manually curated documentation.
Maybe this would also solve the other problem with Confluence--that people end up using it as a junk drawer. DO NOT PILE YOUR TRANSIENT MEETING NOTES IN THE SAME SPACE AS YOUR TECHNICAL DOCUMENTATION PEOPLE. It fills the search index with noise and makes it impossible to find any information except the stuff that was only relevant for the two days after it was written three years ago.
On that note, it seems like the primary downside of this is that you don't get search indexing at all unless you also configure and integrate something like OpenSearch.
Spend a couple hours recording a joke song on your phone that happens to become a viral hit? Ten years of monopolizing it seems more than fair.
Spend millions of dollars hiring a research team and running gene sequencers for years to develop a state of the art drug? Maybe 10 years isn't enough.
Give it a minute to load the JS, and then you'll get a dialog for each icon/character you click. My favorite part was using XSLT over the original SVG data to generate black and white "coloring sheets". Most of them turned out pretty decent. E.g., https://stime.tech/emoji-explorer/assets/coloring/emoji-snai...
I'm not sure if it'd be necessary/useful but it might also be interesting to leverage zero-knowledge proofs so that interested parties could verify when the contents of a disclosure were made available without actually accessing the contents until after some attempts at remediation.
I like the general idea of improving communication / transparency.
Perhaps some branch of the government could provide a registry for responsible disclosure (e.g., `https://some-branch.gov/responsible-disclosure`). As a security researcher, you could notify the government of your intent to disclose as a demonstration of due diligence and good faith.
The registry/site could return a case/reference number that could be included with the disclosure to the manufacturer. In addition to discouraging an attitude of defensive reprisal, it might also prevail a greater sense of urgency upon the manufacturer to follow through with remediations.
Instead of trying to compel manufacturers, who may no longer even exist, to support their old products; perhaps the government should focus on protecting consumers and aftermarket vendors who update / modify / reverse-engineer older revisions--especially after they're no longer meaningfully supported by the manufacturer.
Even search, in and of itself, is incredibly amazing but fairly commoditized at this point. They should've highlighted more unique footage.