Peter Horvath

@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.

Removed by mod

@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.

Removed by mod

@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.

@Creat @misk You are right, the best solution to deal such evil hardware is that you NEVER buy it.

@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 They have obviously zero interest to optimize anything. Just see, how often can it happen that you can decrease the video quality of a game to make it useable on older machines. And why even do you need to it, while 20 years ago there was the same problem, and now the machines are 1000x faster.

@unexposedhazard @cm0002 Linux will be obviously slower. But not intolerably 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?

@wltr @canthangmightstain Main obstacle before Linux was the stupidity, 30 years ago exactly like today.

@Butterphinger @RidcullyTheBrown I deeply feel that you are right… but if you say such things, like “walled gardens via client access”, I think you have a brain problem.

Wtf is a “walled gardens via client access”?

@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.

@Know_not_Scotty_does If the manufacturer gave linux drivers, they are probably inserted into your linux distribution. So you do not need to install anything.

@victorz @Know_not_Scotty_does “Just install the driver”, so you must have a windows with it, too, only to use your own printer…

@thingsiplay Yes, you are right. I think you could trace the parent, by a gdb, and then execute a wait() in its name.

@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.

@CameronDev Your comment clearly shows that you have not ever rooted an Android.

Only for you: rooting the android requires various partition rewriting, decrypting etc operations, all of them in close interaction with the bootloader. It also interacts with various system components, which were originally open source, but the manufacturers modified them on unknown ways.

You school example of the criminal stupidity!

@CameronDev My impression is that you have not ever heard about your right over your own property (aka “rooting”), how the mafia tries to harden as they only can, committing both various license violations, illegal data collection, eavesdropping, spam and cheat. You do not understand, what is this comment about, and you go yet more far: instead of recognizing your own stupidity, you are even boosting that by thinking that I am.