Sukera (u/Sukera) - Readit News

Sukera commented on Love C, hate C: Web framework memory problems alew.is/lava.html... · Posted by u/OneLessThing

uecker · 5 months ago

I do not agree that the integer promotion or casting (?) rules are broken in C. That some people make mistakes because they do not know them is a different problem.

The reason you should make length signed is that you can use the sanitizer to find or mitigate overflow as you correctly observe, while unsigned wraparound leads to bugs which are basically impossible to find. But this has nothing to do with integer promotion and wraparound bugs can also create bugs in - say - Rust.

Sukera · 5 months ago

Could you expand on how these wraparound bugs happen in Rust? As far as I know, integer overflow panics (i.e. aborts) your code when compiled in debug mode, which I think is often used for testing.

Sukera commented on ML needs a new programming language – Interview with Chris Lattner signalsandthreads.com/why... · Posted by u/melodyogonna

jb1991 · 6 months ago

Isn't Mojo designed for writing kernels? That's what it says at the top of the article:

> write state of the art kernels

Julia and Python are high-level languages that call other languages where the kernels exist.

Sukera · 6 months ago

No, you can write the kernels directly in Julia using KernelAbstractions.jl [1].

[1] https://juliagpu.github.io/KernelAbstractions.jl/stable/

Sukera commented on The radix 2^51 trick (2017) chosenplaintext.ca/articl... · Posted by u/blobcode

addaon · 10 months ago

> Aside: Why 13 bits instead of 12? For our purposes, we’re going to ignore the carries in the most significant limb, allowing numbers to wrap when they overflow past 2256 - 1 (just like how unsigned addition works in C with normal size integer types). As a result, we can assign 52 bits to the most significant limb and ignore the fact that it will run out of room for carries before the other limbs do.

Why not give the top limb 64 bits and the other four limbs 48 bits each, then? You can accumulate more additions before normalization, you can take advantage of word alignment during splitting and normalization if your instruction set has anything useful there, and your overflow properties are identical, no?

Sukera · 9 months ago

Because adding the top limbs of two encoded numbers would overflow too soon. If you set both to 2^63 for example, they overflow immediately. Might be fine for wraparound arithmetic, but not in general.

Sukera commented on Why Property Testing Finds Bugs Unit Testing Does Not (2021) buttondown.com/hillelwayn... · Posted by u/Tomte

metalrain · 10 months ago

I would love to used PBT more, but many tests I write have only one answer per input. Think sum like aggregations.

For then it's not clear how would one derive the answer from the generated inputs, that is what code is for.

But PBT can be great for pruning out crashes you don't expect while parsing.

Sukera · 10 months ago

For aggregation-like things, the interesting properties are often about the properties of the accumulation function, and not the entire aggregation, which should then be correct by extension. So for your `sum` example, you'd use PBT to test that your `+` works first, and only then coming up with things that should hold on top of that when repeatedly applying your operation. For example, once you have a list of numbers and know it's sum, adding one additional number to the list and taking the sum again should lead to the same result as if you had added the number to the sum directly (barring non-associative shenanigans like with floating point - but that should have already been found in the addition step ;) ).

There's a bunch of these kinds of patterns (the above was inspired by [0]) that are useful in practice, but unfortunately rarely talked about. I suppose that's because most people end up replicating their TDD workflows and just throwing more randomness at it, instead of throwing more properties at their code.

[0] https://fsharpforfunandprofit.com/posts/property-based-testi...

Sukera commented on · Posted by u/ementally

Sukera · 2 years ago

> Throughout the rest of the paper, we assume an adversary who at some point managed to obtain the private identity key IK, the phone number pn, the API username unA, and the password pwA.

This is basically fully owned access already, right? If you have everything that is required to authenticate to the Signal servers, of course you can register new devices.. In that scenario, there's not much you can do to protect against this, and even the proposed countermeasures are conceivable to work around as an attacker. Signal also seems to view the paper like that:

> We disclosed our findings to the Signal organization on October 20, 2020, and received an answer on October 28, 2020. In summary, they state that they do not treat a compromise of long-term secrets as part of their adversarial model. Therefore, they do not currently plan to mitigate the described attack or implement one of the proposed countermeasures.

Sukera commented on Ask HN: Who wants to be hired? (May 2024) · Posted by u/whoishiring

Sukera · 2 years ago

  Location: EU, Austria
  Remote:  Possible
  Willing to relocate: Yes, for some offers
  Technologies: C, C++, Julia, Python, SQL, Linux, Git/Github, Docker, TrueNAS, Wireguard, CoreDNS, AVR, ARM, RISC-V
  Résumé/CV: ~3 years DevOps (mostly Python/Proxmox/TrueNAS); Email for more extensive CV 
  Email: valentin (at) bogad (dot) at   please mention "HNMay2024" somewhere in the email
  LinkedIn: https://www.linkedin.com/in/vbogad
  Site: https://seelengrab.github.io
  GitHub: https://github.com/Seelengrab

In a previous position I've maintained a multisite Linux environment for ~20 people. I'm very OpenSource friendly, experimenting with compiling Julia baremetal to embedded devices. I've also created Supposition.jl (https://github.com/Seelengrab/Supposition.jl), a Hypothesis inspired property based testing/fuzzing framework for Julia.

Sukera commented on Open Source Community Unites to Build EU CRA-Compliant Cybersecurity Processes news.apache.org/foundatio... · Posted by u/transpute

graemep · 2 years ago

That exemption only covers non-commercial open source. Anyone who monetises the open source project (e.g. by offering related consultancy or hosting business, or offering the code under a commercial license as well) is still liable.

It only covers pure hobby projects by pure hobby developers.

Sukera · 2 years ago

It doesn't only cover pure hobby projects:

> (10c) the mere fact that an open-source software product receives financial support by manufacturers or that manufacturers contribute to the development of such a product should not in itself determine that the activity is of commercial nature.

> (10) Accepting donations without the intention of making a profit should not be considered to be a commercial activity.

> (10c).. for the purpose of this Regulation, the development of products qualifying as free and open-source software by not-for-profit organisations should not be considered a commercial activity as long as the organisation is set up in a way that ensures that all earnings after cost are used to achieve not-for-profit objectives.

See https://berthub.eu/articles/posts/eu-cra-what-does-it-mean-f...

Sukera commented on Julia as a unifying end-to-end workflow language on the Frontier exascale system arxiv.org/abs/2309.10292... · Posted by u/npalli

ChrisRackauckas · 2 years ago

Yes it has not landed in Base, but you're acting like there has not been a general cultural changes. I showed, with receipts, that many of the most widely used packages in the Julia ecosystem have adopted new infrastructure, systems, and tooling to address these problems in the last 3 years. With SciML and JuMP both having adopted such systems, this accounts for roughly 50% of the top 100 most starred Julia packages according to current metrics (Nov 20 2023), with many of the packages not doing this largely being interface packages (plotting, notebooks, and language interop, if you account for those not having this issue it's closer to 2/3 of the top 100 most starred packages). I also want that number to be 100%, and the compiler team is having weekly discussions with us about our needs given that there are now successful parts of the ecosystem to model this tooling based off of, and so yes it can get better and we need to keep improving. But to claim that no shift in culture has occurred is implying that all of this doesn't exist, even though we can point to the receipts.

Sukera · 2 years ago

50% of the top 100 most starred, i.e. used, packages are not representative of the entire community. Not to mention that the vast majority of those SciML packages is developed by a relatively small group of people, compared to the rest of the ecosystem. If all a potential user cares about is SciML, good for them! I've repeatedly said that users not looking for SciML are left behind.

Yes, SciML is doing good. I'm not denying that, and never have. Still, the rest of the community/package ecosystem is not good at catching up - which is what I'm criticizing.