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

Open weight models challenge the "winner takes all" hypothesis, which motivates the astronomical valuations and acts as a justification for trains of cash dumped into AI development.

In other words, if AI models become a commodity, the "AI leaders" will not be able to burn the cash like they do today, thus resulting in a "slower" (one could say instead "more sustainable") development of AI models.


Well maybe they should find better training methods or architectures


Tough shit welcome to capitalism


I wonder if NNs could be trained well enough with 1 bit weights (i.e. 0 and 1) with some layers doing addition, while others substraction (i.e. weight sign would be "hardcoded" into the network architecture). Or with zero-less weights (e.g. -1, -0.5, 0.5, 1).


There are 1-bit* LLMs (+1/-1, usually), though they often come with an additional scaling parameter:

https://huggingface.co/prism-ml/Bonsai-27B-gguf#weight-repre...

> Weight Representation: Q1_0_g128 Each weight is a single sign bit: 0 maps to −scale, 1 maps to +scale. Every group of 128 weights shares one FP16 scale factor. > Effective bits per weight: 1.125 (1 sign bit + 16-bit scale amortized over 128 weights)

The Bonsai ternary model also uses this group-wise scaling, so the theoretical bits per parameter is 1.71 instead of ~1.58; additionally, they actually store trits as 2 bits; with the group scaling factor it becomes 2.125 bits/weight: https://huggingface.co/prism-ml/Ternary-Bonsai-27B-gguf#memo...


Some people use cryptocurrency miners to heat their homes. It's certainly better than dumb resistive heating, but depending on various conditions it can cost more than installing a heat pump.


A dedicated heat pump would be cheaper if we consider heating to be the device's primary purpose. The idea is the computers are doing all sorts of useful things, and the heat is just a free byproduct of that activity.


Because it's not economical, the required hardware is unlikely to pay for itself during its lifetime. The gradient is too small (~50C), which means low Carnot efficiency. Additionally, extraction of low-enthalpy energy involves obstruction of heat transfer, meaning lower cooling efficiency. It may have been a different story if we had computer hardware able to efficiently operate at 200-300C.

Even steel plants which deal with significantly higher waste heat gradients rarely bother with recovering energy.


> It may have been a different story if we had computer hardware able to efficiently operate at 200-300C.

Do I see a market opening here?


>There is no "objective" foundation to music.

Well, there is a number of "objective" factors which play a significant role. For example, see: https://www.youtube.com/watch?v=tCsl6ZcY9ag


>Its capabilities all the way down.

IIUC one problem with such layering of capability processing is that each passed layer results in a context switch (i.e. switch of memory mappings, thrashing of caches, etc.) and its on top of the cost of passing through the kernel. In other words, you may need to pay cost of N syscalls for one multi-layered capability-based operation.


True, but capability calls in SeL4 are supposedly faster than linux syscalls. Because caps are such an important primitive, they're extremely heavily optimised.

As an example, when you invoke a capability, your process hands the callee your scheduler time-slice. So its not like linux where your process yields to the scheduler. The same CPU core will handle the entire call -> process -> return computation pipeline between multiple processes.

I'm not sure how fast it ends up in practice compared to a similar system built on top of linux. I suspect a lot of the difference would come down to implementation choices. And if its still not fast enough, you can always just set up a ring buffer or something between processes to share data directly.


No, it's not. Launch windows [0] are about relative position of orbital bodies which enable use of more efficient transfer orbits.

[0]: https://en.wikipedia.org/wiki/Launch_window


>Are we going to run out of space?

In a certain sense, we do. Pumping thousands satellites to LEO increases probability of triggering the Kessler syndrome. Luckily, LEO orbits are also self-cleaning on reasonable time scales (decades), so I think that some day we will trigger it (potentially, with some "help" from anti-satellite weapons) after which some kind of international regulation will be introduced to prevent repeating it in future.


For Rust we have Loom [0], but do not expect for it to work on your whole application.

[0]: https://github.com/tokio-rs/loom


Isn't it just a lawmakers' version of diff? :) You just can't conveniently apply it automatically to compile the resulting text.

>Why the hell you not just rewrite the old law and bump the revision?

Because it's aimed at lawyers and judges who have to be up-to-date with all changes and its easier for them to remember "section 123 was amended in 2026", than to recall a whole new revision and mentally compute the difference.

It's also why you often can see skipped items (e.g. 1, 2, 4, 8, 9, 10). Because humans often think in terms of "<..> code, section 123", not "<..> code, revision 24, section 123, which was section 130 in revision 20", so when you remove a part, it's more efficient to leave an empty space and to not reuse it later.


> Isn't it just a lawmakers' version of diff?

It probably is, and they are just stuck in the past not wanting to adopt new tools. You have people in tech reading chancelogs, or follow something like the openbsd-cvs mailing list. It feels like it would be easier if you did have have to look up a law, the search for amendments, which may or may not exist.


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

Search: