You’re still trying to weasel out of being wrong. It’s not an archive nor is it compressed. Go read what a Portable Executable is. It’s not about being diplomatic or whatever. Just admit you’re wrong and go and read about how it actually works. You might learn something.

Bruh an exe is not an archive. Some just happen to contain an archive, not all. As me and the other guy discovered some archive utilities can read them, but what they are doing is closer to a binary analysis tool than unpacking an actual archive. It’s not about being nerdy, it’s about getting your facts right.

Okay that’s actually slightly different from what I was expecting. Does the .text file contain machine code or assembly language by any chance? It seems the archive program can pull out the executable code as well, similar to the binary analysis tools I have worked with.

.reloc is probably the relocation table used by the OS to load the program into an address space.

You are actually correct. They can contain archived files or resources that can be unpacked with an archive program (including on Linux btw), but they aren’t just a zip file. That’s why my Linux archive manager (ark I think) offer to open one, but won’t execute it. They can see the extra content even if they can’t execute the file as intended.

Just because they open in 7-Zip or whatever doesn’t mean they are just a zip file. There are several kinds of archives. EXEs are a special case as well. They aren’t archives at all. Rather they can contain archives or extra content along with being an executable. One reason is self extracting archives. Here an archive is packaged with an extraction program as an exe all in one. The other case is exes that have extra resources like images, videos, graphics textures, etc. Either way it’s an executable plus some extra stuff, not a zip archive. DLLs I am not sure about, but I suspect something similar is happening here.

Next time you should research stuff before posting it on Lemmy. Things are sometimes more complicated than they appear.

docx you are correct about though. Specifically it’s a zip file that contains XML files and resources.

Edit: I actually found an article on self extracting archives, it’s quite an interesting technology to be fair even if it causes confusion: https://en.m.wikipedia.org/wiki/Executable_compression

I think he means the cat

Someone confusing load-store with RISC again.

So you do include ephemeral state that’s a copy of database data? If we were including that then every non-static website has plenty of state, but so does every web server. Whatever definition you are using must be quite odd.

I don’t write web applications for a living and I especially don’t write front ends. I do have to ask though:

What information are you actually keeping in the front end or web server? Surely you don’t need any ephemeral state that isn’t already stored in the browser and/or for you like the URL or form details. Only thing I can think of is the session ID, and that’s normally a server side thing.

I mean I’ve written web sites where there is no JavaScript at all, and the server is stateless or close to it. It’s not a difficult thing to do even. All the actual information is in the database, the web server fetches it, embedds it into a HTML template, and sends it to the client. Client doesn’t store anything and neither does the server. Unless I really don’t understand what you mean by state. You might keep some of your server fetches data from another server using REST or SOAP but that’s only used once as well.

The whole conversation was about backend being similar because you can write a stateless server. Have you forgotten? The issue here is a backend isn’t just one service, you can write a stateless service but you are in fact just moving the statefulness to the database server. The whole backend isn’t simpler than the front-end for that reason. It might be simpler for other reasons, though many popular websites need complex backends.

I am not arguing that a stateless service isn’t a useful concept. I get why people might want that. That’s not what this conversation is about. It’s about the backend vs frontend. Backend to me includes databases and other support services.

You still have to consider ACID vs BASE when choosing a database software/provider. It comes from CAP theorem.

If that’s how people want to talk about it they can, but you can’t eliminate statefulness from the whole stack.

Yes that’s a stateless service but not a stateless backend. A backend to me is everything that doesn’t run on the client, including the database. Databases are not stateless, even distributed databases are not stateless. You can’t just spin up more databases without thinking about replication and consistency.

Sure

The only nuances here seem to be: a) very simple websites need little state (but still aren’t stateless) and b) that you can move the state around to make something look stateless within a narrow view.

How am I being obtuse? You have been trying to trivialise the backend and now frontend as well. Backend isn’t just writing PHP or whatever, it’s setting up database servers, authentication proxies, and all that stuff. Not everything can be stateless.

So I was right then. Colour me surprised.

That data has to be stored somewhere though. So you would still need some kind of database server to store it all or some other solution. That’s what I mean by outsourcing state. Data is still stored in the backend, just in a database rather than a web server.

Doesn’t SPA require polling the web server for more information? I feel like any website which retains information outside of the client device (like anything with a login page) would require state to be stored somewhere on the backend.

I would not be so sure. Maybe for a static web page this is possible. Outside of that I think people are kidding themselves. Writing code that might be stateless in isolation but relies on a database isn’t a stateless server imo, it’s just outsourcing state to another service.

You mean Unix for the first one