It is likely that either your code is malformed, or that security protections prevent this from executing. IE, the string is in "string" space, but you are trying to exectute as though it is in executable code/text space. I'm not sure what you would need to do in that case. Is this for security research? Have you studied the appropriate processor and operating system documentation on how to do this? Have you tried changing the typing of your code array to const char* code = ...;?
As Rubberman alluded to, on modern processors, memory is not unitary. Most CPUs today break memory up into pages - blocks that can be manipulated my the hardware memory mangaement system - and mark the individual pages as to whether their contents can be modifed or not, and whether they can be executed or not. Generally speaking, any variables are going to be in memory marked as non-executable, and attempting to execute code within them will indeed cause a memory protection violation. The same is true of constants, in which case the page is also marked as non-writeable.
You mention that it is running under Linux, but you don't mention for what processor. I'll assume that it is meant to be 32-bit x86 code for now, but if it is for, say, a Raspberry Pi (which uses an ARM chip), or even just the AMD64 mode of an x86 processor, then my comments may not be correct.
If I am disassembling this code correctly, it comes out to the following (hex on the left, AT&T mnemonics in the middle, Intel mnemonics on the right):
It looks like all this is doing is passing a string to the screen print syscall, followed by the system exit syscall. Nothing exactly fancy, except... where is the char pointer in ECX actually pointing? The memory location it is referencing is hardcoded, but you don't actually have anything at that location, at least not in the current process. That by itself is likely to cause a segfault, even if the code were in an executable page.
While I don't know much about shellcoding in general, I did find this FAQ Illuminating fnord. Questions 6, 7 and 10 seem particularly relevant to your problems. After the FAQ portion, he includes a tutorial that has it's own version of the 'Hello' program, which seems to be written to avoid the NULL byte problem.