suspended_state

> [...] LLMs are from the get-go a bad idea, a bullshit generating machine.

Is that a matter of opinion, or a fact (in which case you should be able to back it up)?

Of course, but does it mean that my argument is flawed? You're just shifting the discourse, without disproving anything. Do you claim that the web was useful for everyone on day one, or as useful as it is today for everyone?

I could just do the same as GP, and qualify MUDs and BBS as poor proxies for social interactions that are much more elaborate and vibrant in person.

In the early days of the web, there wasn't much we could do with it other than making silly pages with blinking texts or under construction animated GIFs. You need to give it some time before judging a new technology.

The point is that not every web crawler is out there to scrape websites.

I don't know what to think about Systemd.

I think however that a lot of hate comes from:

- a very opaque structure: it's actually not that opaque, since configuration files are still plain text, and better yet with more structure, but it first appears as inscrutable, since the programs aren't shell scripts;

- a set of new tools to learn: Systemd doesn't make use of the existing Unix tool-set (sed, awk, etc), ie. the vocabulary most sysadmins are familiar with in this ecosystem.

It seems on the outset that Systemd is trying to get away from the traditional Unix "one program should do one and only one thing well" (which is colloquial phrasing for separation of concerns).

Still, one idea that occurred to me is that in the early days of Unix, system programs might have been quite simple, with very few options (that man pages were probably very short), but that's clearly not the case nowadays. So haven't we left the "one program should do one and only one thing well" paradigm a long time ago anyway?

Actually, I think that one crucial issue with systemd is its specialization: can it be used for anything else than service management? At first, this seems to clash with the Unix principle, but even awk and sed are meant to do one thing, yet their field of action is very general, not just confined to handle one style of files or perform one style of transformation.

Let's first get the obvious out of the way: caching is not an abstraction, the "Storage" abstraction is what enables caching to be implemented. If I had to put Caching in a category, I would say that it's an optimization strategy.

But that's not really what the blogpost is about. The issue that it tries to discuss is the fact that this abstraction is often imposed to us, without any way to control its behaviour. That's the examples of the LOAD_NAME in python he points at. Without having a clear understanding of the access patterns the application mostly uses, a caching strategy cannot be well defined, and you'll end up with an inadequate solution.

It is very likely that this device works by perceiving and interpreting brain waves. Actually, from the article:

> “We recorded neural activities from single neurons, which is the highest resolution of information we can get from our brain,” Wairagkar says. The signal registered by the electrodes was then sent to an AI algorithm called a neural decoder that deciphered those signals and extracted speech features such as pitch or voicing.

Yes, but is it as efficient?

Doesn't this depend on the point of view?

Records are product types. Variants are sum types.

https://www.cs.princeton.edu/courses/archive/fall05/cos441/n...

It's the VHS of digital image compression and storage.

Indeed, I'm not a regular Python practitioner. I had to use it from time to time because it's the language chosen by the tools I happened to use at that time, like Blender, or Django. In the former case, it wasn't very enjoyable (which says a lot about my skills in that area, or rather lack thereof), while in the latter case I found it quite likeable. So that's my background as far as python goes.

I must admit that I largely prefer static typing, which is why I got interested in that article. It's true that trying to shoehorn this feature in the Python ecosystem is an uphill battle: there's a lot of good engineering skill spent on this.

Perhaps there's a connection to make between this situation and an old theorem about incompleteness?

https://copilot.microsoft.com/shares/2LpT2HFBa3m6jYxUhk9fW

(was generated in quick mode, so you might want to double check).

I am not well versed in python programming, this is just my opinion as an outsider.

For anyone interested in using these tools, I suggest reading the following:

https://www.reddit.com/r/Python/comments/10zdidm/why_type_hi...

That post should probably be taken lightly, but I think that the goal there is to understand that even with the best typing tools, you will have troubles, unless you start by establishing good practices.

For example, Django is large code base, and if you look at it, you will observe that the code is consistent in which features of python are used and how; this project passes the stricter type checking test without troubles. Likewise, Meta certainly has a very large code base (why develop a type checker otherwise?), and they must have figured out that they cannot let their programmers write code however they like; I guess their type checker is the stricter one for that reason.

Python, AFAIK, has many features, a very permissive runtime, and perhaps (not unlike C++) only some limited subset should be used at any time to ensure that the code is manageable. Unfortunately, that subset is probably different depending on who you ask, and what you aim to do.

(Interestingly, the Reddit post somehow reminded me of the hurdles Rust people have getting the Linux kernel guys to accept their practice: C has a much simpler and carefree type system, but Rust being much more strict rubs those C guys the wrong way).

> The first thing to note is that there is no indication that foo or bar can fail.

I don't see how this is different from traditional programming.

> I do think this is a really neat concept, but I have major reservations about the readability/debuggability of the resulting code.

I don't think that readability will be harmed, but I can understand your concerns about debugging. I feel that cluttering the code with consistency/error checks everywhere actually harms much more readability.

The original question was: can quaternions be used in place of matrices to perform LLMs tasks, and the answer is: quaternions are 4 dimensions, with the implied meaning that matrices can cover different dimentionalities, which are needed for LLMs (and neural network in general).

> the quote is the part between the dots; my comment is about why the number of developer resources might limited.

Very confusing. On HN, it's customary to follow the email-style convention of using the '>' symbol for quotes and placing them on separate lines.

Who are you quoting here?

CSS at the time was still a leaky abstraction: in order to get things working, you had to include extraneous DIVs in the HTML code as anchors for the CSS rules. The standard body has attempted to address this issue with pseudo-elements and pseudo-classes as well as other features I may not be aware of.

At least though, these extra DIVs weren't disrupting the page layout (eg. when disabling the CSS - something that was still possible at the time), which was beneficial for accessibility.

>> layouts were implemented by abusing table elements to create a grid.

> Never understood what was actually wrong with it

Separation of concerns?

I don't understand the following from the article:

"The more root growth, the more carbon in the soil, which can be a source of food for soil bacteria that multiply under warming temperatures. When soil in a rice paddy is waterlogged, oxygen gets depleted, causing the soil bacteria to rely further on arsenic to generate energy. The end result is more arsenic building up in the rice paddy, and more roots to take it up to the developing grain."

It is said that the bacteria rely further on arsenic to generate energy, where I understand "rely on" as "consume". So how would this lead to a build up of arsenic? If anything, it should lead to the opposite, shouldn't it? Unless they meant to say that because of the lack of oxygen in the soil, bacteria rely on anaerobic methods to produce energy, which has arsenic as a by-product?

If that is possible in Zig to have a "void" struct field, then you are correct, but wouldn't this block a third-party user from defining a struct field named data later?

I think the main advantage of the intrusive definition is that you can use it to implement the non intrusive one easily, whereas the reverse isn't possible.

I found the idea of polling DB queries interesting. They basically took what is done with HTTP and pushed it down the stack directly in the DB server, eliminating the extra SQL round trips one needs to make server-side in order to provide updates. Neat!

The old station on google maps: https://maps.app.goo.gl/m5m7A8rKKgJwvbAj9

The location on openstreetmap: https://www.openstreetmap.org/node/5694806014

Reddit has a much broader aim than Slashdot ever did. Slashdot _is_ just about discussing news, just like HN. Reddit is basically a BBS with no particular topic or usage in mind. They cannot be compared.

The company history page on the corporate web site of Mitsubishi Pencils provides a reason behind the name: https://www.mpuni.co.jp/en/company/history.html

It's not clear why the 3 companies got the right to use the same logo. Perhaps they could each demonstrate that they used that logo before Japanese law required for it to be formally submitted for trademark?

I was thinking about that too. I wasn't so sure but this SO entry eclipsed my doubts:

https://stackoverflow.com/questions/7222164/mmap-an-entire-l...

I guess that the following statement would be true: if the process cannot load the whole file in memory and allocate memory for the model at the same time, then the it won't be able to run successfully. Strictly speaking, the sentence I quoted doesn't derive from that. This is just me quibbling though, because the intended meaning was most likely what you said.

That's very nice work, and many interesting concepts introduced in the post (for example, arenas, length bounded strings, the Cut struct).

One caveat though:

> If the OBJ source cannot fit in memory, then the model won’t fit in memory.

I don't think that this is true: a (single precision) float textual representation is typically equal or larger than its binary representation (4 bytes), the floating point used in the renderer given later in the post. The numbers given in the cube example are unlikely to occur in real world examples, where one would probably expect more than 2 digits of decimal precision. That being said, for double precision floats, it might be true in many scenarios, but I would not make that a cardinal rule anyway.

This corner cut fits within the objective of the post, which, imho, isn't to make the most efficient program, but provide a great foundation in C to build upon.