Vorpal

joined 2 years ago
[–] Vorpal@programming.dev 7 points 2 weeks ago* (last edited 2 weeks ago) (1 children)

Agreed, I run arch on my desktop and laptop, because it is more stable (in the sense of fewer bugs, things like suspend/resume works reliably for example) than any other distro I have used.

But on my VPS and my Pi I run Debian because it is more stable (in the sense of fewer upgrades that could break things). I can enable unattended upgrades there, which I would never do on my Arch system (though it is incredibly rare for those to break).

Also: if someone said they were a (self proclaimed) "semi noob" I would not recommend Arch. I have used Linux since 2002, and as my main OS since 2006. (Furthermore I'm a software developer in C/C++/Rust.) While Arch is a great distro, don't start with Arch.

[–] Vorpal@programming.dev 16 points 1 month ago (2 children)

I don't know the answer (I don't care about numlock myself), but the arch wiki has an article on this: https://wiki.archlinux.org/title/Activating_numlock_on_bootup

Perhaps that will be useful to you. In general checking the arch wiki is a good idea for any Linux issues, even if you don't run arch, many things still apply to other distros and the articles are of very high quality.

In this case, "Early bootup (mkinitcpio)" would likely not apply to most other distros that aren't based on Arch, but the rest looks to apply widly.

It is worth noting that in the KDE section it mentions the need to apply two settings, perhaps that could be it?

[–] Vorpal@programming.dev 3 points 1 month ago (7 children)

That seems to be for dns resolving, not for ddns? Or am I missing something?

[–] Vorpal@programming.dev 6 points 1 month ago (1 children)

Most registrars also run DNS servers as part of the fee you pay for the domain. Usually they have an API. You can just use that to implement Dynamic DNS, there are even often tools for it. Do a search for your DNS registrar and dyndns.

[–] Vorpal@programming.dev 5 points 1 month ago

Afraid.org is better than DuckDNS. (DuckDNS is not reliable and have been slow or down a lot.)

But it is still American.

[–] Vorpal@programming.dev 2 points 1 month ago

12th verse: I’m sane, I promise

Hmm...

As to LLVM and alloca, it doesn't optimise or even work well in practise. Some basic cases work, others are less well tested. There are lots of "should" that "doesn't" in practice in LLVM.

I have not looked at alloca in LLVM myself but from what I have heard from those who are experts on this, it is quite brittle.

Second of all: sub is my favourite allocator

https://docs.rs/bumpalo/latest/bumpalo/ (and bump allocators in general).

Fourth of all: second point is literally a skill issue idk, especially if your compiler is already proving bounds anyway.

In general proving bounds for stack growth is very difficult. With recursion it is undecidable. This follows directly from Rice's Theorem. (This is my favourite theorem, it is nice to know that something is impossible rather than a skill issue.)

(Of course you could have a static analyser that instead of yes/no returns yes/no/don't know, and then you assign don't know to be either of the other classes depending on if you care more about false positives or false negatives. This is how the rust borrow checker works: forbid if it can't prove it is safe, but there will be safe code that it doesn't allow.)

[–] Vorpal@programming.dev 1 points 1 month ago (2 children)

Alloca for buffers is generally a bad idea:

  • If you have an upper known bound, just use that. If you don't you risk stack overflow. Especially on a malicious input.
  • Alloca optimises poorly (especially with LLVM) since the compiler can't really see how large the stack frame is.

The only reasonable usage I have seen is in the Swift ABI. See this blog post on the topic by a rust compiler developer: https://faultlore.com/blah/swift-abi/ (and even there it is only for some cases that it can be used).

[–] Vorpal@programming.dev 3 points 1 month ago (4 children)

Not really. Heapless uses compile time sized backing buffers to implement Vec, string etc with a max upper size. You would typically use heapless with a statically allocated variable, but it is possible to use it on the stack too.

Alloca is different and allocates a dynamically sized block on the stack. Rust doesn't really support alloca, but there is a crate for it that works by calling through a helper function in C: https://lib.rs/crates/alloca

[–] Vorpal@programming.dev 4 points 1 month ago

Also worth noting is smallvec and compact_str crates. These are useful when you most of the time have small data that you want inline, but are OK with falling back to heap allocation for the occasional outlier.

I have used both inside structs to optimise cache usage. For these uses i tend to use rather short smallvec.

And smallvec in particular is also useful on the stack in a larger variant in hot functions where you might have a Vec that almost always is less than (say) 32 elements, but the program should gracefully handle the occasional long case. I found this offered a small speed up in some batch data processing code I wrote.

[–] Vorpal@programming.dev 5 points 2 months ago (2 children)

What about the UV cured polymer that dentists use? Surely that is relatively safe, though probably way too high viscosity. (Note: While I know a fair bit about FDM, I'm not at all read up on SLA, so I may be completely wrong here.)

[–] Vorpal@programming.dev 8 points 3 months ago (1 children)

Let's Encrypt is meant yo be used with automated certificate renewal using the ACME protocol. There are many clients for this. Both standalone and built into e.g. Caddy, Traefik and other software that does SSL termination.

So this specific concern doesn't really make sense. But that doesn't mean I really see a use case for it either, since it usually makes more sense to access resources via a host name.

[–] Vorpal@programming.dev 4 points 3 months ago* (last edited 3 months ago)

Thanks, didn't think about that. Two reasons I can think of:

  • Vase mode should reduce stringing on TPU as it avoids retractions. Though I have found that just drying TPU + enabling "avoid crossing perimeters" usually hides most stringing.
  • Additionally, it would let you have more precise control over how squishy/firm the TPU part is by adjusting the number of perimeters. Though you can use modifier volumes in the slicer to adjust infill and number of perimeters locally in a part.

Is there any other reason why this is good for TPU that I missed?

 

Because I couldn't find a good non-video resource on this topic, I wrote a tutorial on how to print non-vases in vase mode.

The idea comes from 3D printing wings for model aircrafts, but it can be applied outside this area as well in order to minimise time and material usage in a part (at the expense of more CAD time).

Hope it is useful to someone and I look forward to any feedback on how to improve the article (or correct any mistakes).

 

cross-posted from: https://programming.dev/post/10657765

I made a replacement for the venerable paccheck. It checks if files managed by the package manger have changed and if so reports that back to the user. Unlike paccheck it is cross distro (supports Debian too and could be further extended), and it uses all your CPU cores to be as fast as possible.

Oh and it is written in Rust (that may be a plus or minus depending on your opinion, but it wouldn't have happened at all in any language except Rust, and Rust makes it very easy to add this sort of parallelism).

There are more details (including benchmarks) in the readme on github. Maybe it is useful to some of you.

(The main goal of this project is not actually the program produced so far, but to continue building this into a library. I have a larger project in the planning phase that needs this (in library form) as part of it.)

 

This is a Rust replacement for debsums (on Debian/Ubuntu/...) and paccheck (on Arch Linux and derivatives). It is much faster than those thanks to using all your CPU cores in parallel. What it does is check files installed by your package manager for changes and reports those on stdout.

This is a project I have been working on over the past few weeks. There are more details (including benchmarks) in the readme.

I normally don't advertise my open source projects (having users other than yourself is both a blessing and a curse), but since there was recent discussion on how to grow this lemmy group I'd thought I'd post it. Maybe it is useful to some of you.

I also spent quite some time on optimising this (including a lot of benchmarking, profiling and trying alternative solutions). In the end I'm happy with the performance, though I am considering io-uring for disk IO.

The main goal of this project is not actually the program produced so far, but to continue building this into a library (currently very little is exposed as pub, because the API will change). I have a larger project in the planning phase that needs this (in library form) as part of it.

 

I'm not affiliated with the site, but I found this interesting. Especially the quite nuanced discussion about if rust is hard or not.

With my background in systems level safety critical hard realtime C++ (plus a bunch of functional programming as a hobby) I feel that the answer was no (for me personally). Basically learn about lifetimes and borrowing and then learn the syntax, done. (Async and unsafe are arguably harder, but again I had the requisite background for it to be mostly familiar, though haven't needed to write much unsafe yet.)

But it was very interesting hearing the other perspective as well! Why rust might feel hard if you have a background in JS/Python/Go etc.

And it was awesome to hear such a nuanced discussion on the Internet, that is truly a rare thing these days.

 

cross-posted from: https://programming.dev/post/1825728

Lots of new features!

Thought I should share this with those who don't use users.rust-lang.org. Note: I'm not affiliated with lib.rs, I'm only reposting to lemmy.

 

Lots of new features!

Thought I should share this with those who don't use users.rust-lang.org. Note: I'm not affiliated with lib.rs, I'm only reposting to lemmy.

view more: next ›