By definition /dev/null sinks anything written to it, so it doesn't matter if you write in append mode or not, it's all discarded. Since it doesn't store the data, there's nothing to append to, really.
So in the end, it's just shorter to write > /dev/null with one > sign.
As for the edited addition:
The open(2) manpage says lseek is called before each write to a file in append mode.
If you read closely, you'll see it says (emphasis mine):
the file offset is positioned at the end of the file, as if with lseek(2)
Meaning, it doesn't (need to) actually call the lseek system call, and the effect is not strictly the same either: calling lseek(fd, SEEK_END, 0); write(fd, buf, size); without O_APPEND isn't the same as a write in append mode, since with separate calls another process could write to the file in between the system calls, trashing the appended data. In append mode, this doesn't happen (except over NFS, which doesn't support real append mode).
The text in the standard doesn't mention lseek at that point, only that writes shall go the end of the file.
So, is truncating /dev/null actually unspecified?
Judging by the scripture you refer to, apparently it's implementation-defined. Meaning that any sane implementation will do the same as with pipes and TTY's, namely, nothing. An insane implementation might do something else, and perhaps truncation might mean something sensible in the case of some other device file.
And do the lseek calls have any impact on write performance?
Test it. It's the only way to know for sure on a given system. Or read the source to see where the append mode changes the behaviour, if anywhere.
Those are simply (special) files. They only serve as "pointers" to the actual device. (i.e. the driver module inside the kernel.)
If some command/service already opened that file, it already has a handle to the device and will continue working.
If some command/service tries to open a new connection, it will try to access that file and fail because of "file not found".
Usually those files are populated by udev, which automatically creates them at system startup and on special events like plugging in a USB device, but you could also manually create those using mknod.
Best Answer
Devices on Unix have a type (e.g. character or block), a major number (which typically refers to a driver), and a minor number (which typically refers to an instance).
So, for example:
This is a block device, major 253, minor 0.
If we look at
/proc/deviceswe see it ends with something similar toSo we can see that 253 is "virtblk". Which makes sense, since this is a virtual machine with virtual disks!
The minor number, for this driver, refers to the block device and partition in the device
There are some special drivers which don't refer to "real" hardware. eg
This is a character device, major 1, minor 3.
/proc/devicestells us driver 1We can see this "mem" driver handles a few other devices as well