Yeah. There are good reasons things are bad. But there's also a foolish consistency. Like, you can just do things! If you decide monitoring is important you can decide not to outsource it. Most everyone doesn't, though. Probably because they don't think it's very important, and the existing tools get it done well enough, and it's the muscle memory of the subjectively familiar (if objectively fantastically overpriced).
Well, in the early days of infrastructure growth, when designing bespoke monitoring systems and protocols would be relatively low-cost, it's still nowhere near the highest-ROI way to spend your tech team's time and energy.
And to do it right (i.e. low-risk of of having it blow up with negative effects on the larger business goals), you need someone fairly experienced or maybe even specialized in that area. If you have that person, they are on the team because of their other skills, which you need more urgently.
SaaS, COTS, and open source monitoring tools have to cater to the existing customers. The sales pitch is "easy to integrate". So even they are not incentivized to build something new.
It boils down to the fact that stream-of-bytes is extremely well-understood, and almost always good enough. Infinitely flexible, low-ceremony, no patents, and comes preinstalled on everything (emitters and consumers). It's like HTTP in that way.
And the evolution is similar too. It'll always be stream-of-bytes, but you can emit in JSON or protobuf etc, if it's worth the cognitive overhead to do so. All the hyperscalers do this, even when the original emitter (web servers, etc) is just blindly spewing atrocious CLF/quirky-SSV text.
> It'll always be stream-of-bytes, but you can emit in JSON or protobuf etc, if it's worth the cognitive overhead to do so.
This is the crux of it. That's great until you encounter a need for a schema, and then it's "schema-on-read" or some similar abomination. And the need might not manifest until you're pushing like 1TB/day or more of telemetry data with hundreds or thousands of engineers working on some >1MLoC monstrosity. Hard to dig out of that hole.
The situation is tragically optimal--we've achieved some kind of multiobjective local maximum on a rock in the sewer at the bottom of a picturesque alpine valley and declared victory. We should do better.
> The situation is tragically optimal--we've achieved some kind of multiobjective local maximum on a rock in the sewer at the bottom of a picturesque alpine valley and declared victory. We should do better.
But it's a very comfortable rock. pointy in all the right places.
My take on it is that frequent users perceive apps as desktop launchers/shortcuts.
They don't care about the difference between app and web, per se, but the bookmarking situation in mobile browsers is awful (desktop too, honestly), and an app presents a convenient launcher for the service/site/data they want.
Adding a springboard launcher for a PWA is easy but still apparently more frictional than installing an app.
As long as the application is made aware of the permissions and can prevent functioning when they get denied, that doesn't really help much. It's the choice between getting mugged or never leaving the house.
The ability to deny permissions without the app noticing or filling it with fake data doesn't exist on either system.
In the time it took you to write this comment, you've thought more about the abstraction than most of the people who are confused by it -- and it will never succeed to coax them out of their confusion with such logic. :)
Credit agencies do not report income to the IRS, so there's no tax relevance. Credit agencies are not party to your obligations to the IRS at all. You can lie to credit agencies all day long if you like.
However, if you do so for the purpose of some kind of benefit, financial or otherwise, it's clearly fraud.
It's hard to remember that that's still illegal these days -- but it is, for you and for me, at least.
Is it Fraud though? Think about it...sounds to me like data obfuscation. There are no laws that enforce the truth if there is no financial damage. So the previous comment stands.
I think you're wrong, but I'm not a lawyer and I don't operate on the fringes of fraudulent behaviour, so I might be miscalibrated.
But my premise is that there is benefit derived from the lie, either financial or otherwise. I believe this is clearly fraud and risks civil penalties if pursued by the party who used the information to extend the benefit.
An interesting case is if you lie about previous salary to a prospective employer who does not have the ability to confirm the data. In that context, with no formal pre-employment agreements or contracts, the lie is probably just negotiation strategy with no civil liabilities. I repeat that I am not a lawyer. :)
In the US, I regularly see bathrooms and kitchens without GFCI.
I looked up the history:
1961 GFCI invented by a professor at UC Berkeley
1971 Added to NEC code for outdoor outlets
1981 … bathrooms
1987 … kitchens
2005 … laundry rooms and unfinished basements
2014 … crawlspaces, around pools and hot tubs
Lots of bathrooms haven't been renovated (or at least not with permits) in the last 45 years, apparently!
Except that the latter has more functionality than the former, and should be prefereable.
reply