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

I see hacspec using secret-integers: "wrapper around integer types for constant-timedness". Does Hacspec/Bertie have assurances about constant-timedness too?


Link seems broken.


> It is perfectly good enough for the error code enumeration to be statically randomized into hard coded constants.

A comment points out that they aren't randomized:

> The values used were chosen such that it takes a large number of bit flips to change from allowed to denied. Using random values doesn't really protect against this attack.


Some data for me:

Nitter: I get all 8 posts in the thread in 18 requests, 207 kB, 169 kB transferred.

X: I only get the first post, 128 requests, 11.45 MB, 2.11 MB transferred.


Does it matter? Is wafer cost that large of a fraction of the price of these insanely expensive cards?


From the article:

> Nvidia needs 65% more 5nm wafers to produce the same number of GPUs. Basically all else being equal and scaled, AMD has 65% more capacity than Nvidia, when it comes to the most critical part of the production.

> 5nm dies are the most expensive part of the whole solution, meaning there is also a 65% pricing advantage (though some of this advantage is offset by more complex packaging and other cheaper dies that go into mi300x as well as more HBM chips).


> 5nm dies are the most expensive part of the whole solution, meaning there is also a 65% pricing advantage (though some of this advantage is offset by more complex packaging and other cheaper dies that go into mi300x as well as more HBM chips).

That doesn't say anything about the fraction of the cost on the finished product though? Those numbers just say it could be something like 2% vs 6% of the cost of the card.


Pricing breakdowns are going to be hard to come by, as they're negotiated and confidential. But I think it would be safe to say that leading-edge core dies are going to be a sizable plurality (if not majority) of the cost. Only memory would come close (and some of those Reddit comments suggest more, due to it being HBM), as power delivery and other small components like resistors just aren't that expensive.

The trickier bit to measure is R&D, as it's both a fixed cost and one that can be spread across several products.


The 608.5 mm² 4090 with 76.3 B transistors isn't too far off from the 814 mm² H100 w 80 B transistors. Seems like mostly more area for memory interfacing?

Assuming they're not selling the 4090 at a loss and being generous that the whole cost is the chip cost, that makes for a $1600 chip. Scaled to the H100 we get $2140. That's a pretty minuscule fraction of a $35k card.


COGS for an H100 is about $3-4k.


Given the insane demand for these things right now, the real cost is not being able to sell it.


That makes sense though, are the chips themselves the bottleneck in production?


Good point... at 35ish chips per wafer (although I would -hope- nvidia provisioned things sanely to help yields or otherwise bin) an increase in fully good Chips is still better than binning.


Better output than the smaller llamas in my limited testing, but it's surprisingly slow:

Output generated in 101.74 seconds (0.98 tokens/s, 100 tokens, context 82, seed 532878022)

Output generated in 515.46 seconds (0.99 tokens/s, 511 tokens, context 27, seed 660997525)

Checking nvidia-smi it stalls at ~130W (out of ~470 W max) power usage, ~25% GPU usage and ~10% memory bandwidth usage. There's fairly much traffic on the pci-bus though, and the python process is stable at 100% usage of one core. GPU possibly limited by some thing handled in python? Pausing the GPU-accelerated video-decoding of a twitch stream it get a surprisingly large boost:

Output generated in 380.42 seconds (1.34 tokens/s, 511 tokens, context 26, seed 648992918)


> February 08, 2022

They'd need 20 months to manage to notify users?


2nd in the bug here. I actually have some blockcloned data, f.e. steam uses it for all proton installs, but no issues other than the go build.


Coming back home and checking 2.2.1 out zfs instantly started spewing write & checksum errors due to #15533. Both this and #15526 seem to have underlying issues from <2.2 that are just more easily triggered now. First one also confirmed on FreeBSD now.

Holding off on 2.2 seems recommended, and if you're keeping critical data on OpenZFS it might be a good idea to give the issues a glance. The 2nd one might have the same underlying solution as an issue that has given me system freezes when closing in on ~90% pool usage using 2.1 on top of LUKS.


Title seems mangled.


> Several posts have been hidden/deleted because they also contained inflammatory speech. Several community members have reported their discomfort with Srid. In that context, his Discourse profile was seen as yet another provocation.

Not sure you can link to them then?

Considering the contents of the page seem to support their conclusion that the image was just another way to intentionally provoke others in the community I guess they figured the banned member had no intention of following the intention of the warning, but skirting it as close as possible. And now when that failed and they got banned they're instead trying to get people to rally to their support.


But there is literally no trace of wrongdoing. If you're going to sanction somebody, keep at least some screenshots around. Briefly digging in NixOS repo and the Discord I could find nothing even questionable the banned person did.

Regarding the image/homepage being provocative, again my suggestion would be those be. The fact that you don't agree with some person on an issue is no grounds for a ban.


> If you're going to sanction somebody, keep at least some screenshots around.

That might not've been a consideration when the offending posts were removed. The ones doing the removal might not even be the same people handling suspensions.

> I could find nothing even questionable the banned person did.

That might be an issue of legitimacy. I'm involved in some discord modding, and we got admin-only channels mirroring the others to keep logs of everything. I have no idea how suspensions are handled in the NixOS community though, maybe moderators are picked to handle things in their own discretion.

> The fact that you don't agree with some person on an issue is no grounds for a ban.

That's not what's happening here though, it's the intentionally provocative behaviour?

Say some person argues that Israel is a nazi state dehumanizingly enough to get a warning, and gets told to stop derailing everything into a discussion about that since it's a detriment to a community that in itself has no connection to the issue. Agreeing to this they instead start sporting a green flag, or a little image with a free country between a river and a sea - maybe with a green flag on it - while linking to a page about how Israel is a nazi state. Then the issue the moderators have to consider isn't whether they agree on how to describe Israel, but if the actions of the warned person are still acting inflammatory and derailing the community.

A bit over the top example to make it clearer, if you find it an incomparable situation just tone down the actions in it accordingly.


Right, I get that there are topics that are more sensitive than others and there are links and images which I guess are forbidden to use (a swastika for example). But if the issue at hand is about eating meat (?), then is having a meat loaf as the background image (or even a profile image which one would see involuntarily) reason to ban anyone? It is maybe provocative, but the thing to do there is ignore it, not ban it.


The point seems to escape you, it isn't about the sensitivity of the issue, but about if the behaviour is changed or not.


If the issue is about preferences then what behavior is there to change? He's just supporting his case. Looks to me like the moderators have decided that their preference is "right" and the banned person is wrong, and then go on to abuse their power.

You're better than this - if you are a moderator then learn to ignore these (it won't be the last one you see in life :)).


I'm a NixOS user, and having seen ideologically-charged members (on both sides of the aisle) maliciously edit package manifests, I'm glad these dick-swingers get kicked to the curb. There isn't room for your politics when designing open source software, and if anyone disagrees with that it's their prerogative to fork the software.

If it was my call, I'd go even further. If you're unwilling to put your love of software development before your arbitrary personal opinions, you shouldn't be trusted in the SDLC. It's a petty rabbit hole that ends in people writing overly restrictive CoCs instead of pounding down the offending users with a mallet. Make an example out of them.


AFAIK, srid hasn't "maliciously edited package manifests" as you put it. It's more like the moderators and srid don't agree on some off-topic topic, so the moderators (IMO) abused their power and banned him.

Also, apparently the discussion forum post (or github PR?) has been removed so there doesn't seem to be any good evidence either way. Looking at srid's PRs, mentions, discourse etc, it seems all ok, can't find any of these toxic derailments and what not.


In this case mods just found a convenient excuse to ban the "outgroup" member based on ideological lines of demarcation (specifically the unwoke link in the bio). It is never about the facts. If a convenient argument exists, it will be made, if it doesn't, it or the facts for it will be made up soon enough.


Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

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

Search: