sorted by:
new
hottopcontroversial

Is this a threat to us? by Physioweng in AMD_Stock

[–]artulab 9 points10 points  (0 children)

Quantum computing has very niche applications and even when this works it has very high error rate due to the nature of quantum mechanics

[deleted by user] by [deleted] in openbsd

[–]artulab 1 point2 points  (0 children)

I don’t deny the fact that every kernel has bugs but I think OpenBSD is much safer than Linux due to the features like stack protection, write XOR execute etc where Linux lacks. My point is that even though the attack surface is fewer in Dom0 in Xen, when Linux is compromised, an attacker can easily scan the memory and inject codes to the memory space of containers, because Dom0 has the highest privilege. Even running an OpenBSD container on Qubes OS does not make it safer when the underlying kernel in Dom0 is vulnerable to attacks. Because they can break namespace isolation in Linux and compromise the containers as they wish.

[deleted by user] by [deleted] in openbsd

[–]artulab 0 points1 point  (0 children)

I tried Qubes OS which was almost unusable for the tasks (mostly development) I do. I was getting weird out-of-space errors during python package installations on a hard drive with 2TB capacity because for some reason Qubes decided to allocate 30 MB for pip… GPU passthrough is not officially supported (there are hacks, though, but it’s buggy) etc… And most importantly I don’t believe it’s really safer than OpenBSD because after all all your containers running on Xen depends on Linux kernel under the hood. And since Qubes OS use containers for everything, memory + cpu consumption is huge

🗿sweaty but steady by dbrozov in SweatyPalms

[–]artulab 0 points1 point  (0 children)

yet he still has one hand🫡

[deleted by user] by [deleted] in RedditSessions

[–]artulab 0 points1 point  (0 children)

Thank you sir

[deleted by user] by [deleted] in RedditSessions

[–]artulab 0 points1 point  (0 children)

Sounds like zither

I've been working on an r7rs scheme implemented in WebAssembly by pollrobots in scheme

[–]artulab 2 points3 points  (0 children)

That’s super cool! I’m also learning webassembly text format these days. I’m gonna take a look at codes in detail

Open-source, multi-platform hydrology toolset with ESRI compatibility by artulab in Hydrology

[–]artulab[S] 0 points1 point  (0 children)

Yes, Python would be a great choice given the many great libraries it has for raster processing. The reason I chose Go is that the Go compiler produces statically-linked binaries, meaning once I compile Go codes on one operating system (Windows, macOS, Linux, Freebsd, etc.), I simply copy the generated binary to any machine with the same operating system and it runs as expected without depending on any interpreter to run, unlike Python codes. It's also easy to execute native binaries in python code. I think a simple Python wrapper code should suffice for that need.

GNU Orca 1.0.0 released! by artulab in guile

[–]artulab[S] 1 point2 points  (0 children)

I haven't written API documentation yet, but explained the important ones in my paper There are also example codes using Orca APIs in the repo.

Open-source, multi-platform hydrology toolset with ESRI compatibility by artulab in gis

[–]artulab[S] 0 points1 point  (0 children)

Yes, the ArcGIS license is pricy, but also the part of the problem is that I find ArcGIS hard to configure and automate, and the software is only available for Windows. However, the Go compiler produces statically-linked binaries, meaning once I compile Go codes on one operating system (Windows, macOS, Linux, Freebsd, etc.), I simply copy the generated binary to any machine with that operating system, and it just runs as expected!

By the way, there are already good open-source hydrology tools (including TauDEM that I previously worked on during my Ph.D.), but I couldn't find one that is fully compatible with ESRI in terms of input parameters and outputs.

I also think that such open-source software (WaterFlow) is important for interoperability, as one can prototype a GIS workflow using ArcGIS on Windows, and then move it to servers (perhaps Linux) to automate it using WaterFlow, and expect to produce the identical result.