Hacker Newsnew | past | comments | ask | show | jobs | submit | more swiftcoder's commentslogin

Because they are serverless, so there's currently no memory for it to be processed in at the point of upload

Every time I click on one of these posts, I'm expecting it to be a tiny KVM switch. When did this whole KVM nomenclature catch on for virtual machines?

Well it was released on Linux in 2007, so it's meant Kernel Virtual Machine for at least 18 years

See: https://en.wikipedia.org/wiki/Kernel-based_Virtual_Machine


KVM (as in the switch) was termed in 1995: https://en.wikipedia.org/wiki/KVM_switch

It certainly wasn't in common usage that early - at least not outside of linux circles. I don't really recall hearing it in this context before maybe the early 20's

> Typst is incredible for single-person or a trio of people, but the web experience is not there yet for collaboration

How did collaborate in the past on LaTeX publications?


Not OP, but likely overleaf.

> Much less portable than the C ecosystem though.

Theoretically? Yes. In practice...

Do you actually develop for a platform that (a) has a standards-compliant C compiler, (b) does not have a Rust target, and (c) has enough memory to be worth dealing with PDFs?


It's a start, for sure

If you use the 3-prong version of the power adapter to connect to a grounded outlet, this problem goes away. Of course, Apple doesn't actually sell a 3-prong plug for their charger in Europe... so us lucky folks in the EU have to get a 3rd party one off the internet

Yes, they do. [1] for Italian outlets, [2] for many of the others. I'm sure I don't need to continue.

[1]: https://www.apple.com/it/shop/product/mw2n3ci/a/prolunga-per...

[2]: https://www.apple.com/fr/shop/product/mw2n3z/a/câble-d’exten...


I suspect what they meant is that there isn't an official Schuko nub that slides onto the brick and lets you hang it directly from the socket rather than carrying an extra meter of cable around. There is a BS1363 one, and those are only legit feasible in a grounded configuration (although I guess you could use a plastic ground spade to lift the child protection slider inside the socket if you were a particularly unpleasant engineer). Nice for those of us in British-adjacent countries.

I'm talking about the non-corded variants. Carrying an extra metre of cable around just to get the grounding prong is not great.

As another poster mentioned, it's particularly annoying because Apple does ship the UK adapter in 3-pin grounded form


YMMV. I throw away the non-corded variants because they rarely fit in the spaces that people think to put outlets, especially as the chargers have grown and (particularly) train operators love putting outlets attached to tables with about 5mm of clearance.

Open-source is not about being able to view the source code at point-of-execution. It's about having a license to modify/distribute that source code

If you look through second-hand car listings in Europe, >400,000km is not that usual to see. In places where cars are relatively expensive, folks keep them running forever...

That said, a million miles is probably enough for anyone :D


> the SDK seems way larger than I had imagined, but that is normal for (software) things, I guess. "This API also enables the scheduling of tasks on the main thread from any other thread." was not easy to unpack nor see the use of in what was (to me) an audio-generation-centered API

VST plugins almost all have a GUI, thus the VST SDK has to support an entire cross-platform UI framework... This threading functionality is mostly about shipping input events/rendering updates back and forth to the main (UI) thread


There is no single UI framework in VST. The plugin API only has interfaces for creating/destroying/resizing a GUI window. You are not required to use VSTGUI.

For context, the variation in UI between VSTs is pretty large and tend to be very creative, much like UI in games.

For better or worse, frequently worse

Like traveling back in time before UX was a word


Correct, it just hands you native handles. What you do with them is up to you.

JUCE is a popular UI framework (at least it was 10 years ago). But I've seen people put electron apps somehow into a VST.


Oh man, this is really starting to look like a plague.

And yet here we are discussing the value of using C++ vs other languages for real time audio processing.


The documentation on this is... uh... intimidating? I come away from this with the sense that I need to learn a whole lot about cryptography to make a good decision here:

https://argon2-cffi.readthedocs.io/en/stable/parameters.html


Do not reference these kinds of docs whenever you need practical, actionable advice. They serve their purpose, but are for a completely different kind of audience.

For anyone perusing this thread, your first resource for this kind of security advice should probably be the OWASP cheatsheets which is a living set of documents that packages current practice into direct recommendations for implementers.

Here's what it says about tuning Argon2:

https://cheatsheetseries.owasp.org/cheatsheets/Password_Stor...


It's been a couple years since I've looked but the track record of OWASP for cryptography advice has been pretty dismal.

Do you have a better recommendation?

I feel bad for OWASP. They're doing the lords work, but seem to have a shoestring budget.


The OWASP ASVS appendix on Cryptography is one of the best and concise resources I know for this kind of thing: https://github.com/OWASP/ASVS/blob/master/5.0/en/0x92-Append...

This is just a random list of links to standards and summary tables, some of which are wrong (urandom vs. random, for instance). The "A/L/D" scoring makes very little sense. CBC is legacy-allowable and CTR is disallowed; "verification of padding must be performed in constant time". For reasons passing understanding, "MAC-then-encrypt" is legacy-allowable. They've deprecated the internally truncated SHA2's and kept the full-width ones (the internally truncated ones are more, not less secure). They've taken the time to formally disallow "MD5 and SHA1 based KDF functions". There's a long list of allowed FFDH groups. AES-CMAC is a recommended general-purpose message authenticator.

This is a mess, and I would actively steer people away from it.


Yes it’s an audit checklist for when you need to know specifically what to use and with which parameters.

It’s unfortunate if there are mistakes in there. The people at OWASP would be very happy to receive feedback on their GitHub I’m sure.


It's a bad audit checklist! If OWASP volunteers can't do a good one, they should just not do one at all. It's fine for them not to cover things that are outside their expertise.

Which one would you recommend instead? Referring dev teams to NIST standards or the like doesn’t work well in my experience.

There doesn't always have to be a resource. Sometimes no resource is better than a faulty one. Cryptography is one of those cases.

I’d wager that something like 90% of developers who look at that page should close the tab instead of reading any of it.

If you’re building a system and need crypto… pick the canonical library for the ecosystem or language you’re working in. Don’t try to build your own collection of primitives.


Also, I gave the link to the appendix because there was a specific question about Argon2 parameters. For general developer audiences, they need to look at the standard itself which is a lot more high level about how to properly implement cryptography in software: https://github.com/OWASP/ASVS/blob/master/5.0/en/0x20-V11-Cr...

For the most common use-cases of cryptography like authentication and secure communication there is more specific, but still high level guidance that is useful for developers as well:

- https://github.com/OWASP/ASVS/blob/master/5.0/en/0x21-V12-Se...

- https://github.com/OWASP/ASVS/blob/master/5.0/en/0x18-V9-Sel...

- https://github.com/OWASP/ASVS/blob/master/5.0/en/0x15-V6-Aut...


This standard is bad. People should avoid it. For example: 11.2.2 (cryptographic agility) is an anti-pattern in modern cryptographic engineering.

Please elaborate why you believe that? The ability to easily rotate encryption keys is considered an anti pattern?

Yes I fully agree. I’m a big fan of libraries like Google Tink that make you pick a use case and use the best implementation for that use case with built in crypto agility.

Most crypto libraries are not built like that however. They just give you a big pile of primitives/algorithms to choose from. Then frameworks get built on top of that, not always taking into account best practices, and leave people that are serious about security the job of making sure the implementation is secure. This is the point where you need something like ASVS.


What language today still doesn't have a de facto simplified toolbox for wrapping crypto operations?

If you're a developer, and you start trying to perform crypto operations for your service and the library you chose is making you question which cipher, what KDF parameters, or what DH group you want, that is 100% a red flag and you should promptly stop using that crypto library.


Can you give some examples of such commonly used libraries for languages like Java / C# / C++?

In my experience there are not many libraries like Google Tink around, and they are not in widespread use at all. Most applications doing encryption manually for specific purposes still have the words AES, CBC, GCM, IV etc hardcoded in their source code.

If you review such code, it’s still useful to have resources that show industry best practices, but I agree that the gold standard is to not have these details in your own code at all.



Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: