@forestbeasts @p4rzivalrp2 Quite honestly, I am a bit disappointed on wayland - it promises a fast X, but it does not provide it. The cause of the slow X was not that it is an old monster, the cause was the much lesser developer resources. Wayland has even much lesser.

@davidgro That was a different thing. You can write or read from the physical memory address 0 even on the systems of the today - except that practically all the OS-es are using their paging or memory management to make that address unreeachable. Actually, as far I can remember, on Linux, the addresses between 0 - 65535 are mapped unreachable. If try to write them, you will get SIGSEGV. This is because a memory page is 4K, that is the granularity of the memory permissions. Beside that, we also need SIGSEGV (which would map to a "null pointer dereference" or analog) if it actually tried to access the part of a larger struct (what would be visible as an access to a non-zero, but very small memory address).

C64 had no memory protection, you could read or write anywhere where you wanted. Although it had memory-mapped I/O, meaning that instead of bus-level port communication, all the IO, i.e. communication of the CPU with the chips of the mainboard, happened as if they would be memory. Some chip happily crashed the system on such writes, particularly the CIA did it (general purpose I/O chip and hw clock) for not enough well thought memory operations in the $DC00 - $DFFF range.

You could happily write into 0 on C64. Actually, on the address 1, you could access the chip select pin of some RAM chips, meaning that you could with that switch from the basic ROM into an additional RAM area. Writing to the 0 byte did not had any on the spot visible effect on my experiments, but today I read in the docs, it had actually effect to the GPIO ports related to the memory chips managed at the address 1.

Actually, c64 went even more: the first page, i.e. the addresses between 0-255, very accessible a bit faster, because they required a lesser amount of CPU and data bus cycles. Very important registers, used for important operations, were there.

However, this all is about the C64 hardware. The C64 basic v2.0, which was written by the microsoft, quickly evaporating all my youth nostalgy, had nothing similar to the NULL (of C) or null (of Java). It not even had an "unset", "undefined" or similar type. The 3 types it had, were: 32-bit floating point, 16-bit integer and 0-254 byte long string.

@misk I think these modchip are exactly what would also really need in the android or iEvil world. Although I am not very sure, how could they be attached into a machine.

@davidgro @hunger Last basic variant I worked with was the basic of the commodore machines. It had no NULL. I have also seen vbscript a little, afaik also it had not.

In Java, null does not mean a real 0 value, I think it is more like a static const, more similar to the None type of the Python. Its name is only a helper for the C/C++ guys to better understand a stack trace.

@misk @Creat It is so terrible. But I believe, hardware jailbreaking should long exist, for example by using raspberry pi-s to attach to the wires of the evil hardware on tricky ways. For example, by attaching pins of the memory chips, their bus could be probably locked for a short time (which is not enough yet for the main OS to crash), and their content could be manipulated. The data structures in the RAM are absolutely not protected against anything. On a Unix-related OS, you can easily find a process data structure by its characteristic signatures, and then you can simply change its UID to 0, voila you are root.

Alternatively, you can simply find the keys used to encrypt the disk content.

Alternatively, also finding the cached blocks in the block cache could be possible. By finding a block, you have access to the decrypted disk blocks, and there you can overwrite against anything, for example by giving a +s to your "su" binary.

@unexposedhazard @cm0002 Linux will be obviously slower. Reason is simple, much lesser amount of developer resources are there to optimize it. But that is only one of the sides.

Another side: 20 years ago, bottleneck of the 3D gaming was the cpu/gpu. Now we have 1000 times faster machines. What is the bottleneck? Of course, cpu/gpu. Does not stink here something, uhm?

@EtAl @cm0002 Ubuntu has a pretty well multi-monitor configurator tool, I had not ever any problem with it. Although I use only very rarely multiple monitors, usually there is only two, the embedded one into the laptop and an external over hdmi.

@thingsiplay Sorry you might right! In this case, I would debug the parent process and I would execute the wait() syscalls in its name, but it is hardly autimatizable and probably many people can not do that. Thanks the info!

@thingsiplay Stop their parent process and the zombie will go under init, then init will stop them.

@onlinepersona @Innerworld And what do you think, will the AI agent be ready to the following discussion?