HackerLangs
TopNewTrendsCommentsPastAskShowJobs

nullc

18,957 karmajoined 16 năm trước
gmaxwell

http://nt4tn.net/

Submissions

[untitled]

1 points·by nullc·9 tháng trước·0 comments

comments

nullc
·3 giờ trước·discuss
Would you like me too? I thought it unnecessary and needlessly rude to single anyone out: There are many examples of HN regulars behaving this way, and in my impression it has considerably increased over the last six years. I'm sure I could find a post or two of my own that is guilty of it-- it's increasingly the culture here, as unfortunate as it is and it's something we should all watch out for to avoid it in ourselves and to discount it in others.
nullc
·5 giờ trước·discuss
[flagged]
nullc
·Hôm qua·discuss
Careful with those graphs, they're usually evaluating the model on KLD on relatively short transcripts. When you're running with 100k token contexts and the model running close loop a difference that looks small in terms of KLD may be quite substantial.

I'm not aware of any great benchmarks that work by giving it a live agentic harness and a number of realistic tasks that take most of the context window to accomplish and evaluate success rate and tokens to completion... but that's what you'd really want to use to judge different quantization levels.
nullc
·3 ngày trước·discuss
I've got a shim that will ask the model to write a summary of what didn't work, then rolls it rolls back the context to before those attempts with only the summary as advice. Some care has to be taken with cache management that there is an available checkpoint back there.

Appears to help, but I suspect it would be much better with first class support and reinforcement learning to make good use of this kind of advice.

Still certainly needs some tuning because I've noticed the model taking the advice as the word of god and avoiding trying anything remotely like the things that didn't work.
nullc
·3 ngày trước·discuss
Most of the models where people are concerned about don't do this when unquantized, so I doubt it's much about the metapolitics imposed in reinforcement training.
nullc
·3 ngày trước·discuss
> In other words, Bernstein proposed a NTRU-based scheme under his theory it was the most conservative.

This is in fact that what I meant, and should have said: thanks.
nullc
·3 ngày trước·discuss
Post selection is also design. Evolution by natural (or artificial, for that matter) selection works by post-selection.

I'm happy to agree that it affords much less degrees of freedom than original design, but the irrelevance argument depends on no influence rather than a lack of absolute influence.
nullc
·4 ngày trước·discuss
Yes, and strongly argued against lattice schemes generally. DJB submitted a lattice scheme under the theory that if the advocates of lattice schemes were able to win the argument about the performance properties then there should be a choice of an extremely conservatively designed one.

DJB himself has consistently advocated for Classic McEliece in any application which can accept its performance characteristics (which are excellent except for the ginormous public keys), and spent many bytes trying to convince people that the set of applications that can is wider than they suspect.
nullc
·4 ngày trước·discuss
I might have expected you'd be once bitten twice shy after having once taking an aggressive position that DUAL-EC would never have backdoored anyone in practice...

The optionality of MLKEM by itself is of a similar shape to standardizing a lame DRBG that 'obviously' no one would use and anyone who would use would use the appendix parameter generation scheme that would have rendered it secure (although still slow). The reality of it was that once it was standardized NSA was able to secretly compel its use.

On one hand MLKEM by itself seems like a better choice than DUAL-EC, on the other hand that fact should make it much easier for a powerful attacker to cause a target to use it if you do have an attack that exploits this fact.

MLKEM was selected out of myriad other options through a NIST process which was directly influenced by NSA (including in manners that NIST failed to disclose and actively mislead the group about). I think this makes the commentary regarding NSA highly relevant. While it seems less like that NSA already knows of a total break in MLKEM (and indeed their influence could have been in a strengthening direction...) it's possible that their influence was motivated by things like that ease of undetectably compromising specific implementations through techniques like dopant adulteration or specialized side channel weaknesses.

If your plan it to tamper with chip mfgr or hit them with a very well aimed e-beam (e.g. to cause ion migration) after the fact then having a non-hybrid scheme is pretty obviously going to make your life much easier... Or perhaps they've taken a route similar to the one they took with Crypto AG-- this time positioning themselves as a fabless silicon vendor to sell MLKEM RTL to a market that doesn't have an implementation but already has many robust ECC implementations to choose from.

...and that's without getting into the unknown possibility of a cryptoanalytic breakthrough.

I don't think it's even safe to say that NSA would only consider NOBUS backdoors-- I don't think any of us can know how inadvisably arrogant the relevant decision makers may be and what they might consider NOBUS. Given how DUAL_EC went in Netscreen's products I think it's reasonable to argument that there is no such thing as a NOBUS backdoor when push comes to shove. Capping DES's key size is candidate example of a very much non-NOBUS weakness that NSA felt comfortable with, as one needed a particularly amount of strength to exploit it which they believed that only they had. Today, of course, a child's video game device can crack DES as a direct product of that part of their influence.

Not a great track record when fear of "store and decrypt later" attacks is much of what motivates the use of PQ key agreement today.

The consistent aggression five-eyes affiliated cryptographic-intelligence groups have had for hybrid schemes is truly difficult to comprehend-- given that practically everyone else considers them obviously prudent in all cases where the resource costs permit -- and I think this justifies the utmost concern and caution. And in terms of caution hybrid schemes are table stakes.

A major theme of DJB's cryptographic security advocacy is that cryptographic security is often as much about what you don't offer as it is what you do. A completently engineered security product is misuse resistant and it's not completely clear to me that a standard which offers the choice of a non-hybrid mlkem qualifies as misuse resistant.

That said, there are plenty of drafts that are in no way misuse resistant. :)
nullc
·4 ngày trước·discuss
Perhaps it's useful to know that NAC is the treatment for acetaminophen toxicity, should you happen to find yourself in the middle of a zombie apocalypse with a Tylenol ODed friend and a supplements isle handy but no readily available medical support. :D

There has been some suggestions that acetaminophen products should contain NAC to offset some of the toxic effects, but I dunno where they've gone-- there probably isn't any money in it to study it formally.

I try to make an effort to know what the treatment/antidote is for any hazardous substance in my home... things you hope you never need to know but are glad if you do.
nullc
·5 ngày trước·discuss
> If the left reproduces via external means (e.g., media), then they've effectively outsourced biological reproduction and all its costs

Ahh. Brood parasitism. Very tricky.
nullc
·7 ngày trước·discuss
I could kill you with a pen.
nullc
·7 ngày trước·discuss
how do you get 5x faster at inference when inference is memory bandwidth limited? getting 5x the memory bandwidth of a h100 seems physically difficult.
nullc
·7 ngày trước·discuss
Any high end audio dac is internally running at a much higher sample rate-- that's what it takes to get their delivered performance with the silicon that's available. Its up-sampling process was designed by the designers of the DAC with intimate knoweldge of its analog properties.

Second guessing it by upsampling in front of it seems dubious to me. It might help in some cases where the DAC designers were thinking of different objectives or just didn't do a great job. It might also help with some other issues, like if the dac is timed off the input clock and the input clock sucks and the upsampler retimes the signal.

Of course the upsampler designers could also get it wrong, be aliasing the hell out of the results, and happen to like the sound of the corrupted audio. :P

The effects are all objectively measurable however-- with expensive equipment at least. I think I'd want to set test results with a particular hardware combination before sticking an upsampler in it. OTOH, if there already was one there because it's just some built in feature of some kit I wanted to use otherwise, I wouldn't worry much about it. Particularly if that kit has been reviewed by people with proper test gear and they didn't decide that it was broken.
nullc
·7 ngày trước·discuss
so an 8-core zen4 should be able to sustain more than 300 gflops of 64-bit multiply-adds. At 480khz that's 625k operations per sample. I'll grant the 100x oversampling was probably too ambitious. :P

For adaptive rate I think the issue there is you have a hard-realtime constraint for this usage (even if you wouldn't mind rendering offline, you kinda have to hear it realtime to tweak it-- after all you might tweak it in a way that brings out an artifact you like and then be disappointed by the render). Also in the case of a whole modular system having all sorts of different parts needing to be part of the adaptation loop seems pretty hard to me.

My thinking was just in general that 192k is really not enough to prevent aliasy algorithms from messing up. If you are alias safe you can probably run at 48k and be fine. If you're not, you really want to go much higher.
nullc
·7 ngày trước·discuss
From the paper it appears that it's probably more useful on small-ish models.
nullc
·7 ngày trước·discuss
It would be nice if special purpose models provided a some diverse examples of exactly the input required to get its expected performance on a mix of problem types. Maybe also a document intended for LLMs to read that advises on prompt construction.

I've found that you can get wildly different quality results from these sorts of models due to seemingly insignificant differences in prompt construction. It would be much easier to guess at what it wants if I could just see some RL transcripts -- and so the model author is in a much better position to provide initial advice.
nullc
·7 ngày trước·discuss
> The big build in article starts off with a $40K budget and then includes 4 GPUs that are $12K each. For those doing the math, this build is going to cost more like 50-55K.

Just two months ago you could get RTX PRO 6000's for about $8500 on ebay, which is the MSRP.
nullc
·7 ngày trước·discuss
Those cards would really prefer you use a pcie-5 switch, but I guess they're sold out.
nullc
·8 ngày trước·discuss
Worst negative pattern I've seen is hyper defensive programing. E.g.

  try:
    something_that_should_not_fail_and_if_it_does_our_assumptions_are_all_wrong()
  except:
    fallback_that_will_not_result_in_correct_behavior_but_make_failure_hard_to_detect()
But, of course, it depends a lot on which models you're using and how you instruct them.