Just my personal taste though; I don’t mean to knock LLMs.

I could be wrong though —- could you be specific? I don’t want to misinform anyone…

I clarified why I mentioned fork().

I tried to explain the difference between registers and variables.

I’m not trying to show off or bring anyone down… I just like to help people. I’m old (my first Linux kernel commit was in 2004). And I could be wrong — please LMK if I made a factual error (I’d appreciate it, honestly).

All good?

Re: fork(), I just meant to be thorough in explaining the environment is copied, not shared by processes. Setenv() only affects the process from which it’s called.

The array size bit in the article: The value 0x220 looks suspiciously close to the size of the old environment in 64-bit words (0x220 / 8 = 68), and this value was written over the terminating NULL of the environment block…

HTH!

1. If a process crashes and dumps, be sure to look at the system log of the cause (e.g. SIGSEGV, OOM, invalid instruction, etc.)

2. Be certain you’re looking at the right core dumps — I believe UID 1000 just means posix UserID (which is unrelated to a PID), though I don’t use containers.

3. Stay focused on the right level of abstraction — memory model details are great to know, but irrelevant here.

4. Variables do not correlate 1:1 with registers, except in C calling conventions. The assumption about x20 and a local variable is incorrect, unfortunately.

5. getenv() and setenv() do not work as implied in the post. When a process starts via execve(), the OS/libc constructs a new snapshot of the environment, and cannot be modified by an ancestral process. It’s a snapshot in time, unless updated by the process itself. When a process fork()s, the child gets a new copy of the parent’s environment — updates do not propagate.

getenv() is thread safe and reentrant. You don’t use an environment to pass shared data — setenv() is generally used when constructing the environment for a child process before a fork(). See man environment.

6. FWIW, ‘char** env’ is a null-terminated array of pointers, so dumping memory from *env (or env[0]) is only valid until you hit the first NULL. The size of the array is not stored in the array.

I hope this helps! And apologies if this is redundant — I read so many comments; mostly variations of “the problem with getenv is x”, but gave up before reading all of the (currently) 168 comments.

I mean, the Wally paper contains enough information to effectively implement homomorphic encryption for similar purposes. The field was almost entirely academic ~12 years ago…

I miss talking shop on HN. Comments like that are why we can’t have nice things.

If the latter, please note that this feature doesn’t actually send a query to a server for a specific landmark — your device does the actual identification work. It’s a rather clever feature in that sense…

> The client decrypts the reply to its PNNS query, which may contain multiple candidate landmarks. A specialized, lightweight on-device reranking model then predicts the best candidate…

[please correct me if I missed anything — this used to be my field, but I’ve been disabled for 10 years now, so grain of salt]

From a cursory glance, the computation of centroids done on the client device seems to obviate the need for sending embedded vectors of potentially sensitive photo details — is that incorrect?

I’d be curious to read a report of how on-device-only search (using latest hardware and software) is impacted by disabling the feature and/or network access…

It even suggests cloud providers did contribute, and uses bad data (git commits “by employer” w/o dataset) that basically contradicts their argument.

I may be biased, as I saw Amazon doing exactly what this article claims “maybe they weren’t”. But statements like this seem intentionally misleading, and easily disproven:

“Distributing a source-available version of MongoDB could be seen as a loss-leader strategy to reach developers that the company wagered did not care about open-source.”

MongoDB is still “source-available”, and on the same GitHub repo I’ve used since 2010. The SSPL only impacts cloud-providers, and has exceptions for cloud providers who release their source code.

The OSI doesn’t get to define open-source. Neither do I, but at least I was part of the community for ~20 years…

If you disagree, could you indicate the relevant text?

If you make the functionality of the Program or a modified version available to third parties as a service, you must make the… SNIP …programs that you use to make the Program or modified version available as a service…

I’m eliding for clarity, but the NAS doesn’t make the program available as a service. The code that accesses the file system on the NAS to offer your service? Probably need to release code that calls fread/fwrite/NtFileX in your infrastructure code.

I get that it sounds vague and everything, but the FAQ also clarifies none of this applies unless you’re competing and targeting third parties. If you’re one of the few companies who want to do that, your legal team can formalize the line of demarcation.

Apologies, I hate defending the SSPL, but I can’t think of any better way to stop the monopolistic and EEE practices against open source projects. If anyone has a better solution to protect the freedoms of open-source developers, please, please publish it!

In fact, you can build a similar service and offer it within your organization (and subsidiaries), and you still don’t have to release anything. The license only applies to companies like Amazon if they offer MongoDB as their own service (DocumentDB).

I know that’s a bit tangential, but hope that helps a bit?

FWIW, just realized it doesn’t even apply if deployed internally (within an organization and/or subsidiaries)…

It was rough seeing huge cloud providers profit off open source projects without giving anything back. When they offered competing hosting services with no value added (well, past “integrated billing”), no contributions or innovation, and drove their new customers to the documentation and libraries of the companies backing these projects, they crossed a huge line.

And it’s not just MongoDB. Or Elastic. Just look at all the “services” AWS offers, and note how many AWS actually invented or even contributed to…

Monopolistic practices forced a lot of companies to either shut down, or find a way to survive. I’m glad MongoDB decided to use the SSPL instead of shut down like so many others. I’m glad they’ve continued to thrive.

Changing to the SSPL isn’t ideal, but it only impacts people who want to sell hosted versions of the software (not users, self-hosted or otherwise). For those infinitesimal few selling hosted versions of the software, it doesn’t even stop them from doing what they want — it just stopped the monopolies from destroying something a lot of people dedicated a lot of effort to... That seems like a pretty amazing feat to me, given the reality...

I wish the OSI wasn’t so successful painting users of the SSPL as somehow betraying the open source community. And I wish the SSPL wasn’t necessary. But until there a better option, I’m ok with the SSPL…

Again, I say this with all due respect, and this is just my opinion. Corrections and new perspectives welcome!

Also, if you bought something closed-source to sell MongoDB as a service, why isn’t it realistic to buy a license?

Your suggestion of a monopoly in the DBaaS space seems to preclude the existence of other databases… Or am I misunderstanding?

I’m not sure what you mean by “IT is a business decision” — could you elaborate?

-edit- P.S. I’m trying to be supportive here; not trying to take anything away from what you’ve built with FerretDB! Honestly, there’s room for so room for innovation in this domain, and it’s nice to see new projects…

I mean, I wouldn’t recommend running a ReplicaSet on the same host on any production host (it defeats the purpose), but for testing, I’ve run a sharded cluster w/ 3 replicas per shard…

Happy to try and help!

The OSI looks and sounds like an authority on open source software, but their entire strategy is legal, political and quasi-philosophical. I get how easy it is to be mislead by them though — they’re good at spinning things and rewriting history.

https://en.m.wikipedia.org/wiki/History_of_free_and_open-sou...

If you want to offer MongoDB as a service, you can still do so free of charge, as long as the service infrastructure is also made openly available, right? And if you don’t want to make the source available, you can purchase a license and do so, right?

Furthermore, if you’re using MongoDB, be it self-hosted, with a vendor, or even some proprietary database that implements the wire protocol for compatibility, you’re likely using MongoDB-developed clients/drivers, which are Apache 2.0 (“OSI-approved open source”).

So it seems like the only way to be locked into a vendor is if you’re using MongoDB drivers to connect with a 3rd party database that doesn’t fully implement all functionality of MongoDB in a compatible way… Right?

I could be wrong, but as someone who contributed to MongoDB as an open source project, and was later hired by MongoDB based on said contributions, it kinda hurts to see the OSI’s “MongoDB isn’t open source anymore” campaign work so well.

That said, I sincerely wish the team behind this project all the best!

My complaints aren’t against anyone in the open source communities I’ve known and loved. Just this self-important legal organization that acts like it controls (and even gets to define) open source software.

P.S. I left MongoDB in 2015 due to a neurological disability, but it was one of the highlights of my career, with so many kind and brilliant people. But it’s also been a while, and my brain doesn’t work so well these days, so please correct me if I got anything wrong!