owaislone

I've seen anything that mentions the word "telemetry" automatically receive down votes on HN. People confuse it with companies collecting user-identifiable data from clients like apps/browsers.

Podman does support docker API so you can use something like the OpenTelemetry Collector to fetch metrics using the docker API and forward them to prometheus.

Collector: https://github.com/open-telemetry/opentelemetry-collector-co...

Docker receiver: https://github.com/open-telemetry/opentelemetry-collector-co...

Prometheus exporters: https://github.com/open-telemetry/opentelemetry-collector-co... and https://github.com/open-telemetry/opentelemetry-collector-co...

OpenTelemetry will soon support native Podman API as well.

I don't know if it was based on user-testing but yes it did involve a lot of user-group studies where they'd bring in random people with no prior Linux experience and tell them to use Unity

Probably because Youtube was using MySQL before being acquired and switched to a better, probably fully managed DB that was much easier (free?) to maintain and scale.

Happy for them. Back in 2004/2005, Ubuntu was what got me into the Linux wonderland. It was an amazing time. Canonical's work on the desktop towards the end was so exciting for me personally. Unity as a concept even though just partially realized is still my favorite ever DE. To this day I install little tools on my mac that give me some Unity elements like super+{1,2..N} combo. Part of me still wishes they or someone else can come back and finish that vision.

The original Unity design docs were so good but I can't find them anymore. Does anyone have access to them? They detailed things like workspaces, "windicators", HUD etc. It was an exciting time even though there were a lot of flamewars because of Gnome fans not being happy with Canonical doing their own thing.

That's actually wonderful news. Thanks

Only thing this and Steam OS is missing is native support for software like Easy Anti-Cheat. Because EAC explicitly refuses to work on wine (proton), it's impossible to run a huge number of AAA multiplayer games. I know Value probably cannot do much on it's own here though.

Nice. I'd recommend negating the points mentioned on the landing page and replacing red crosses with green checks. For example,

Often limited to one OS => Supports all desktop platforms

Infrastructure setup takes valuable time away from actually developing your app => Spent time building your app, not update infrastructure.

I feel instead of speaking negatively about other solutions, speaking positively about Pakkly makes me want to try it out more.

Doesn't that mean the client holds the keys/secret of some sort is shared with the client so it can either generate or verify?

Yeah that's a bit strange. My guess is that they use different tech or techniques under the hood and eventually one will be picked as a winner and become just web.telegram.com or they'll take ideas from both and merge into a single one. It kinda looks like a poor man's A/B test.

I just tried one of the apps and it had instant feedback when I gave it the wrong 2FA code. It felt too fast for any network calls to be involved. I looked at the network tab in my browser and sure enough no network calls were being made. It looks like they are using some sort of client side crypto to verify or at least reject tokens. Does anyone any idea about why they'd chose to do it client side or what I am missing?

Sandboxing does not mean no interaction. It means supervised interaction between apps where the user is in control of what to allow and what not. I'm not sure how well Flatpack does it (never used it) or Snap does it (used quite a bit but never tested how well it sandboxes) but there are other platforms that handle sandboxing pretty well and then provide APIs on top to allow interaction with the system and other apps (iOS, Android, Meego for example).

> We sign the webhooks for you to prevent SSRF, we implemented a retry logic, we have monitoring on all of these, and all of the other things I mentioned elsewhere.

Nice. These are very useful feature and I can see myself subscribing for these. May I suggest you highlight these as the main features and demote, remove or re-word "not having to invest significant engineering resources in making a reliable webhook calling system" bit (not exact words). Just a suggestion, don't claim to know more about your business than you but as a possible customer, this claim being at the top would throw me off TBH.

> I mentioned it elsewhere in this thread, I don't see how this can be a library. It's a standalone service that needs to be run and monitored, needs to scale with your usage, and you need to make sure it doesn't hang, the queue doesn't get too long, and etc. I actually say it in the post, webhooks aren't as simple as they seem.

They definitely aren't and I know that from building some quite non-trivial ones and I did build some of those as libraries used across projects in the same company. Also, wouldn't my scale be the same irrespective of whether I call Diahook or anything else directly? I still need to make same amount of calls, have same queue, same retries etc.

> I think the same can be said on every other API company, including Stripe, Sendgrid, Twilio and etc. If this is a concern for you, you need to take care of that, if it's not a concern for you, then Diahook is not any different.

This should definitely be a concern for everyone unless missing outgoing webhooks is fine for a service and I agree Diahook wouldn't be any different which was my original comment. Sorry if I came across as dismissive. I was just pointing out how using something like this cannot be a reason to eschew fault tolerance in outgoing webhook code.

> As a (hypothetical) SAAS company, I don't get an SLA from my customers that their webhook consumer endpoints won't go down

Really? I thought this would be covered under most SLAs.

> It seems to me that people saying your service is also potentially unreliable are missing the point a bit.

The reason I (and _I guess_ other people) are thinking of this is that I read not having to invest significant engineering resources into building a robust failure resistant system as one of the main, if not the main selling point and I don't see how that is possible if I have to build it for Diahook in the first place. I understand Diahook has a great SLA and promises to be up as much as possible but things will always go wrong and there are so many points of failure outside of Diahooks control. So as a service maintainer, I still need to invest the same amount of engineering in the component that calls the webhooks.

SLA is a business thing, not a technical one. When I evaluate multiple services and compare their SLAs, I see the probability of one service causing less disruptions to my business than the other. I don't see that as a reason to not write fault tolerant code. Engineers cannot rely on a higher SLA as a reason to throw fault tolerance out of the window. That's my main issue with using a service like this. However, there can be other features that could still make me sign up. Not having to write fault tolerant code just isn't one and anyone buying into that is shooting themselves in the foot.

This looks nice but don't I still have to invest all the engineering to make sure my calls reach Diahook service in the first place? The argument from diahook seems to be "we'll never go down". That's covered by SLAs by all companies that Diahook would be forwarding my calls to. Does Diahook claim 100% uptime? That's impossible. Even if it were possible, there are many other points of failure between my service and Diahook and I need to take all of them into account. Once I do that, I don't see much point in using Diahook. This would've been better off as a library I think.

There are other features/reason that would make me use a "webhook service" and I've contemplated building one before but mainly for async message passing between systems. Anything sync and you almost always need to take care of all the failure states.

This could be useful as a library or side-car. I can't help but think of this as a plugin for something like Envoy even though Envoy probably does a lot of this already.

I so want to go back to this but after losing two of my 2 TB drives got corrupted in the past 15 years and now I'm scared of leaving everything on a drive. Perhaps a cheap S3 deep archive storage + a physical drive as main storage is the answer but then I won't have an app like Google Photos which is actually pretty great especially for sharing with family.

Unrelated but does anyone know if the partner sharing photos in Google Photos costs double the storage? I know I can view my partners photos in the app but there is a "save" feature which allows me to save my partners photos to my own "galley". Does that mean the photo counts towards my Google One storage twice? I think it doesn't but I'm not sure.

Interesting. Would really appreciate if you could share the video with us. Thanks

Do you still need the LG remote to make it work or can you throw it away and still be able to operate or even re-configure the TV later?

How do PC monitors today compare with TVs? I wonder if higher end monitors combined with sound bars and chromecast/firestick would be a good enough replacement for the living room TV.

The backend already stored all the information about the users. Why would it violate any laws if it stored a bit more or a bit less info? Things can get tricky if Github exported the collected data to third party for analytics.

GTK3 broke the theming API almost every minor release.

Fuchsia will e to Android and ChromeOS what Servo is/was to Firefox. Eventually the guts of Android and ChromeOS will be replaced with Fuchsia while end users won't see a radical change. It might feel like moving from XP to Vista or OS 9 to OS X.

Cyberpunk, like any other single player title is much more likely to work than games like COD, Apex or Fortnite. Most multiplayer games use some additional components like the EAC that explicitly is made to not run on Wine AFAIK. IIRC, EAC did work on Wine until Epic games patched it so it wouldn't anymore.

Getting just EAC (Easy Anti-Cheat) to work on Linux would immediately make so many titles work flawlessly. Too many games are literally unable to run on Linux/Wine because EAC won't let them. For example, Apex Legends.

Interesting. Do you know how hard it would be for someone to upload a bunch of original videos with same copyright as the videos in question?

You use Ora2Pg

Because everyone wants their preferred set of tools/languages to do it using the design patterns they like and there is nothing wrong with that. I don't see myself using Beeware ever really but that doesn't mean people shouldn't work on it.

OP is not wrong. It is a huge risk for the maintainer to merge the PR in it's current form or as a fork no matter how you classify the present Iranian government. Anyone knowing anything about Iran would sympathize with the maintainer.

https://venturebeat.com/2012/01/09/iran-sentences-us-born-de...

https://en.wikipedia.org/wiki/Saeed_Malekpour

That's not what I was implying at all. It's not about money. If a person learns to actually write software on their QA job, why would they not do it for a living? In most cases, it's a more satisfying job to have. The assumption I made was that if a QA person who also reviews code a lot becomes really good at the job, they are very likely to try and become a developer themselves.