What problems have you had with joins?
I have this comment in one of my projects:
```
It is required to mark left-joined columns in the query as nullable, otherwise SQLx expects them to not be null even though it is a left join. For more information, see the link below:
https://github.com/launchbadge/sqlx/issues/367#issuecomment-...
```
Did you have other problems beyond this, or are you referring to something different?
The issue above is a bit annoying but not enough that I'd switch to an ORM over it. I think SQLx overall is great.
I've always liked the concept of ECS, but I agree with this, although I have very limited experience with Bevy. If I were to write a game in Rust, I would most likely not choose ECS and Bevy because of two reasons: 1. Bevy will have lots of breaking changes as pointed in the post, and 2. ECS is almost always not required -- you can make performant games without ECS, and if with your own engine then you retain full control over breaking changes and API design compromises.
I think all posts I have seen regarding migrating away from writing a game in Rust were using Bevy, which is interesting. I do think Bevy is awesome and great, but it's a complex project.
I've been working on https://asterai.io -- a platform for developing, running and managing AI agents.
It lets you create multiple agents, configure them via the web console (such as LLM parameters and system prompts) and manage their plugins and functionality.
The system is fully plugin-based, where each plugin is a WASM program that exposes functions/tools that the agent can call, and can also hook into the query lifecycle. Because plugins are WASM, they can be written in various languages such as Rust, Go, TypeScript etc. Plugins can also act as libraries, which is possible because of WebAssembly Components (a great piece of software!) -- so you can dynamically call functions from other plugins within your agent, and you get type support for your chosen language too (with codegen via WASM Components tooling).
More recently, I've been working on an SSH server for agents. The idea is that you can add public keys to your custom agent and then SSH into it to talk to it easily from terminal.
If this sounds interesting, feel free to join our Discord! The project is still new and feedback is highly appreciated. http://asterai.io/discord
That's a good question. Currently, there is one way to do it. The client querying the agent receives JSON-encoded values that are returned from plugin function calls made by the agent. These values are received alongside the agent token response stream (via SSE). So plugins can essentially emit events that the client can forward to the UI application, such as to click a button etc. The limitation with this is that there is no built-in way to send a success/error status back, it's one way only. It works well for actions that are infallible such as simple UI actions.
The client here would also need a way to interact with the target program of course, e.g. from a JavaScript browser you can click buttons and manipulate the DOM, or from a VSCode Plugin you can interact with the editor etc.
It's definitely something that can be improved though! I've been thinking about some type of MCP interoperability that could maybe assist with this.
There's nothing wrong with releasing software under a license that allows contributions but disallows commercial use, which is what Cyph was attempting to do:
> We're a small startup with a significant amount of time and money invested into the development of Cyph. We recognize the need for anyone to be able to review the code and verify our production build against it from a security perspective, but at the same time it would be problematic if an unrelated third party could just stand up their own instance of Cyph and directly compete with us at this stage. We would be much more inclined to fully open source Cyph at a later stage of the business.
I disagree with the philosophy of forbidding any contributions just because they are not fully open-source for commercial purposes.
This seems like a very common scenario for software that is almost "open source" except for not allowing commercial deployments. I would be surprised if there is no existing licence to cover this use case, but it will not be fully open source of course. Which again doesn't mean that all contributions need to be forbidden.
There are bunch of well known source available licenses, such as BSL 1.1 (https://mariadb.com/bsl11/). No need to invent a new license that gives more confusions.
ianal but I think it's done this way to allow for some latitude in interpretation. gives licensees the ability to get things going, eg as a private beta, and seek a commercial license when they're ready instead of worrying about that up-front. also gives both parties the ability to argue whether a particular situation counts as production use if the dispute ends up in court.
That's unfortunately a very narrow sense. In fact, the most common definition of open source implies open governance because of the wording. The exact definition will vary depending on exact authorities (OSI vs. FSF), governance transparency, relationship with patents, treatment of non-software contents and many others. This ambiguity is why I never say "open source" alone, at the very least I say F/OSS to be clear. Maybe I should start saying something more soon.
Open Source is a specific thing.
Free Software is a specific thing.
When I say Open Source I mean Open Source. When I say Free Software I mean Free Software.
The two are not equivalent.
Open Source is defines by OSI.
Free Software is defined by FSF.
(The clue is right there in the name.)
Feel free to refer to F/OSS if you want to refer to both. You definitely should be saying something more if you wish to include other models.
>> In fact, the most common definition of open source implies open governance because of the wording.
eh? I disagree with this. Open Source does not imply Open Governance. I'm not sure any license discusses governance at all. Organisations have governance rules, not (most / all ?) Licenses.
Your reading of the license name to imply some form of governance is, in my opinion, unwarranted.
> Open Source is a specific thing. Free Software is a specific thing. When I say Open Source I mean Open Source. When I say Free Software I mean Free Software. The two are not equivalent.
The hint is that you have slightly changed your terminology there, intentional or not. The capitalized terms "Open Source" and "Free Software" indeed have specific definitions. But generalized and thus non-capitalized words "open source" and "free software" had been fuzzier, and pretty much all conversations about F/OSS deal with that sense (the "common" sense hereafter). In fact the notation F/OSS is an acknowledgment that both words are, nominal definitions notwithstanding, used as if they are synonyms to each other.
> Open Source does not imply Open Governance. I'm not sure any license discusses governance at all.
Under the "common" sense, they are heavily related and this has been one cause of maintainer burnouts. Again, I don't like the term "open source" (capitalized or not) for that reason too.
> But generalized and thus non-capitalized words "open source" and "free software" had been fuzzier, and pretty much all conversations about F/OSS deal with that sense (the "common" sense hereafter).
You'll have to provide some source for this argument. The very fact that we're having this conversation means that the fact that "Open Source" and "open source" are different things is, at the very least, controversial.
"Free Software" has been a controversial term since the late 80s, I'll give you that, but the only confusion it ever brew was between "free as in freedom" vs "free as in free beer", and people thinking the term "free software" means "software I don't have to pay for" is rather common.
But, as I said in another subthread, this whole mess about the meaning of "open source" only started recently when people started overloading the term to mean something other than "whan has been defined as 'Open Source' by the people who coined that term in regards to software in the first place" (i.e., the OSI). There was no confusion 10 years ago.
Even 10 years ago, it was already very common to assume that "open sourced" softwares should necessarily open their development process. I have several first-hand accounts and tried very hard to decouple them to no avail. And this confusion was built into the origin of that term; esr's highly influential The Cathedral and the Bazaar [1] exactly suggested that after all. It is no surprise that the term became even fuzzier by now.
I feel that applying "common sense" to legal documents may lead you into trouble.
That aside, there are as many governance models are there are licenses - and they two are not linked in any way. I've certainly seen plenty of Open Source projects which are not in any shape or form Open Governance.
> I feel that applying "common sense" to legal documents may lead you into trouble.
Of course IANAL and we are not even talking about the legal aspect here, but legally speaking to be pedantic, the common sense does play a role when there is a reason to believe that some party failed to understand a deeper legal meaning. You can't arbitrarily replace any word in legal documents provided that definitions are given in advance, after all.
> That aside, there are as many governance models are there are licenses - and they two are not linked in any way.
Nominally not, but they are linked in the way that some sort of openness is heavily expected for most "open source" projects.
There is a difference between a design flaw and an implementation flaw though. It seems like for PDFs, those are mostly design flaws, e.g. doing potentially malicious silent tasks in the background without the user's knowledge. Although it could be argued that the OS should be the component guarding against those types of attacks instead of the PDF implementation.
The way you word it, it's as if they were a bunch of tech bros putting microchips in people's brains and running a remote debugger for fun, in a completely unregulated environment.
The people that accept these kinds of implants during a "prototype phase" are usually in a very bad position, so the risk is worth it for them, as the technology can drastically improve their lives.
It seems to me there is a contradiction there between "Apple’s positive effect on my life should not be underestimated [...] and I should love apple for that" and "Apple is not a real person and not worthy of your love".
People, including those you love, can also do things you don't like.
I'm not sure if I have a point here but the line of reasoning there doesn't quite make sense to me.
Apple tries to convince people it isn't a brand, but a lifestyle or an identity. So if you identify as part of this lifestyle, you must love Apple, or you don't love yourself. Some take it a step further and hate Apple's competitors. Perhaps this is related...
Part of that story of course is their execution, thoughtfulness and great taste to pick “just the right” technical ideas.
MacOS X Panther with Aqua’s basically artifact-less and butter smooth postscript based rendering capabilities, the beloved (!) BSD shell I could drop into at any point. All of that in 2003 … a true OS from the future and for the masses!
Battery runtime of PPC 7xx also was stellar at the time. AFAIR nothing could compete in relative comparison.
Humanistic and design oriented engineering at an excellent level and consistently so. Of course I aspired to be exactly like that as a professional!
Too bad they have strayed from that in many ways over the years. They IMO mostly still, but only barely hold the functional high ground these days.
There are things you can love. It might sound silly unless you've climbed mountains in the winter, but I love my ice axe. It's let me go places I'd never be able to go otherwise.
That said, it is different from the love I have for people. When my son was young and would treat people poorly over things, I told him there are three kinds of things we can love: people, places, and things. When there's any conflict, the priority should almost always be in that order.
I think what is meant by "should love" is that it would be natural to, or for our emotions to prompt for affection towards, Apple for its good deeds. but the point is to resist that because Apple is just an emotionless business entity.
It's rather clearly worded and I see no contradiction.
Meanwhile in the real world we often find new deposits of gold, and if we ever make it to space presumably we’ll find a whole lot more of it (perhaps infinite amounts).
but until space we have a finite amount of gold. Current known gold mines will be mined out at around 2030 and there is about 30 - 100k tons of gold left in unexploited gold.
Around 30% of known gold in the earths crust is accounted for. Nations included in the "BRICS Meme" have been purchasing large amount of gold and would like to see us return to a gold standard for monetary and policy reasons.
The devices can ship with an embedded hardware security module that holds a private key. The private key has its public key whitelisted by Rolex, and can be used to sign a message transferring the ownership to the current owner's public key. If you can do this transfer action, the device is legitimate. Of course you'd need to check that the public keys/addresses match Rolex's.
Synchronisation is the hard part. I suppose there are a few different ways to do it. One way would be to use a hardware that holds a private key in a secure chip, and whoever has access to the physical watch can sign a message with that key to point to an arbitrary address. This can then be submitted to the blockchain.
Confirmation is easy, as the blockchain takes care of that. It would be emitted by a verifiable/trusted public key. If the address is not Rolex's address, the item is fake.
