agnos.is Forums

You should group your source files by domain, then by feature, e.g. 'src/foo/model' and 'src/foo/exports'. Is serialization/deserialization the only aim of these structures ? If not, that code should definitely be separated, so as to evolve separately from the structure itself. If it is the only aim, the code should also be separated, so you can change your serialization type (e.g. from JSON to XML) without impacting the model. Also you might need another export for compatibility with another software, and you don't want your model file to grow with the 10 formats you support.

You see, we first have to think about optimal tip-to-tip efficiency…

I like the way azure dev-ops do it, they highlight the entire line with a soft color and the changes with a harder one. Isn't not semantic afaik.

Just because something isnt perfect doesn't mean you shouldn't do it. Would you rather OP share links with tracking?

I kinda wanna say... skill issue? But really, dynamic typing is great as long as it fits the problem your solving and you keep your types simple or even just primitive

I once had to use a network API, which was only available for Python, with sensor drivers whose API was only available in C. I just used a file as a buffer to transfer data between them and didn't need any other interfaces. The price paid, was polling.

Until you find they’re using and old version of macOS… or Windows 8.

I’ve been using Netlify for smaller apps, but lately Railway has been my go too. Pretty cheap too and it covers mostly everything you’ll need to deploy app regardless of language or framework. Their UI makes it all very easy to manage with the “nodes”. Both of those services (as do most) give you the option to load environment variables onto the app itself. So the process is normally this: You have env vars you’re using locally like API tokens that you’re putting in your .env during development. Now you’re ready to deploy. Because you’ve gitignored that file locally, you don’t have to worry about secrets being in your code base, but also, because they’re environment variables, you’re framework will see those variables available in the “box”. Ultimately, there’s no difference between having stuff in your local .env and injected by a service during deployment. Just make sure the env var keys are the same in each case. Hope that’s not too confusing. If so, I’m happy to clarify anything.

This isn't a million miles from what bitcoin mining does, although in that case they're trying to find hashes that start with a lot of zeroes.

Not everything can be easily boxed into Boolean categories so no, a mostly true claim is not simply false. You are erasing the key context and nuance to make this foolish absolute statement.

So far it seems the issue could be solved by LDC's magic attribute/pragma system, except it isn't hooked up to the address space system.

Wine and gnu.

Do you think a Proxy would be better in this regard compared to a firewall? I was trying to watch the logs of ufw today and see if I could do something there but the incoming and outgoing connections are A LOT, and I would essentially like to whitelist both per domain and per IP. How much maintainance would this require? I wonder how often IPs change today, but with all the NAT, dynamic DNS and CDNs there around maintaining a whitelist only with IP addresses looks like a nightmare.. Squid proxy with squidguard could be a better option than trying to work with a forewall maybe?

Releasing a v1 would be misleading anyway, even if the language itself is ready for it (it isn't)..... because they use zig in their standard library

Asking whether you’ve tried $simpleSolution the post sounded less like it being an open question and more like it being "do $simpleSolution" to me Instead I’d be offered simple solutions (that I’d tried), but in a condescending way, as though I should have already known better. Checking again, yeah, this doesn't seem to be about asking whether you already tried that.

FWIW SELinux is a standard Linux feature - mostly used by RedHat distros. The difference is the approach to how much a system should be locked down. Desktop systems are traditionally more flexible, probably more for historic reasons, partly due to being used by more technically sophisticated users (or at least assuming users would be more sophisticated). Smart phones, however, were marketed towards the lowest-common denominator users running on a device with many limitations as well. I'm not disparaging these users mind - just stating a fact. So things need to be locked down more. And since these platforms had no legacy expectations on them they could do it however they like (e.g. they can dictate which directories are used for what purposes). The desktop is sorta moving in this direction as well. Flatpaks and snaps run applications in containers which can be restricted and isolated from each other as well as from the rest of the system. It takes time for applications to catch up to being sandboxed though so it is happening slowly.

I believe that's how it became a cognate in English as well. Very common to hear people use ur-<word> to refer to the original or foundation of that thing.

I'm glad you're enjoying PHP and have given me another perspective on the subject. This comment is not optimized for engagement. This is why I'm here.

Interesting constraint - what's the motivation, if you don't mind me asking?

This is just my take, but a game engine could be a really cool way to see how far you can take Odin. As a new language, I don’t think there are many complex projects using it.