Interesting project but whoever decided "forM" is a good name for a language keyword should be made to gurgle Tabasco sauce for a few minutes.
HN user
remon
Gotta be honest, this isn't very inspiring : "Wait, division by zero is zero, really? Yes. But focusing on this is a bit like focusing on the color of the seats in a spacecraft."
Ah thanks for the insights and references. And yes I'm still curious why this definition of div/0==0 is needed in the context of Flix
"Controversial: Flix defines division by zero to equal zero." Wait what. Can I read up on the motivation somewhere?
Curious if anyone can weigh in on why Flix requires a developer to explicitly mark a function as pure. I'd imagine in almost all cases this can be derived through static analysis.
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.
In what way? Both need a constitutional change for every country this distinction is relevant for.
That currency has a fixed exchange rate to the euro. Any perceived sovereignty benefits are fictitious.
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.
Some of these make "lightweight" a bit of a stretch. Per-pixel iterative shaders are probably a performance/battery risk for most applications.
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".
Imagine still using Meta products in 2025.
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).
Honest question; what does OSI actually do? I am involved with a number of OS projects and not once has OSI come up in any context, be it compliance, governance, education and so on.
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.
At this point you're actively contributing to the death of free speech if you're still active on X in any way. There are no excuses to use it still if you have any sort of functional moral compass.
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.
This almost always resolves to "not using actual cookies, but exactly the same privacy and security paradigm as cookies"
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.
This. Thank you for verbalizing what I struggled to.
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."
It's sort of funny how can you immediately tell it's LLM sanitized/rewritten.
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.