cosmie

This[1] may help.

What you're saying is true, but it's generally using either the API remoting or device emulation methods mentioned on that wiki page. In those cases, the VM does not see your actual GPU device, but emulated device provided by the VM software. I'm running Windows within Parallels on a Mac, and here[2] is a screenshot showing the different devices each sees.

In the general case, the multiplexing is all software based. The guest VM talks to the an emulated GPU, the virtualized device driver then passes those to the hypervisor/host, which then generates equivalent calls on to the GPU, then back up the chain. So while you're still ultimately using the GPU, the software-based indirection introduces a performance penalty and potential bottleneck. And you're also limited to the cross-section of capabilities exposed by your virtualized GPU driver, hypervisor system, and the driver being used by that hypervisor (or host OS, for Type 2 hypervisors). The table under API remoting shows just how varied 3D acceleration support is across different hypervisors.

As an alternative to that, you can use fixed passthrough to directly expose your physical GPU to the VM. This lets you tap into the full capabilities of the GPU (or other PCI device), and achieves near native performance. The graphics calls you make in the VM now go directly to the GPU, cutting out game of telephone that emulated devices play. Assuming, of course, your video card drivers aren't actively trying to block you from running within a VM[3].

The problem is that when a device is assigned to a guest VM in this manner, that VM gets exclusive access to it. Even the host OS can't use it while its assigned to the guest.

This article is about the fourth option – mediated passthrough. The vGPU functionality enables the graphics card to expose itself as multiple logical interfaces. So every VM gets its own logical interface to the GPU and send calls directly to the physical GPU like it does in normal passthrough mode, and the hardware handles the multiplexing aspect instead of the host/hypervisor worrying about it. Which gives you the best of both worlds.

[1] https://en.wikipedia.org/wiki/GPU_virtualization

[2] https://imgur.com/VMAGs5D

[3] https://wiki.archlinux.org/index.php/PCI_passthrough_via_OVM...

I've executed my own email programs for small projects before, and had the same reaction when I started working at an agency and saw how much we charged for that type of work.

Interestingly enough, it's actually not as padded as it seems. While the update itself may only take an hour or so of time, there's a few hours of communication/procedural overhead baked into these things:

- Receive a project brief - Align with client on the contents of the brief - Provide estimate and get sign off (potentially before the brief, if this is repeat work for an existing client) - Do actual work - Client review of work - Revisions. Usually incredibly minor nitpicking, but virtually always requested. - Final client review and acceptance

Whether the work takes 30 minutes or 30 hours, that procedural overhead is standard in BigCo marketing departments, and creates a price floor of about $500 since even the tiniest requests end up taking several hours of total effort (communication/procedural stuff + actual work). If you're engaging an agency instead of a freelancer, that floor jumps to about $1,000 as the entire process gets facilitated by an account manager + PM, so you have to add in a couple hours of their time as well for the procedural/communication overhead.

---

Not to say that's a particularly efficient process, or that it should be that way. But figured I'd share that perspective, since I initially reacted the same way you did when I saw those estimates for stuff that should have taken a trivially small amount of time to accomplish.

> Still much underappreciated and I think underestimated technology by CF. Very hyped..

I think much of Cloudflare's capabilities are underappreciated and underestimated.

I do analytics work for an agency, and had one multi-national client that had their sites behind a traditional "bigco" networking stack such as F5 load balancers, Imperva web application firewalls, etc. Due to the particular setup they had for one site, third party scripts loading on the site (not tracking scripts, but libraries from third party services providing user-visible functionality on the site).

The setup also completely broke any sort of analytics scripts as well, due to the way traffic was intercepted/analyzed by the web application firewall.

This had been the state of things for years before I came on, because it simply wasn't resolvable within the constraints of their enterprise networking policies and infrastructure. Cloudflare web workers had just come out, and I was able to hash out a proof of concept that

1) Left all of the pre-existing legacy networking infrastructure as-is without undermining the intent behind any of it, and therefore required minimal internal red tape nor one-off exceptions. While

2) Handling all of the jankiness introduced by it within the web worker itself, ultimately serving a "proper" response to the client that completely mitigated all of the issues that had been introduced.

It fixed the analytics stuff that was my headache, and made me happy. It fixed the constant breakage on other stuff, which made the devs happy. It left the legacy infrastructure in place, which made enterprise IT happy. It provided a legitimate business justification to introduce Cloudflare in a minor and targeted manner to this stodgy environment, which made the enterprise networking team I had to work with excited and collaborative. It was minimally invasive and cheap, making the entire process legitimately feasible vs. a dead in the water pipedream. It solved all kinds of "unsolvable" problems that had plagued that site for years, which made the marketing client with power over our agency contract happy.

After the fact, it was interesting to absorb and appreciate the entire thing. At the end of the day it was an elegant but ultimately minor bit of technical work. But it was only achievable because of the availability, flexibility, and ease of use of web workers by Cloudflare. The end result could have been achieved by any number of things, but only this solution checked all the right boxes to be able to slither from hair-brained scheme while cursing my analytics data, past the numerous barriers and objections, all the way to POC and production implementation. With a bonus of planting a seed in a massive, technically-stodgy bigco for the use of Cloudflare in their enterprise architecture.

Security deposits are legally the tenants funds held in escrow by the landlord until the end of the lease. They tend to be heavily regulated in tenant law, with stipulations on how large they can be, what can be deducted from the security deposit upon lease termination, how long after lease termination the landlord has to return the remainder of the deposit, whether they have to be held in an actual escrow account[1], etc.

Prepaid rent is just that - it's rent for some future period that the landlord is just receiving early, so doesn't come with all the legal strings attached[2]. The landlord recognizes the income when they receive it and it becomes their money to do what they want with at that point.

The nuance goes beyond just semantics, too. If a tenant files for bankruptcy, the security deposit the landlord is holding in escrow is considered an asset of the tenant's estate. Whereas prepaid rent is not, unless the contract was executed super recently and the judge determines it unfairly harmed other creditors and wants to claw it back.

[1] https://www.lawyers.com/legal-info/taxation/property-tax/adv...

[2] I'm sure this isn't a universal truth - in the US alone, tenant law tends to be an overlaid mishmash of federal, state, and local regulations. So I'm sure some places attach strings to it. But many if not most places do not.

It's not a leftover – the core premise of how these scripts work use the exact same principle. Even when using the JS tracking library, if you look at the network calls to Facebook after the initial script download, they're all hits to https://www.facebook.com/tr/ with the metadata for the call in query parameters and a return an image content type (image/gif).

As I mentioned in my original comment, the tracking scripts are more than just generator functions for the image pixels. They also do stuff like browser fingerprinting and cookie management[1], and ensure these things get tacked onto generated pixel calls. This improves the fidelity of the data sent back to Facebook, but ultimately it all boils down to image calls with tracking data tacked on as query parameters to the call.

The reason Facebook (and others) don't recommend doing this is because

– As you mentioned, they have way more freedom to do what they want on the page when you load their actual script. So of course that's going to be their preference.

– Advertisers use these pixels for attribution purposes, but ad networks also use the opportunity to further fingerprint and profile users for targeting within their platform.

– The tracking script abstracts away the actual tracking protocol being used (i.e. the query parameters and their associated values). Which helps ensure calls are made correctly, as well as provides flexibility to make changes in the underlying protocol while retaining a stable interface via the JS SDK.

- Takes care of things like generating a unique user id, looking for and saving Facebook Click IDs when seen on incoming traffic, and tacking those values onto pixel calls when they occur.

Any user ID can actually be used, so long as it's unique (and Facebook's methodology is documented and easily replicated in [1], if you want to be consistent with the SDK). And persisting a query parameter into a cookie is actually more robust if done by a first-party script, since ITP has made the lifespan for cookies written by third-party scripts so short.

As long as your custom image generator accounts for those two components (generates a client id if none exists and persists + includes a fbclid if seen on incoming traffic), you will get close to parity with the JS tracking library as far as attribution in Facebook Ads without any need to load third party scripts from Facebook (or other advertisers). Which, as an advertiser, is the only part that you care about. What isn't at parity is all of the secondary fingerprinting that ad networks do, but that's the ad network's problem and preventing that shady shit from happening on your site is the precise reason you'd want to roll your own tracking calls to begin with.

[1] https://developers.facebook.com/docs/marketing-api/conversio...

> I suspect it's more likely intended to ease setup for less-technically-savvy users.

> ie they don't really want your truly-security-critical customer data.

It's both. It eases implementation with a one-and-done snippet, and then slaps a user-friendly GUI on the other side for marketers to sort through the firehose and use what they want.

While making it also trivially easy for marketers to toggle a button that OKs the turbo-boost mode that siphons up (hashed) sensitive customer information, which can then be used to claim credit for additional conversions by cross-referencing the (hashed) PII siphoned up against what Facebook has for those exposed to your ads.

Virtually all tracking boils down to 1x1 sized images getting embedded on the page, with various metadata being attached in that image call. The javascript libraries may include other functionality (like additional fingerprinting and such), but are primarily just convenient abstractions that generate and embed the the tracking images for you. Most provide the details needed[1] to build your own generator function, which would allow you to integrate the tracking you want while reducing your security exposure to third party code.

As for GTM – a deployed container is self-contained. If you don't want to expose your site to third party code, but want to use GTM as a convenient control plane for configuration of tags and tagging rules, you can do that. Instead of using the standard snippet that loads the container from Google, you can just grab the generated javascript file for the container after a new deploy and self-host it. It gives you the convenience of GTM (central control plane for tagging-related stuff, versioning and commenting, etc) but without the security exposure of embedding externally hosted scripts.

[1] https://developers.facebook.com/docs/facebook-pixel/advanced...

I don't necessarily disagree with you, and whether a pixel should be there at all is definitely a discussion in itself.

But for those who are implementing FB Pixels, I wanted to put out some potentially useful information that can help protect against unintended data disclosure, after mentioning the auto-listener behavior in a reply to another comment and being met with surprise[1].

[1] https://news.ycombinator.com/item?id=26537078

I'm not really sure if it's common knowledge, but I'd say it's less common then it should be. I went ahead and made a top level comment[1] with some info about controlling data disclosure to FB's Pixel in case it's helpful to others.

In the analytics space, you traditionally had to: – Initialize a tracking object on page load – Explicitly call methods on that tracking object when you wanted to actually send a hit

This is how it works for Adobe Analytics and Google Analytics historically. Many of the newer analytics providers instantiate auto-listeners, which gave them an edge on the out-of-the-box analytics features. And Google Analytics 4 (the newest release), also does this.

So it's not unheard of for site analytics. And a quick glance at a particular provider's website can usually make it obvious if this is occurring, based on the advertised features.

Ad pixels tend to be different though. You create a conversion event within the ad platform, and you're given a snippet of code to fire when that specific event occurs, which both instantiates the tracking object and calls the tracking method with the conversion event's configuration details.

Facebook's pixel works far more like a modern analytics library than an ad pixel. It vacuums up the hit data from the site and the marketer is able to sort it out after the fact in Facebook's interface and use what they want from it. Marketers working within Facebook can see this is happening because they set up the conversions and audiences against the hit data, but that's "just the way things work" in Facebook so they think nothing of it. Marketers coming from other channels will notice how different it is, but won't realize what's actually happening nor the implications behind it. Devs would realize pretty quickly what's happening after a few minutes exposure to the FB Pixel interface and it'd trigger a red flag for them, but that's marketing's territory and all devs see are the snippets provided for implementation. So the only time most people become aware of it is if marketing has someone technical working directly within FB's interface or if the person tasked with implementation has a reason to dig into Facebook's dev documentation rather than just plop the snippet on the page like they were told.

[1] https://news.ycombinator.com/item?id=26537140

PSA for any devs out there implementing FB Pixels:

– Facebook's pixel will, by default, attach click listeners to the page and send back associated metadata. This simplifies implementation needs, but can create unintentional information leaks in privileged contexts. To disable this behavior, there's a flag[1] you can use. After which, you can manually trigger FB Pixel hits and control both when they're fired and what information is included in them.

– There's a feature for the FB Pixel called Advanced Matching[2] that allows you to send hashed PII as parameters with your FB events. "Automatic Advanced Matching" can be enabled at any time via a toggle in the FB interface. I believe that setting autoConfig to false as mentioned above will similarly prevent Automatic Advanced Matching from working (since it disables the auto-creation of all those listeners to begin with). When manually triggering pixel calls like above, you can use this functionality via "Manual Advanced Matching"[3].

As a general rule, I'd strongly encourage anyone implementing a Facebook pixel to also include the autoConfig = false flag. This makes it work like most other pixels, where the base tag just instantiates an object. After which, hits only occur when explicitly defined in the site code, and include specifically what details you include in it. That way you're fully aware of the scope of data disclosure happening and any need from marketing to include sensitive (or potentially sensitive) information in these calls has to be explicitly requested (and theoretically vetted) as part of the standard dev process.

[1] https://developers.facebook.com/docs/facebook-pixel/advanced...

[2] https://www.facebook.com/business/help/611774685654668

[3] https://developers.facebook.com/docs/facebook-pixel/advanced...

Within Facebook, you can use the event stream collected by your FB Pixel to both define conversion criteria as well as create audiences and define inclusion/exclusion criteria for that audience. When it comes to tracking on pages behind auth, primarily it's for audience building which can be used for

– Cross-sell/Up-sell campaigns. Build an audience based on usage patterns, and create a create a campaign for a complimentary service or higher tier (say, for example, someone clicks the button for a gated feature they don't have access to).

– Suppression lists. If you don't want your campaigns to target existing users, you can build an audience from pixel data on your authenticated pages and suppress against that.

– Lookalike audiences. After you create an audience in Facebook, you can create a "lookalike audience" from that. So even if you aren't actively doing either of the above, you'd derive value from tracking your "best" customers and using it as a seed list for a lookalike audience.

You're also not limited to using the FB Pixel for any of the above. In addition to a browser-side pixel, FB allows you to upload hashed customer information and use those for conversion tracking and audience building. Which used to be completely transparent to end users, but now you're able to see a list of companies that have uploaded your info to FB in this manner (I can't recall where it's buried in the user settings, off the top of my head).

All of that said, it's entirely likely that Backblaze wasn't intentionally sending any of this data to FB to begin with. An insidious aspect of FB's Pixel is that it automatically attaches listeners to a bunch of stuff on the page such as buttons and sends back interactions and associated metadata[1]. The flag to disable this isn't mentioned in the implementation instructions that are generated upfront, and it's actually a fairly uncommon trait for ad pixels. So a typical implementation tends to leave it on out of ignorance rather than make a deliberate determination on whether to use or disable that functionality.

[1] https://developers.facebook.com/docs/facebook-pixel/advanced...

I can try to give you an overview, but caveat emptor that I'm no expert and could very well be butchering some of the finer points below.

The two historical programmatic interfaces to Office (that I'm familiar with):

VBA[1] - They have a pretty extensive VBA object model for the various Office programs, and is used for macros (either by auto-generated code when you "Record Macro" or manually developed code). The code lives within the Office file and follows it around, allowing it to be fairly portable since it doesn't require anything external to the file (unless you're calling out externally or relying on things like ODBC drivers).

You can also package up VBA into add-ins as well.

COM - There's an interopp assembly[2] that exposes a COM-based object model. This is the object model being used here (via Excel-DNA[3]), and the one hooked into by Visual Studio Tools for Office[4].

The biggest issue with both of these is cross-platform support – historically add-ins have been Windows only. COM isn't supported anywhere else, and VBA is only supported on Mac (not mobile). And the Mac VBA model isn't nearly as robust as the Windows version and has several caveats[5].

Enter Javascript, which is a relatively new option and what they're pushing hard get people onto. They've started developing an object model to expose the various Office apps via Javascript[6]. When you develop an add-in using this[7], the add-in is actually a webapp running in a sandboxed browser, with transparently handled interop between the add-in sandbox and the Office app. So all of the actual add-in development is HTML, CSS, and Javascript based.

The primary benefit of the Javascript option is that they're portable between the various platforms ([7] mentions Windows, Mac, Web-based, and the iPad. Not sure about Android/iPhone). But you get a lot of secondary benefits as well, such as the ability to have your add-in resources loaded from a remote website, ensuring things like the user always loading the latest version.

They've also slowly been making inroads in expanding the usage of Javascript - Office Scripts[8] is a preview feature they have right now, that effectively allows you to record macros in Excel for the web, which generate Javascript-based code rather than VBA code. You can also create user defined functions[9] in Javascript that can be mixed with normal functions within cells.

I (unfortunately) have to use Excel for many end-user deliverables, and have tinkered around with the Javascript options to make a few quality-of-life utilities for myself and others on my team. It's super handy for plugging into online services, and for being portable. I have one or two utilities for external teams that they access via Excel Online but I don't give them the file, and for others on the team we have several in circulation the Javascript-based stuff all "just works" in these contexts.

A major caveat of the Javascript stuff is that it all runs in sandboxed contexts and can primarily only interface between the Office host application and external services. COM and VBA-based add-ins don't have this constraint, and interact with other local resources beyond the host application itself.

On the plus side for the JavaScript option – in addition to being cross-platform, they're also not nearly as locked down in corporate environments because of their reduced security threat. But that limitation also means that it's unusable for solutions like this D in Excel add-in, which couldn't execute in that browser context and require the COM interop capabilities.

[1] https://docs.microsoft.com/en-us/office/vba/library-referenc...

[2] https://docs.microsoft.com/en-us/visualstudio/vsto/office-pr...

[3] https://excel-dna.net/

[4] https://docs.microsoft.com/en-us/visualstudio/vsto/create-vs...

[5] https://docs.microsoft.com/en-us/office/vba/api/overview/off...

[6] https://docs.microsoft.com/en-us/javascript/api/overview?vie...

[7] https://docs.microsoft.com/en-us/office/dev/add-ins/excel/ex...

[8] https://docs.microsoft.com/en-us/office/dev/scripts/resource...

[8] https://docs.microsoft.com/en-us/office/dev/add-ins/excel/ex...

[9] https://docs.microsoft.com/en-us/sharepoint/dev/general-deve...

They already have a counter move, to an extent. One of the deployment models for GA is via Google Tag Manager. One of the deployment models for GTM is this[1] server-side mode deployed to an App Engine container in Google Cloud. The only browser-visible communication happens between your browser and the App Engine instance, and then you send server side calls from that to the downstream systems based on those events (GA, Facebook Conversion API, etc).

It can also be used like the traditional GTM model, where it loads the primary GTM script browser-side, then that loads additional browser-side scripts based on the tags you implement (GA, Facebook, chat systems, map widgets, whatever). But the default GA support built into it avoids loading anything from Google's domains directly by the browser. And it's not even subject to the CNAME cloaking protections[2] that ITP have implemented, since it's not using the "CNAME to third party" technique that's typically common for these sorts of things to get first party access/privileges and is instead actually running on your infrastructure.

[1] https://developers.google.com/tag-manager/serverside

[2] https://webkit.org/blog/11338/cname-cloaking-and-bounce-trac...

While not completely customizable, it is already configurable. The Alexa/Echo devices currently support 4 wake words - Alexa, Amazon, Computer, and Echo.

I work with an Aleksa that I refer to frequently during calls, and was quite excited when I stumbled on the wake word setting in the Alexa app.

> Which gets to me other point in: besides the seriously unlucky residential users, who is paying these extreme prices? Factories which can't go down? Critical infrastructure?

The residential consumers in this unlucky boat were ones that explicitly opted into it. Most residential plans don't directly expose the consumer to wholesale pricing fluctuations - the consumer pays a flat rate per kwh, and the electric provider takes on the risk of their wholesale costs going above the retail rates their customers are paying.

The "known flat rate" usually get adjusted on a periodic basis, so right now the electric companies are eating the loss themselves and will have to make up for it when they next adjust the flat rate consumers pay. But on the short term, the consumer is protected from the volatility of the wholesale rate spikes and the electric company ends up on the hook to carry that debt load.

... unless you opted into one of the providers in Texas that give you "access" to wholesale rates. Because fixed rate plans have to factor in wholesale pricing uncertainty (like this exact situation), they typically have higher rates than plans pegged to wholesale. So the people in this situation took a deliberate gamble - generally they had cheaper-than-retail rates due to direct access to wholesale pricing. But they also took on the risk of wholesale pricing volatility, so it's now coming back to bite them in the current situation.

It's still seriously unlucky. But it's also wholly avoidable, and those in it have been enjoying the benefit of generally lower rates by opting into this risk exposure.

> Edit: As to why they're valued at $35B, consider that their customer base is "Every company with IT too screwed up / incompetent to deliver new features in a timely manner."

And that's not even the totality of their potential customer base. It just happens to be their primary focus (and pricing model) right now.

There are a huge number of repetitive processes/workflows that simply don't bubble up to the purview of IT. They either don't directly intersect the systems centrally managed by IT, don't warrant the cost/time/effort required for IT to get involved, aren't formally documented or known by IT in the first place, or IT simply doesn't provide any official channels to engage with them for automation-related support.

UIPath's current market positioning and pricing scheme is geared solidly at business cases built off of "ROI of RPA vs. IT modernization efforts". With a focus on automating singular processes occurring at a high frequency. Which alone is enough to support their valuation. But they could also trivially expand their positioning to include "power user" oriented pricing plans and move into that area of the market as well, where singular users (or teams) have a high quantity of low volume workflows.

ARRAYFORMULA itself doesn't exist in Excel, but they did recently add support for dynamic/spilled arrays[1]. Which brings it close to (if not at) parity with ARRAYFORMULA.

It's not even close to as handy as QUERY (in ease of use or intuitiveness), but they also recently introduced FILTER[2]. Which can be used in combination with other functions to replicate a subset of QUERY use cases.

My pet list of functions that have me reaching for Sheets are the regex ones[3][4][5]. Excel's search and replace functions support basic wildcards[6], but anything more sophisticated than that quickly becomes infeasible, impractical, or impossible to replicate using Excel function built-ins and requires dropping writing into Javascript or VBA to write up a custom function.

That said, Excel has had a pretty nifty and powerful ETL tool hidden inside of it for the past ~7 years called Power Query[7]. This is essentially an entire app-within-an-app (and is a data processing engine in many Microsoft data products), complete with it's own programming language[8] and compressed columnar data store format. For anyone with a development background, you can easily ramp up on Power Query's language and do 90% of the work you need to do there, and obviate the need for complicated and fragile formulas to begin with.

[1] https://support.microsoft.com/en-us/office/guidelines-and-ex...

[2] https://support.microsoft.com/en-us/office/filter-function-f...

[3] https://support.google.com/docs/answer/3098244

[4] https://support.google.com/docs/answer/3098292

[5] https://support.google.com/docs/answer/3098245

[6] https://support.microsoft.com/en-ie/office/using-wildcard-ch...

[7] https://support.microsoft.com/en-us/office/getting-started-w...

[8] https://docs.microsoft.com/en-us/powerquery-m/

Carriers run IoT-specific networks[1], which are optimized for use cases such as telematics (low power consumption, low bandwidth usage, but high penetration and coverage). So it's entirely likely that your washing machine would be able to happily send along telematic data via the same carrier your cell phone can't even establish a connection to.

[1] https://www.business.att.com/products/lpwa.html

Reading through the comments on a few of these recent Gitlab posts, the self-hosted option has pricing parity with the SaaS option. I.e. most of the features gated to the $19/month Premium tier for the SaaS are similarly gated in the self-hosted option, and require paying the same $19/month cost in order to activate that extended feature set in self-hosted instances.

There do appear to be some features in the paid SaaS options that are available in the free/core self-hosted software, but I can't find a straightforward breakdown of what those all are.

Sounds like you can already do that with the "delete from org + recreate in personal" workflow, so an "unshare" button would just be streamlining that existing capability.

Stuff like what the parent described tend to be "on top" of your day job, rather than your actual day job.

Parent likely established a working relationship with individual(s) in engineering organically over time, and at some point leveraged that relationship to ping them about a customer issue that crossed their path and seemed to be an engineering concern vs user-error. That didn't cause waves and went well, and got repeated enough to become an established but unofficial "thing" parent was capable of, and they became known by a few sales/account folks as the go-to person when they felt a situation may warrant that unofficial route.

You can make a career off of doing this sort of thing, but I'd caution against it. If a company is hiring for specific scenario of "fast lane between client and engineering", the actual job is "support with special escalation privileges, servicing clients splurged for the premium package". You get all the soul-crushing hell of working a normal support role, but with the added benefit of solely servicing clients that expect you to hand them the world because they paid extra for it. Which is far closer to a nightmare than a dream; particularly considering someone working one of these official roles likely has the skills to pivot out of the support org and into the engineering org in some capacity, and drastically increase their salary potential while simultaneously improving their quality of (work) life.

In a more general sense though, pretty much any career benefits from doing what the parent described. It's effectively just flexing your soft skills and establishing relationships with people outside of your immediate sphere/department. Which has a tendency to make it easier for you to get things done, and garnering a reputation to that effect.

> What management needs to realize is that this is also an important interface point which requires attention. This doesn't happen at all, or is inconsistent.

> What I've always found interesting, is that all of these are often failing in some way at the same time in an organization of any size.

The formalization of it is frequently the cause of it failing or being inconsistent. Once it's a workflow that's explicitly acknowledged and condoned by management, it will start to lose its effectiveness. As an official express lane between customers and engineering, every account/sales person will become aware of it and overload it, either in the general course of supporting their client portfolio as much as possible, or even worse, by making this internal express route known to clients, as they can get incremental revenue by branding it as a "VIP Support" service or to make at-risk clients feel special. Which will eventually end up in actual client contracts in some form or another, opening the door to client abuse (or misuse) as well as causing legit cases that would have gone through this implicit channel to get routed to and trapped in normal support because the client at hand didn't pay up for the express lane.

You've also replaced a channel built off of relationships and mutual trust/respect into one based on official responsibilities and inertia, and all the hazards that entails. Such as political/managerial turf wars that add friction to the process, as well as cost minimization efforts that deskill the role over time and profit maximization efforts that overwhelm the capacity of the role, alienating the engineering team and undermining the entire intent.

... not to say it's impossible. But that's generally why you'll see it failing in some capacity any time you witness it, because it's almost impossible to maintain equilibrium the moment you officiate it.

An alternative that tends to be more lasting is for management to _actively facilitate organic growth_ of these sorts of things. Enable and encourage and provide opportunities for inter-departmental relationships and lines of communications to form. That way there is no single "back channel", and organic lines of communication between different parts of the org are robust against the loss of a single node.

You'd be surprised. Amazon's affiliate program, as one example, pays out for any item added to someone's cart within 24 hours of the affiliate click (with a 90 day window to complete the purchase)[1].

So even if the commission on the Display Dummy Plug would be peanuts, you can still generate a decent revenue stream from capturing commissions on ancillary and unrelated add to cart actions within that 24 hour window.

[1] https://affiliate-program.amazon.com/help/node/topic/G9SMD8T...

> Also, giving your credentials to any third party, including Plaid, voids the warranty at many financial institutions.

Funny enough, I've seen that be the case at some banks that simultaneously integrate Plaid into their online account application flow for the initial/funding deposit but. Pretty ironic that users are implicitly coerced into voiding their liability protection at their existing bank during the course of opening an account at a new one. Who wouldn't hesitate to turn around and also invalidate your liability protections themselves if you used your new bank's credentials with Plaid elsewhere.

That's a legally required quirk of credit unions; in order to get a federal charter/license to operate, they have to define a field of membership[1].

That said, I've never had a credit union bring up membership requirements post-joining, and have been able to both use existing accounts and open additional accounts at credit unions long after no longer qualifying for their field of membership.

A lot of credit unions even participate in shared branching[2], which lets you use the physical branches of one credit union to manage the account you have with another. Which comes in handy for the few things you can't use ATMs or online banking for, such as large transactions beyond ATM limits or depositing cash.

[1] https://www.ncua.gov/support-services/credit-union-resources...

[2] https://www.thebalance.com/co-op-shared-branches-how-custome...

Oh interesting. I was curious and found [1], which mentions aerial deployment is actually preferred when poles are available.

Around me, you might see aerial to neighborhood cabinets, but everything past that (cabinet -> pedestal, pedestal -> premise) is always buried. Considering how much of a pain buried lines are around here, I had presumed that there was some value to this. But looks like it might just be a constraint imposed by local regulations.

[1] https://www.ofsoptics.com/fiber-optic-solutions-for-the-home...

Those aren't conflicting positions; indefinitely can mean both "unspecified/undetermined" or "unlimited/forever" amounts of time. So you can interpret that statement as

"we are extending the block we have placed on his Facebook and Instagram accounts for at least the next two weeks, but potentially longer."

My childhood was a few decade after that, but peanut butter on toasted white bread and Velveeta (+ Rotel[1]) were pretty much stables of my youth.

[1] https://www.ro-tel.com/products/original

They didn't come back and bury those?

I have AT&T Fiber – the installer ran a line from the nearest fiber hut to my home (across several neighbors' yards and a storm water runoff/drainage area), and left it exposed. But a separate truck rolled through about a week later and microtrenched it, so it's buried all the way up to my house.

> has access to everything else

Everything else _that's on my computer_.

The person with access to my camera has access to observe the environment my computer is in. My WFH setup is in my bedroom - I don't want to be paranoid that my company (or a random IT employee at my company) can use my computer as an incognito candid camera at a whim by remotely activating it and suppressing any visible indications that it's activated.

Manual shutters ensure that you definitively know if it's even _capable_ of viewing/recording you. Automated shutters at least can provide re-assurance at a glance if it's active (or capable of being activated) at that point in time. An indicator light that may or may not be capable of being manually suppressed means you have no reassurance at all about whether you're being visually observed any time your laptop is open and powered on, which can be stressful.

I can shut it and turn it off at night when I'm not working to provide reassurance that it can't record me when I'm not working, but my room is a shared space where there are plenty of things that happen in it while I _am_ working that I wouldn't want captured, such as my SO in bed behind me if I start work before she gets up, or her coming in to change during the day or get dressed after a bath/shower.

The abrupt shift to WFH over the past year is likely one of the drivers of it being such a hot trend for business laptops. Many people I know and work with have don't have dedicated home offices, and have similarly resorted to repurposing shared spaces to work from (bedrooms, dining rooms, living rooms, etc), and likely have similar concerns about maintaining their personal privacy as much as possible.