864 karma · joined June 18, 2010
If you want to publish on consoles you need to pay someone who ported the engine to the console you want to target (or port the engine yourself). The code can't be open source because of licensing issues.
From: https://docs.godotengine.org/en/stable/tutorials/platform/co...
Isn't the information still there, inside the black hole, but just not retrievable from the outside?
Proper abstraction is the one thing you need to get right, and django makes it so easy to make clean separate modules work together using a shared base and way of working (user model, groups, permissions, urls, signals, etc.).
One day you'll need to use your payments logic to sell something else, embrace it.
For people with an established codebase, not wanting to go all in on lambda/serverless, or wanting to use existing frameworks, the trade-off might be worth it.
In any case, I don't know of any one other framework with a remotely comparable admin interface in terms of capabilities and usability out of the box, so there's that. I'd be happy to be proven wrong.
For everything else (even async with channels), as long as you don't stray too much from the django way, you'll be immensely rewarded by how neat and easy to navigate even large applications look.
Turning off when charging sounds like a way to prevent someone to follow through with the shockingly brilliant idea of doing that while plugged in to the wall socket.
Starting from the time mechanics shown in, e.g., Interstellar. If when you're near a massive black hole time passes differently (more time passes away form the hole, so to speak), couldn't it be said that the regions near and far the black hole are drifting apart in the "time dimension"?
If we take the black hole to be an extreme case of that, isn't the black hole a region that is drifting away so "fast" that light isn't fast enough to reach "us" on the outside?
In that case, there would be no paradox, right? Whatever is inside the black hole is still there, but with no way to communicate.
When in bed, ready to sleep, I could condition myself to believe the bed was tipping over to the side, up to the point where I would have the reflex of grabbing the sheets to keep myself from falling, similar to jolting awake up after falling in a dream.
I wonder if something could be done to manipulate these perceptions without actually zapping the brain.
Tough problem to solve. I wish we could just accept the fact that people can have opinions different from our own. This is not just normal, but good!
It feels like we're just scaling up small town feuds into a global phenomenon, e.g. "I won't set foot in X or Y's restaurant. Don't you know they buy their cabbages from NextDoorVille instead of buying them from Old Whitney down the street?!"
Having an "open door" and publicly stating an unpopular opinion is, sadly, broadly incompatible.
Your app/game won't be 24h on the play store without the apk popping up on some random site, ready to be downloaded.
I don't see a way to do proper sideloading without opening this avenue. Maybe a mac os style notarization scheme, but apple gets a lot of flack for that too.
Congrats on launching! It's awesome to see Cap'n Proto and sandstorm's legacy living on :)
We know about gravitational potential energy. We harness it all the time with dams and whatnot. Generally speaking, when we lift matter high above, we get some of the used energy back when it falls back down.
But when we talk about sending say, a spaceship into space, it may fall on a different planet, with a different gravity (a function of the planet's mass), changing the amount of energy yielded by the fall.
The question is: Where is the energy stored in the meantime? Where does the extra energy, if the ship falls into a heavier planet, come from?
It seems that the energy is being stored somewhere, and that matter itself allows us to tap into that, but is not the place where it is stored. Is there anything I can read to better understand what we know about this?
Like you said, it will most likely have limitations, but it's still one more tool in the belt, regardless.
Never attribute to stupidity what can be adequately explained by opportunity costs.
(Hope I'm not butchering the quote)
The small studios (or one-man armies) are the ones using custom stuff because they have to do it all anyways, no biggie having to do a little leg work to import stuff.
When you're a bigger studio, having to coordinate and support multiple teams with different workflows, the engine and the tools it provides play a much bigger role. The studios with such scale either build something that works for them, or use some existing one provided by others.
I understand that PGP might not be the way to go. I understand that metadata might leak. I understand that every cypher will be broken, eventually.
But what's wrong with trying to send a an e-mail with contents you want no other party than the recipient to read, again, provided the recipient doesn't share it with other people.
For the record, I don't send encrypted mail. UX for these is generally terrible, hard to verify sigs, etc. I am genuinely asking what part am I missing. Is there a fundamental reason that encrypted e-mail cannot work with current e-mail protocols? (but replacing PGP if needed)
I like to believe that means that there are more of the former, and less of the latter.
While this means that yes, "the company" can read your e-mails, it also means that they can't deny doing it if it actually happened. Neither can a rogue employee do it without there being a record, assuming you have accounts properly setup and don't share account passwords.
It may be just anecdotal but their calls work flawlessly, regardless of number of participants, where other apps are just a laggy mess. So yes, their apps are just a means to an end and may be rushed and "low quality", but oh boy do they deliver.
How well that will work in practice remains to be seen. But they aren't simply deprecating all kernel extensions.
I should add that I find myself with a song stuck in my head all the time as well.