HN user

remon

655 karma
Posts2
Comments201
View on HN

Well, it's a fact, not a narrative. I think the actual debate is whether or not boosting economies of countries in the EU that for one reason or another were or are behind on the curve is a net win. I think it is. Just as it is perfectly justified for other countries to feel a bit hard done by if that same country after an estimates 280 billion euro injection is still rejecting the shared currency of that body.

Being able to buy groceries with euros is not a strong, or even related, argument to the point you're making. Even ignoring the real economic cost of having two currencies, there is no serious economist that would argue Poland joining the EUR zone is negative for Poland (as opposed to for stronger EU economies). Every single historic metric points in the other direction. Poland's economy is maturing and strengthening and median household income is slowly reaching parity with neighbouring countries so this particular argument may only hold for maybe another decade but until then it's a bit misguided. Also, not for nothing but the Polish economy is mostly doing as well as it does because of the metric ton of EU subsidies injected into it the past decades. Poland is one of the largest net receivers of EU money since 2004 so arguing it or its single currency was somehow a net negative to Poland is, and by extension an odd argument to make for someone benefiting from the above as a Polish citizen.

Author is not wrong, but boy do I get annoyed with tech articles with this sort of "listen up you dumb f*cks..." tone.

So far there are zero data points on the success side of the fence when it comes to visual programming. The exceedingly rare times I come across it professionally it's a toy project or something that's basically in the state of "We wish it was just code but we don't dare touch it".

I know people are going on about privacy and that's fair but easily sorted with the appropriate data privacy policies and actually adhering to your commitments in them.

If you are approaching this from a potential business perspective that will not be the major issue. As you can tell from the comments most people do want their screen recordings on a remote service, now matter the policies involved.

That leaves you with some options :

1) Encrypt the outgoing WebRTC stream before it leaves the client device/browser (e.g. through WebRTC Insertable Streams or similar), encoded with a client local key that only your customer knows/manages. This ensures any screen recordings stored on your end cannot be accessed in any way. They can then download the recordings as needed and decrypt on demand. Note that this still has the implication of you storing and transmitting massive amounts of data which is likely to become cost prohibitive as a service.

2) As above but do the decrypting for your customer on your end so they get to download playable media. This obviously introduces the security risk of your platform becoming temporarily able to 'see' the content.

3) Save your recording directly through MediaRecorder WebM or similar (has various browser compatibility challenges as standards materialize) and uses less obvious encodings (we're still living with the bullshit of H.264 requiring licensing).

Show HN: FlakeUI 1 year ago

There's a significant performance issue. There's no good reason for a few ovals and texts to stutter on my system. May be worth investigating.

If the random user ID is truly anonymous (so, cannot be linked back to an identifiable person even with other data you have), it is not personal data under GDPR and no obligation to inform or consent is needed. If the data processor stores any information that makes PII attribution possible then, and only then, does it fall under GDPR, CCPA, etc. That random ID being persisted on the device allowing for subsequent attribution is still not PII sensitive unless/until the aforementioned identifiability barrier is breached. This is exactly why prominent analytics platforms (Plausible, Matoma, Mixpanel if configured correctly, etc) all offer data hygiene barriers.

I suspect what's happening here is that the word "user" is making things ambiguous here. It was meant in the context of attributable session, not as the data subject as per GDPR language for example.

Well, sure, if you're exceptionally picky about non-normative use cases you can probably find a use for it that is not harmful to the average person. But you're doing a lot of heavy lifting already to justify a positive use case (contacting a person you apparently have no other way of reaching, which isn't in the top 3 of primary use cases for X). Anyway, I was speaking in the aggregate. X (so, post Elon) has been bad for society as a whole and if that's not an objective statement then it is at least close enough to make no difference. I suspect any arguments to use it anyway probably boil down "but...I like it". And since we live in a free world that's a good enough argument to have. It is not, however, harmless.

That's reversing the argument. I'm not saying quitting X is bad for X, I'm saying quitting X is good for you. Nobody's completely immune to whatever that sociological experiment is turning into and staying on X is likely to influence your ethics, morals and standards in an objectively negative way.

Maybe we're disconnecting. Cookies are just a standardised way to communicate a small key/value set between client/browser and server through HTTP headers. It's not inherently (in)secure, sensitive, etc. There are zero things you can do with cookies that you cannot do without and there are no inherent differences in security, they're just very convenient if you're in HTTP world.

And yes what you said is exactly right; you're allowed to fingerprint a unique user and track data with that fingerprint as the sole unique identifier without any PII legislation (GDPR, CCPA, etc.) compliance issues. You just cannot store any information that allows linking PII data to that fingerprint in either direction. In other words, attribution to a random UUID that just happens to represent an anonymous user is not an issue.

Circling back to the original comment; there is no (good) argument against cookies if you're basically doing exactly what cookies are doing. Umami using it as a USP is, at best, a little odd.

Sure but any probabilistic approach is either relatively inaccurate reduces it's usefulness for this use case, or accurate which raises the same identifiability concerns cookies would introduce. I guess my point was; this has been thought about already. (Pseudo) anonymized attribution is a bit of a solved problem and you can do it with or without cookies. That's mostly a implementation detail rather than a distinguishing feature.

I'm not super invested in this debate one way or the other but arguing a comment should be part of your data rather than documenting what data is contained is a bizarre take on the question. Either be of the opinion it's a data format and comments are just out of scope (and using JSON for e.g. config is just a bad choice), or agree that allowing comments in JSON should be part of the spec since right or wrong it is used for config and other human edited use cases. JSON5's adoption seems to imply people are mostly on the latter side of the fence.

Nah this isn't a big word salad issue. The content is fine. It's just clearly a text written by humans and then rewritten by an LLM, potentially due to the original author(s) not being native speakers. If you feel it's natural English that's fine too ;)

It's neither. I remember them moving to the cloud but apparently they moved to Google/Oracle (the latter making this article particularly interesting btw). As per the relevant press release : "It’s understood that Uber will close down its own on-premises data centers and move the entirety of its information technology workloads to Oracle and Google Cloud."

Their entire setup seems somewhat suspect. I can't think of any technical justification for needing 21k instances for their type of business.

Impressive numbers at a glance but that boils down to ~140qps which is between one and two orders of magnitude below what you'd expect a normal MySQL node typically would serve. Obviously average execution time is mostly a function of the complexity of the query but based on Uber's business I can't really see what sort of non-normative queries they'd run at volume (e.g. for their customer facing apps). Uber's infra runs on Amazon AWS afaik and even taking some level of volume discount into account they're burning many millions of USD on some combination of overcapacity or suboptimal querying/caching strategies.