So often when traveling I find some app that is required to complete some menial task like recharging a public transport card, that is for some reason ONLY available in the app store of that country.
If this blocks me loading those apps via APKPure or similar, it's going to suck.
Ugh I used to keep a British iPhone on a British network in the USA just so I could access my bank accounts, because the app couldn't be downloaded in the USA.
From what I remember, for some reason there were specific features only available through the app. Believe me, any app use of mine is a very last resort.
I see more and more companies shutting down their web portals in favour of mobile apps.
At the company I work at the moment the customer base is 2-3% on web, rest is mobile. It's such an incredible waste of time and money to keep the portal functionality on par for such a low number, and I hope they shut it down soon.
Chromecast was an endless source of frustration for me from having the first prototypes while at Google, to the latest devices.
It solves such a simple problem that no one else seemed to want to tackle - put a video on the TV - and yet, it never quite worked reliably.
We used it every evening for years and 19/20 times it streams effortlessly and instantly... 1/20 times I'm restarting browsers, TV's, WiFi until we give up and watch on a laptop.
Back to the HDMI cable. In retrospect, I should have never left it.
We have 5 Chromecasts with Android TV and they all work perfectly. We really only use Plex, Youtube, Netflix and a few other streaming apps, but none of them has any problems. It sounds like your problems with Chromecast are due to the rest of your network infrastructure and not the Chromecast.
There are lots of variants of this. Wazuh, Velociraptor, etc. They have several problems. One is that user-mode EDR is just not very efficient and effective, and kernel mode requires Microsoft driver signing. There are some hoops for that, and I don't know how hard they are, but I don't know of any of these products that seems to be jumping through them.
The other issue is that detection engineering is really expensive, so the detections that are included with CrowdStrike out of the box are your problem if you're using a free product. From a cost perspective you're not getting off a lot cheaper and trying to sell open source and a detection engineer's salary to a CISO who can just buy CrowdStrike instead is understandably a pretty tough sell. Or it was until this weekend, anyway.
It sounds really interesting. But the only thing it does not do is scanning for vira/malwares, although this could be implemented using GRR I guess. How does Google mitigate malware threats in-house?
> 10-12,000ft is generally accepted as negligible impact on cognitive function
That is just a guideline.
Each person responds to hypoxia differently and starts becoming hypoxic at different altitudes. One person might start having symptoms at 8,000 while another can function without oxygen at 14,000 for hours. It depends on your health and acclimation. All else equal if you live in Denver your tolerance to altitude will be greater.
This also applies to carbon monoxide exposure. For either condition you may not get headaches at all. Or you may get loss of color vision first. Or maybe your fingers tingle first. It is highly variable from person to person. Many people in those situations report they excluded hypoxia or carbon monoxide as a possibility because their symptoms didn't line up with the published lists, unaware that those lists are merely guidelines.
The one constant is that by the time you realize you are hypoxic or have CO poisoning you will either not care or be unable to fix the problem. This seems to be nearly 100% universal. Even when briefed ahead of time in a test scenario almost everyone will fail to take any action to rectify their situation on their own. Sometimes they can be coached into taking action (like descending or putting on an oxygen mask). For that reason a number of GA pilots use a pulse oximeter when flying above 8-10k to detect the signs early, while they are still aware enough to take action.
Also be aware that perversely CO causes your pulse oximeter reading to increase. Those chemical dots are useless, you need an actual detector and the sensor inside them is good for 10 years. Once bound to hemoglobin CO takes a long time (12-24 hours) to be removed and breathing oxygen only speeds that up by half. This is very unlike hypoxia which disappears in seconds once you start on oxygen. For aviation don't use household detectors - they have relatively high thresholds. On a long cross-country or multi-day flight you can accumulate exposure at levels low enough not to trigger a household alarm but cumulatively become very impaired due to the long half-life of CO in the body.
As someone with thousands of jumps from this altitude, I disagree. The VAST majority of 'first timers' I've taken on tandems don't feel much, if any, difference either going up.
Fair enough, I haven't jumped out of a plane, I was basing it on my climbing experience, which I realise now is not a valid comparison, I suspect that it's more noticeable in that context because of the high rate of respiration you tend to get when slogging it up big hills.
They definitely do care - DJI devices block you flying in any kind of prohibited airspace out of the box and it's very difficult to override. In many countries, there's prohibited airspace over prisons for this reason.
Oh man, I FEEL this comment. That was one absurdly awful set of documentation, because they not just have a lot of confusingly placed repeat content, they also follow the philosophy of only explaining top level initial conceptual primer for everything, and only explaining the actual main use case of the component 3 navigation pages deep.
So a beginner has to jump a BUNCH of pages to get a primer, and an expert has to bookmark the couple actually-useful pages and later give up and just look at github for specific operators/processors when they already know the basic config inside out.
Same experience. Otel is one of the wordiest docs I've ever come across that says very little.
Further, I found a lot of little bugs that are hard to Google, or when Googling finding open issues that are either known and working on, or no response at all.
I ended up just throwing it in the garbage and using direct connectors. I like what Otel is trying to achieve, but it feels extremely opaque and half baked at the moment.
Yes! Otel, is exactly what I was thinking. It’s for people working on it with access to tribal knowledge.
For mortals working to add it to their service it’s not fit for purpose
I know the feeling, so I built something that hopefully addresses some of this: https://otelrecipes.com. Just launched it last week!
It offers sample applications and a website that shows in a step-by-step manner what you have to do to get OpenTelemetry configured in your apps. My goal is to keep the sample apps to the minimum and focused on a single goal: E.g., I want to add tracing to my app; I want to record metrics; I want to correlate logs with traces etc.
I have lots of ideas and things in the backlog, such as collector recipes.
It's all OSS as well, so anyone can contribute with more samples :)
The best OTel docs I've seen have been from observability vendors. The CNCF needs some volunteer technical writers or something. I think a lot of those docs suffer from being written by people who know the spec inside and out.
Have you given the Getting Started docs pages a go? Indeed it's mostly still reference/conceptual content, and not oriented towards specific workflows yet. We've been wanting to get that kind of content written for quite some time, but the reality is we're a small group (often volunteering our time) and there's still an immense amount of reference and conceptual gaps that need addressing.
When I started using Honeycomb, I had such a wonderful integration experience with their Beeline SDKs.
Then they transitioned to OpenTelemetry – for very good, justifiable, "good community member" reasons – and yikes, everything got so much more complicated. We ended up writing our own moral equivalent to the Beeline SDK. (And Honeycomb have followed up since with their own wrappers.)
There's so much I love about Open Source, but piles and piles of wildly generic, unopinionated code... ooft. :-)
Don't know about the US, but some airports with a significant retail presence post-security allow non-passengers through to shop/eat etc. As a kid I remember my parents coming through security to send me off on a flight by myself in Australia.
I tried to use it for a new SaaS product - but their plans start at 3000$/mo.
It seems like they have things backwards. The small fry like me don't want to self-host, we want a managed solution. The big fishes have enough scale to self-host.
I see your point, but I think this might work for them. At my previous place we started on Stripe it was really nice to work with, cost nothing in absolute terms because we had few sales, easy to integrate.
But a few years in we were doing substantial volume and we wanted to re-negotiate the contract. If we had Lago and could re-integrate with that, using it as leverage on a Stripe contract renewal, that could have been worth $3k a month, given that we were paying Stripe $30k per month in fees.
Our situation was a little different being retail rather than SaaS billing, but I could see a world where this makes financial sense.
Got trapped by the same thing. Usage based billing is a huge pain point for us we were really excited by lago but dont want to self host infra if we can outsource it.
We ended up talking to about 5 different usage based billing API providers and basically no one is interested in servicing the sub $1000 per month market which is where we will realistically be for the next year as we grow.
Additionally lago and other providers advertise "no revenue cut" and then always quote pricing as a percentage of revenue (which is technical not a revenue cut except your fee scales pretty linarly with revenue).
Take a look at https://revenium.io (full disclosure: I'm co-founder/cto.) We are a fully hosted solution with a free/developer tier and plans that start at $19/month. We also have a self-hosted option.
This is actually a space I’m exploring. Would love to chat about your use case if you’re interested. Shoot me an email at chris. Domain name revenuehq.com.
We are billing more than $1000 a month :). The providers didn’t want our business for less than $1000 per month (at a heavily discounted time limited price).
We talked to this many providers because it’s a huge pain point for us and the thing we hacked together was inadequate for tracking usage.
This may be true in the most technical sense but it's a pointless observation. There are of course plenty of big businesses now so it's a perfectly rational business decision to target those big ones first. Because they were small 5, 10, 50 years ago is completely irrelevant.
This suggests their target customer are the Stripe whales spending more than $3000 a month on fees.
It's pricing genius to avoid the small, expensive to service, unprofitable customers (let Stripe lose money on those), and then they cherry pick the good customers once that have already scaled up at Stripe
What's a fair price for a budget-friendly hosted version? Lower upfront cost, or maybe a revenue share? We've aimed at enterprise deals for the paid edition, keeping the open-source version widely accessible. Keen to hear your thoughts on adjusting our pricing.
100$/mo? I would like to be able to build out an idea in a week or two and see if it goes anywhere. Making my own metered billing system to go with it would be an enormous project.
If it does go places, I'm happy to pay the big fees when it gets big.
IMHO this is why Stripe is so successful - picking up the customers while they're small. I'm with Stripe because Adyen et. al wouldn't talk to me at $100/mo but Stripe would, and many years later I'm still with Stripe running a large multiple of that through them (ok, via Paddle now..)
Can i ask why, in 2024, basic internet payment infrastructure isn't a commoditized resource shared across FANG/governments/ISP/banks? Why Does it have to be this way? Why must it be so convoluted for the merchants themselves? Why must it cost so much money just to be able to accept payments? Don't we all love payments? Don't transactions make the world go round? Are we already paying taxes on literally everything? Wouldn't it be in everyone's best interest is to make the simple act of doing business be as simple, frictionless, and barrierless as possible?
What is it exactly that you want Amazon, the US government, Verizon, and JPMorgan doing together that isn't done better by Stripe and its competitors right now?
For a discussion around payments this seems very similar to the "internet is a utility" discussion from decades past with a weird anti-capitalist / "a private company doing this is bad" vibes.
If this blocks me loading those apps via APKPure or similar, it's going to suck.