Live data from Hacker News

Linux is an interpreter

astrid.tech

21–30 of 65 posts

Re: Linux is an interpreter

#21
post #18

Earlier quoted context omitted.

> if we can't afford 1.50$/mo, then we aren't really professionals and are just coasting on real infrastructure subsidized by professionals This is a strange claim. Whether someone is getting paid or not to do something is what determines who is a professional, not whether or how much they're paying someone else. (And that's the only thing that matters, unlike the way that "professional" is used as a euphemism in Ame…

I think the sense of the word professional here is not as a boolean professional/amateur, but the sense of professionalism, the characteristic of taking business seriously, not letting personal matters intervene, and in this case, investing into tools. To put an example, suppose you hire a painter, and they show up with non-work attire, no ladder, no brush, they ask you to buy a can of paint for them and a brush. Com…

It always depends on results. It can be unprofessional to design a system that takes an external variable like S3 for granted, especially if it's not needed. As long as the hack isn't worse than the official $1.50 happy-path, you might as well save the end-customer a monthly fee and reduce your attack surface.

I think hacks like these have a positive effect on the industry. It pushes back on meaningless, encroaching monetization and encourages Conatbo to reevaluate their service offerings to ensure they justify the price.

Re: Linux is an interpreter

#22
This article was painful to read because of all the misconceptions. A cpio archive is not a filesystem. Author uses initramfs, which is based on tmpfs. Linux can extract cpio to tmpfs. An archive of files and directories is in itself not a program.

Just because something looks similar doesn't mean it's equivalent. Binary programs are executed on the CPU, so if there's an interpreter involed it's hiding in the hardware environment. That's outside the scope of an OS kernel.

If you have a shell script in your filesystem and run it, you need to also provide the shell that interprets the script. Author omits this detail and confuses the kernel with the shell program.

Linux can easily be compiled without support for initramfs and ramdisk. It can still boot and run whatever userland sits in the filesystem.

"Linux initrd interpreter" hurts my brain. That's not how it works.

Edit: should've read further. Still a backwards way of explaining things imho.

Re: Linux is an interpreter

#23
post #22

This article was painful to read because of all the misconceptions. A cpio archive is not a filesystem. Author uses initramfs, which is based on tmpfs. Linux can extract cpio to tmpfs. An archive of files and directories is in itself not a program. Just because something looks similar doesn't mean it's equivalent. Binary programs are executed on the CPU, so if there's an interpreter involed it's hiding in the hardwar…

At least it isn't AI slop!

Re: Linux is an interpreter

#25
man ld.so:

... (in which case no command-line options to the dynamic linker can be passed and, in the ELF case, the dynamic linker which is stored in the .interp section of the program is executed)

note how the ELF section is named.

Re: Linux is an interpreter

#26
post #22

This article was painful to read because of all the misconceptions. A cpio archive is not a filesystem. Author uses initramfs, which is based on tmpfs. Linux can extract cpio to tmpfs. An archive of files and directories is in itself not a program. Just because something looks similar doesn't mean it's equivalent. Binary programs are executed on the CPU, so if there's an interpreter involed it's hiding in the hardwar…

At least it isn't AI slop!

I dunno, sure seems like "AI research" at least.

Re: Linux is an interpreter

#27
post #22

This article was painful to read because of all the misconceptions. A cpio archive is not a filesystem. Author uses initramfs, which is based on tmpfs. Linux can extract cpio to tmpfs. An archive of files and directories is in itself not a program. Just because something looks similar doesn't mean it's equivalent. Binary programs are executed on the CPU, so if there's an interpreter involed it's hiding in the hardwar…

> An archive of files and directories is in itself not a program.

Okay, but you can make the same argument to say that ELF files aren't programs in and of themselves either. In fact, some ELF files are dynamic libraries without an entrypoint, and therefore not actually executable in any meaningful way unless connected to yet another program.

If you can accept that some ELF files are executables and some aren't, then you can also accept that some CPIOs are executables and some aren't. What's the difference between ld.so unpacking an ELF file into RAM and running its entrypoint, and the Linux kernel unpacking an initramfs into RAM and running its entrypoint?

Re: Linux is an interpreter

#28
post #22

This article was painful to read because of all the misconceptions. A cpio archive is not a filesystem. Author uses initramfs, which is based on tmpfs. Linux can extract cpio to tmpfs. An archive of files and directories is in itself not a program. Just because something looks similar doesn't mean it's equivalent. Binary programs are executed on the CPU, so if there's an interpreter involed it's hiding in the hardwar…

It's the init in the cpio which is the interpeted program, and the rest of the cpio is memory for this interpeted progam.

Re: Linux is an interpreter

#30
post #25

man ld.so: ... (in which case no command-line options to the dynamic linker can be passed and, in the ELF case, the dynamic linker which is stored in the .interp section of the program is executed) note how the ELF section is named.

[dead]
Post reply on HN