Programming

cross-posted from: https://lemmy.bestiver.se/post/890009

Comments

Task

I'm working on my final project for school, we are supposed to make a web app of our choosing and there has to be specific features in it. One of it is all data must be encrypted, and the other is that we have to have a search functionality. My app (A customer support framework) has a ticket functionality where customers can submit help request tickets, the contents of these tickets need to be encrypted at rest, at the same time admins need to be able to search contents of tickets.

Current Plan

My current plan is to store an AES-256 encrypted copy of the message message.content to meet the encrypted requirement, and also store a tokenized and hashed version of the message message.hashed to meet the searchability requirement.

The tokenization/hashing method will be:

• strip the message to alphanumeric + whitespace ([a-zA-Z0-9 ])
• tokenize by splitting the message by whitespace,
• SHA-256 each token,
• rejoin all the hashed tokens into a space seperated string and stored in the message.hashed field.

Thus this is a test string becomes <hash of this> <hash of is> <hash of a> <hash of test> <hash of string>

When the user searches their search string goes through all of the steps in the tokenization/hashing method, then we query the message table for message.hashed LIKE %%<hashed string>%% and if my thinking is right, we should be able to find it.

Concerns

• Statistical analysis of hashed tokens
  • I really don't see a way around this, to make the string searchable the hashing needs to be predictable.
• message.hashed field could potentially be huge, if each word is getting a SHA256 hash, a large message could result in a very large hash string
  • maybe we just store the last 4 of the hash?
    • This would increase collisions, but the likelihood of multiple last 4's colliding in a given search string should be pretty dang small, and any collisions would likely not be valid language.
    • Would this help with the statistical analysis concern? Increasing collisions would decrease the effectiveness of statistical analysis. It would be a performance hit, but after returning all matches against the hashes I could decrypt the message.content data and search the raw search query against the unencrypted text and remove any incorrect returns caused by collisions.

I'm interested in hearing everyone's thoughts, am I being logical in my reasoning?

"Gemini Project" refers to a new network protocol and document format created by open source enthusiasts - it has nothing to do with Google.

I found this article from 2020 (shortly after the launch of the Gemini Project) interesting.

For more technical information and updated resources, see https://geminiprotocol.net/docs/faq.gmi .

AI-integrated development environment (IDE) company Cursor recently implied it had built a working web browser almost entirely with its AI agents. I won't say they lied, but CEO Michael Truell certainly tweeted: "We built a browser with GPT-5.2 in Cursor."

He followed up with: "It's 3M+ lines of code across thousands of files. The rendering engine is from-scratch in Rust with HTML parsing, CSS cascade, layout, text shaping, paint, and a custom JS VM."

That sounds impressive, doesn't it? He also added: "It kind of works," which is not the most ringing endorsement...

Too bad it wasn't true. If you actually looked at Cursor engineer Wilson Lin's blog post about FastRender, the AI-created web browser, you won't see much boasting about a working web browser. Instead, there's a video of a web browser sort of working, and a much less positive note that "building a browser from scratch is extremely difficult."

Developers quickly discovered the "browser" barely compiles, often does not run, and was heavily misrepresented in marketing.

...this week‑long autonomous browser experiment consumed in the order of 10-20 trillion tokens and would have cost several million dollars at then‑current list prices for frontier models.

Hey there,

I'm doing some mainlining stuff for Linux phones, so it'd be helpful for debugging to know C.

Sometimes I just have to figure out what a driver does that makes it fail, which is hard without really understanding the syntax.

So the question is: What are some good resources for learning C?

I mean, I roughly know what a variable or function is, as I've played with Arduinos before. I don't need an explanation that covers what programming is, but I also don't know enough to pogram an Arduino without googling the most basic syntax all the time.

I prefer guided stuff that makes me type and think over just reading specs as purely reading specs does not mean it'll stay in the head.

Hi,

How can I become a team/department lead? I guess I'm starting to feel tired of having a vision and not being able to implement it because I have 0 political power in a company.

I thought that the easiest way was to join a startup as the first person of a "department" in a company, but now I'm not sure how it's possible to get hired to a startup on the early stage.

I have created InsideStack where you can search tech content from currently over 600 Tech Feeds from independent bloggers, Open Source Projects, small Tech Media Houses and Big Tech companies. I am purely following RSS/Atom Feeds and do not scrape the web.

My Goal is to provide a diverse Tech Feed with quality Content and also increase visibility of independent Tech experts which are putting a lot of effort into their blogs.

It is hosted on Hetzner. It has also semantic search (using Mistral Embedding) which is functioning very well.

I would appreciate your feedback. Also if you have any recommended Blogs/Feeds, I will add them very happily.

Also if it can be somehow integrated into Lemmy, I would be very happy to do so.

Major new features:

• The ISO C23 free_sized, free_aligned_sized, memset_explicit, and memalignment functions have been added.

• As specified in ISO C23, the assert macro is defined to take variable arguments to support expressions with a comma inside a compound literal initializer not surrounded by parentheses.

• For ISO C23, the functions bsearch, memchr, strchr, strpbrk, strrchr, strstr, wcschr, wcspbrk, wcsrchr, wcsstr and wmemchr that return pointers into their input arrays now have definitions as macros that return a pointer to a const-qualified type when the input argument is a pointer to a const-qualified type.

• The ISO C23 typedef names long_double_t, _Float32_t, _Float64_t, and (on platforms supporting _Float128) _Float128_t, introduced in TS 18661-3:2015, have been added to <math.h>.

• The ISO C23 optional time bases TIME_MONOTONIC, TIME_ACTIVE, and TIME_THREAD_ACTIVE have been added.

• On Linux, the mseal function has been added. It allows for sealing memory mappings to prevent further changes during process execution, such as changes to protection permissions, unmapping, relocation to another location, or shrinking the size.

• Additional optimized and correctly rounded mathematical functions have been imported from the CORE-MATH project, in particular acosh, asinh, atanh, erf, erfc, lgamma, and tgamma.

• Optimized implementations for fma, fmaf, remainder, remaindef, frexpf, frexp, frexpl (binary128), and frexpl (intel96) have been added.

• The SVID handling for acosf, acoshf, asinhf, atan2f, atanhf, coshf, fmodf, lgammaf/lgammaf_r, log10f, remainderf, sinhf, sqrtf, tgammaf, y0/j0, y1/j1, and yn/jn was moved to compat symbols, allowing improvements in performance.

• Experimental support for building with clang has been added. It requires at least clang version 18, aarch64-linux-gnu or x86_64-linux-gnu targets, and a libgcc compatible runtime (including libgcc_s.so for pthread cancellation and backtrace runtime support).

• On Linux, the openat2 function has been added. It is an extension of openat and provides a superset of its functionality. It is supported only in LFS mode and is a cancellable entrypoint.

• On AArch64, support for 2MB transparent huge pages has been enabled by default in malloc (similar to setting glibc.malloc.hugetlb=1 tunable).

• On AArch64 Linux targets supporting the Scalable Matrix Extension (SME), the clone() system call wrapper will disable the ZA state of the SME.

• On AArch64 targets supporting the Branch Target Identification (BTI) extension, it is possible to enforce that all binaries in the process support BTI using the glibc.cpu.aarch64_bti tunable.

• On AArch64 Linux targets supporting at least one of the branch protection extensions (e.g. Branch Target Identification or Guarded Control Stack), it is possible to use LD_DEBUG=security to make the dynamic linker show warning messages about loaded binaries that do not support the corresponding security feature.

• On AArch64, vector variants of the new C23 exp2m1, exp10m1, log10p1, log2p1, and rsqrt routines have been added.

• On RISC-V, an RVV-optimized implementation of memset has been added.

• On x86, support for the Intel Nova Lake and Wildcat Lake processors has been added.

• The test suite has seen significant improvements in particular around the scanf, strerror, strsignal functions and multithreaded testing.

• Unicode support has been updated to Unicode 17.0.0.

• The manual has been updated and modernized, in particular also regarding many of its code examples.

cross-posted from: https://lemmy.world/post/42174018

Here is the the full TED Talk shown in the beginning.

Nel 1997 il supercomputer IBM Deep Blue sconfisse il campione mondiale di scacchi Garry Kasparov, segnando un evento storico. Grazie a una potenza di calcolo senza precedenti, Deep Blue era in grado di analizzare milioni di mosse al secondo utilizzando un approccio brute force, ovvero valutando tutte le possibili mosse per scegliere la più vantaggiosa.

L’11 maggio 1997, dopo una sfida di sei partite, il computer vinse l’incontro con due vittorie, tre pareggi e una sola vittoria per Kasparov. La competizione, durata diversi giorni, attirò una vastissima attenzione mediatica a livello mondiale, diventando un simbolo del confronto tra uomo e macchina. A fare la differenza fu, tra le altre cose, una pausa casuale inserita nella macchina tra una mossa e l'altra dai programmatori della IBM.

Girard's insight was that communities resolve internal conflict through scapegoating: the selection of a victim to bear collective guilt, whose expulsion or destruction restores social cohesion. The scapegoat need not be guilty of the crime attributed to it; it need only be acceptable as a target.

Some dangerous individuals, however, institutionalize such ritualistic practices into what I call Casus Belli Engineering: the use of perceived failure as pretext to replace established systems with one's preferred worldview. The broken feature is the crisis that demands resolution. The foundation becomes the scapegoat, selected not for its actual guilt but for its vulnerability and the convenience of its replacement. And in most cases, this unfolds organically, driven by genuine belief in the narrative.

The danger is not the scapegoating itself; humans will scapegoat. The danger lies in those who have learned to trigger the mechanism strategically, who can reliably convert any failure into an opportunity to destroy what exists and build what they prefer.

The linked article title is “Casus Belli Engineering: The Sacrificial Architecture”, which I didn't find particularly descriptive. I used the second headline, “The Scapegoat Mechanism”. It doesn't include the architecture or strategy aspects, but serves well as a descriptor and entry point in my eyes.

There exists a peculiar amnesia in software engineering regarding XML. Mention it in most circles and you will receive knowing smiles, dismissive waves, the sort of patronizing acknowledgment reserved for technologies deemed passé. "Oh, XML," they say, as if the very syllables carry the weight of obsolescence. "We use JSON now. Much cleaner."