The domains are totally different and lead to different tradeoffs. An internal marketing data platform can justifiably be optimised for iteration speed and quick scalability over availability.
Most of the gamers I know who are not in the tech space are very against AI, especially if it is being used for stuff that is more on the art side. Anything that displaces "game industry workers" is viewed as a bad thing.
I personally don't mind AI use to write code, and while I haven't seen AI art that conveys much in me, I'm open to the idea that it could be used in interesting ways.
They are against AI code now as well. AI anything is toxic to the general pop, which is why some companies are asking not to be forced to reveal their use of it.
The real issue is that people's livelihoods are being automated. This can be fixed with sensible policies and things like universal healthcare and universal basic income.
There are some additional policies I'd like involving AI automation gains compensating workers losing their jobs to AI, and laws making all AI open-source due to their nature of being trained on public data.
With those policies, it wouldn't hurt so much to lose your job to AI. I would think there would be leas hostility at that point.
I must say it is all very confusing to me. If someone likes a game, why does the origin of assets matter? It is the same thing I see with crypto. It is just code and data. People putting value on it doesn't change what it is. Yet now there are all these regulations because enough people assigned enough value so the code suddenly becomes regulated.
AI is just code and data. It doesn't make sense how offended people are by it. No one is being for to use AI. Sure, it is changing how our society functions, but this isn't the fault of AI, it is the fault of bad systems. We have bad economic systems, bad political systems, bad leaders across the board, and bad distribution of ownership. AI isn't causing these problems, it is just amplifying them.
To me it speaks to the fact that Rebble is not really an organization that is in a position to actually negotiate a long term deal with another company and go through all the trials and tribulations that involves.
That is not a criticism of them nor is it surprising, their responsibility up to now has been to maintain a core set of open source software. A loosely structured control structure is entirely appropriate for that task. But it really does not work when instead of bringing one person representing the company to a negotiation, you have half a dozen people who all have their own thoughts and levels of interest and commitment, some of whom will resort to community action if they don't like something about the process.
They also backed down from their ludicrous position that they are acting as protectors of other people's watchfaces being downloaded in bulk by a particular company they don't like, whereas they are totally fine with the watchfaces being publicly available for general use. It clearly reads as them trying to clutch control of the one thing they haven't open sourced.
Rebble contributors did have a legitimate gripe, which is that they were lead to develop some additional software under the idea that there would be an agreement at the end of the day. But the Rebble Foundation's response to this was totally immature and irrational.
I agree with what Eric said in his follow up, which is that it is quite concerning to engage in a partnership with an organization which reacts like this as part of a negotiation process. God knows I wouldn't, and it doesn;t surprise me that an alternative solution was found.
Well said and exactly my thoughts on it as well. Eric has done more than he really had to, and it is unclear to me what rebble really wants/is positioning for.
You are not really factoring in all the work on the hardware, much of the software, and the entirety of the financing, which is being done by Eric and the Core Devices team.
If Rebble wants to take the risk and put out a smartwatch, there is nothing stopping them. Infact all of the open sourcing work Core Devices has done gives them a good starting point.
Ok, I think the verdict on the "JavaScript for everything" experiment is in. It was already resolved long ago (in my opinion), but this should convince any stragglers. Let's accept that the one thing JS is really great for is DOM patching, and move on.
Going forward, use WASM if you really want to make an SPA (and think about that choice), where the source language is not something that ties into the JS dependency ecosystem. Ban it and burn it with fire for anything on the backend, for christ.
If you are considering event sourcing, run an event/audit log for a while and see if that does not get you most of the way there.
You get similar levels of historical insight, with the disadvantage that to replay things you might need to put a little CLI or script together to infer commands out of the audit log (which if you do a lot, you can make a little library to make building those one off tools quite simple - I've done that). But you avoid all the many well documented footguns that come from trying to run an event sourced system in a typical evolving business.
reply