janosdebugs

Here's the problem: I can do a SEPA transaction using online banking (with a Google-enabled phone) or by walking to my bank personally.

I wish that transparency and security were a selling point in gaming, but to me it doesn't seem like it. People will install all kinds of stuff and give them administrator permissions without a second thought. Anti-cheat eating itself into the kernel seems to be perfectly normal for most people. It's an entertainment product and people don't want to be inconvenienced for the most part.

Regarding the development costs, I'm not exactly an expert and I have never worked in a game studio (apart from the company my wife and I are running), but let's take StarCraft 2 for example. If you were to have the engine, but not the art, you could likely easily develop a very capable multiplayer RTS game. Heroes of the Storm was developed out of a StarCraft 2 mod[1]. As another example, Stormgate[2], made by ex Blizzard devs, is getting a whole lot of press coverage for their netcode. It stands to reason that a good engine and netcode are very real competitive advantages in the RTS space. Other game types, such as a walking sim or an adventure game will have a lot less "secret sauce" in the code and more in the art, voice acting, etc. (The Invincible[3] is great in this area) so the code/data split would likely heavily depend on the type of game. (Games can also become very messy between art, visual scripting, engine settings and code, which is what makes releasing the code separately tricky.)

My wife and I are (slowly, next to the day job) working on a Python programming/learning game and hopefully we'll manage to make a clean split between the engine and the art because it would be important for modding. However, I wouldn't feel comfortable releasing it under an open source license because it would cut off a potential source of revenue to license it to educators wanting to make their own challenges and courses. Maybe later we'll figure out that the base game makes enough money and it doesn't matter anymore, but it's really hard to predict success. As a game dev I would really like to make it possible, for example, for game archivists to do their work legally, for people to legally backup and rebuild their games for newer operating systems, or for their kids to be able to inherit their games[4], but carving out specific exceptions, especially for unknown future use cases 10-20 years down the line is exceptionally hard and I'm also not a lawyer, so for desktop the Steam Subscriber Agreement is governing our PC releases for now.

[1]: https://starcraft.fandom.com/wiki/Heroes_of_the_Storm

[2]: https://www.pcgamer.com/an-upcoming-rts-will-incorporate-the...

[3]: https://store.steampowered.com/app/731040/The_Invincible/

[4]: https://arstechnica.com/gaming/2024/05/after-you-die-your-st...

What payment method would you recommend for paying mortgages, utility bills, and company expenses?

I live in an EU country and I, in fact, cannot use online banking without a Google-enabled Android or an iPhone. There is exactly one bank that offers a desktop authenticator, but we had a really bad experience with them when we tried them for a year.

I've done a fair bit of open source work, but the best I could come up with for games is "source available" where you can get the code to recompile for yourself or mod it. (My wife and I put up the source code of our first game as a DLC on Steam as an experiment.)

Re only code: Game engines often tie code and data together and the code without the data won't even compile in many cases, or you won't be able to produce a new dataset because documenting the required settings is a monumental task.

Finally, there is no real benefit to open sourcing a game if you want to make money. There is no complementary product or service you can sell with it. Reviewing and incorporating community fixes requires work and potentially legal review as not everyone in the modding community is also necessarily well versed in IP law. All these things need funding which is not a given if the game is open source in any meaningful way. If a game is truly open source, a less than ethical company with a bunch of cheap labor can go and undercut you, so there is an incentive to make creating an alternative build as hard as possible, defeating the entire idea of open source.

I would like to be able to release on an alternative storefront so people who want to degoogle their phones, but F-Droid's policies (most known alternative) make that impossible. (To be clear, it's a perfectly legit choice, I just wish there was a meaningful alternative to Google.)

In this case the software in question was a game. I have not seen any visble business models for truly open source games under the acceptable licenses for F-Droid. There are source-available games, but that would not be enough in this case.

I think the main issue may be how much up-front investment games need that would never be recouped with an open source license, but I'd love to be shown an example to the contrary.

No tracking? Providing an alternative? Not strengthening the Google-Apple duopoly on the mobile phone market? I was looking at it as a platform to publish an app on, which the open source requirement stopped dead in its tracks. I didn't have a viable open source business model for it at this time because it was a straight "customer pays money, gets software" deal with no tracking or other nonsense.

As-is, F-Droid will not be an _alternative_, it can, at most, be an extension to the Play Store.

I think policies[1] are blocking F-Droid more than anything from being a viable alternative. A bank will likely never release their app as open source, nor will any of the big authentication vendors. This means that you cannot completely replace the Google Play Store with F-Droid if you have to use any of these, you can only use it as an additional store, at which point many won't be bothered.

[1]: https://f-droid.org/en/docs/Inclusion_Policy/

My experience is that the more experienced you are the less benefit you will see from coding asistants. If you are at the beginning of your career and writing a simple for loop requires serious brain power, an AI coding assistant will seriously speed you up. The same goes for task complexity. Mainstream tasks will work better than specialized ones simply due to the lack of adequate training material.

Given the amount of work required to onboard your own IP range[1], this is almost certainly untrue when it comes to total cost.

[1] https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-byoi...

As far as I can tell, yes. If cookies (or other means of storing data on the users computer) are strictly technically necessary, and no data collection takes place as a legitimate interest, and you do not process data requiring consent, neither the ePrivacy directive nor the GDPR requires you to create a cookie banner. Needless to say, I'm not a lawyer and this is not legal advice.

On a technical level this would likely mean turning off access logs and other tracking mechanisms. (IP addresses are considered personal data last I checked.)

My wife and I run a small (2 person) business in the EU. The largest hurdle was finding a hosting provider (VPS) that wouldn't transfer data outside the EU so we wouldn't have to add SCCs to our privacy policy. As a business owner, I'd say the balance is still positive, it forces some self-reflection on data gathering practices.

Not sure about the "hosted on US soil" part, if you are a US company, the data gets transfered anyway when you view it.

How would this work when raising a kid? It's not just about making a collection of cells, kids need a lot of attention and affection to develop healthily.

I wonder how accurate this assessment is since the Linux Foundation is a non-profit.

You can do a lot of dark magic with CSS or SVG too. Specifically, CSS has calc too. Website haven't just been documents for a long long time and basically nobody is going to bother keeping any computation in the JS space only.

The NVDA screen reader reads this text as: "This is my email frame link email us." That is by no means equivalent to actually seeing the email address. I found that HTML entity encoding every single character of the link takes care of any spam problem already and is much more accessible.

It also doesn't block well-known libraries. Using this addon sounds like a really good way to have a bad time on the Internet. By the logic of this, why bot block websites which have non-free content or other supporting files?

The whole premise of a website is that the owner gives you a licese of some kind to view it. Blocking only a technical part of it makes no logical sense. It's not like you are going to take the JS code under a free license that is likely dependent on the HTML structure under a non-free license and do stuff with it.

The problem is, we don't know. I've seen PRs that could be curious students, or it could be a first try to see if we are paying attention. It's really easy these days to produce a halfway decent looking PR for someone in their first year of uni and my worry is that an increased volume of low to medium quality contributions will lead to maintainer fatigue. Depending on the project, that may be the point where pressure can be applied to share maintainership.

Having done a little bit of work in the area[1], I think you should publicly document exactly what those best-practices are. Are the workloads running in a networkless container? Do you limit IO? Do you limit disk usage? Answering these in detail would help you gain customer trust on both sides.

[1]: https://containerssh.io/v0.5/reference/docker/#securing-dock...

I don't think a framework can make a blanket statement about accessibility unless it's a negative one. Even if the framework does everything right, user error can completely break accessibility inadvertently. All such a statement does is give people a false sense of security that they ticked the "accessibility" checkbox, leaving people dependent on a screen reader, Braille device, with a motoric navigation difficulty, etc. completely stranded.

I have a habit of turning on NVDA, Android Talkback, etc. quite frequently to test when I'm working on a website, but even then, there are big differences between screen readers and a blanket statement of accessibility is completely worthless. People frequently tell me that something I tested on several Windows/Android devices doesn't work on Voiceover despite following the relevant standards. It's like browsers in the IE6 era, you need to explicitly test with as many as you can. And yes, it sucks.

Atlantis has an issue open for OpenTofu support [1]. This might be something to look out for.

[1] https://github.com/runatlantis/atlantis/issues/3741

People have already done this by implementing functions as data sources, which also get recorded in the state unnecessarily.

Could you please elaborate on your comment? Do you mean you tested this tool and it's not accessible, do you mean you are concerned about the tool not being accessible, or is there a problem with the website linked? The reason I'm asking is because it is possible to make a 3D website accessible and I'm curious if you have any more info on this particular tool.

Thanks, I was looking at the wrong store page. Don't mind me.

Edit: I think this explains a fair few things:

> This EULA was created by eulatemplate.com for Reentry - An Orbital Simulator, with modifications and additions by Wilhelmsen Studios.

To the game dev, if you're reading this: you may want to read the Steam Subscriber Agreement. It may already cover what you want and you may not need an EULA, especially since this may be unenforcable in many parts of the world.

Strange, I can't see an EULA on the store page, did it get removed?

My bad, I didn't know that that term was so established.

To me, what you are describing doesn't constitute a drive-by PR. You used the software, saw a bug, fixed it. This is the very best part of open source. (I hope the text in its entirety made that clear.)

The kind of PRs I'm talking about are from people who have never and likely never will use the software, but want the badge of questionable honor of having contributed to a well-known project. The only reason they looked at the code is because they saw it in the news or someone told them to "go contribute to open source" to help their career. I don't mind a junior going to fix a but that they themselves found and know how they want the software to work. I do mind if someone goes randomly looking for something to contribute without understanding the software, how it's supposed to be used, and proceeds to expect maintainers to hand-hold them through the process of getting their contribution in so they can put it on their CV or satisfy a teachers assignment.

I think what's rarely spoken about is the fact that each PR needs maintainer time. Maintainers are typically few and their time should be used to further the project, not for personal gain.

Open source can be a wonderful thing when people come together and build something cool. Unfortunately, maintainer burnout has been a thing recently and part of the reason is that IT and open source are seen as a way to get a lucrative job. Some (and by no means all) people disregard the consequences of their actions to get there.

Juniors should absolutely be encouraged to either build a project on their own or collaboratively, or to start by joining the community and listening before starting to write code. This is something that's lost on many and "drive-by PRs" happen a lot on high profile projects from people just wanting to say "I'm an X contributor" on their CV or get a coveted t-shirt and never come back again.

These drive-by PRs come in a variety of forms. Some are just absolute nonsense, some rename things for no good reason, some refactor a part of the code that nobody asked for, and some do add a tiny bit of value, but are extremely bad quality to the point where rewriting it would take less time than going through several (dozen) review rounds explaining to the budding contributor how to write code. (Or how to even use git. Rebasing a PR is a problem for a lot of people, for example.) Maintainers of open source projects typically didn't sign up for being mentors to people who barely know how to code.

More than that, these random PRs increase the noise level in the project by a lot and take away time from the contributors, junior or not, who put in way more effort that a drive-by PR author did. Leaving PRs to rot is bad because they will start having conflicts, so not reviewing them is not an option. Each of these PRs needs to be properly reviewed because they have a maintenance cost later that rests on the shoulders of the maintainers, not the contributor. Each PR carries the risk of someone introducing malicious code. Answering these PRs politely but firmly also takes quite a bit of effort.

Yes, juniors should be encouraged, but realistic expectations should be set. Contributing code to a highly complex project probably isn't going to happen. They should try and contribute to small projects that they themselves know and use. That way they understand what is good an what is bad for that piece of software. Also, they should "read the room" and the contribution guide before jumping in. The best way to start is with small things: reporting issues, fixing docs bugs, and once they are comfortable with the workflow, move up to writing code.

Unfortunately, communication is hard and getting this message across ("be considerate") to the right people is harder. This post has a good analogy for that with the bricks.

I wish I had an answer to that, but I don't know. I only worked on projects of comparable size in Go, Java and PHP. Java was maybe the best for abstractions (big surprise), but it really doesn't lend itself to system-level stuff.

How would you imagine that working? I think a lot of people would love that, but I have seen very little specific so far.