"CSS exists, so you can separate the words from the layout. That way you can restyle the same content for different types of user agent, whether it be the blind, pda users, or some other niche group."
I don't see why it is necessary to separate the words from the layout in order to be able to "re-style", as you said, the content of a webpage for different types of user agent or for readability reasons.
"What slashdot doesn't allow with its html 3.2 layout is taking the regular slashdot page and stripping out the layout, colors or content you don't need or want."
I'm not sure what you mean, in detail, by stripping out the "layout" or "content". As for the colors, why not use your browser settings to override them?
"we're transitioning between the old way of doing things (in-page layout) and the new way (completely separate layout and content)"
I don't understand why the new way is necessarily any better than the "old" way.
"Don't like the font some site is using? Change it."
That can be done easily using browser settings, which are automatically remembered across sessions.
"Don't like it that the site menu is on the right instead of the left? Move it over."
Firstly, I don't see why making such a change entails the use of CSS. Secondly, I think such a change steps over an important dividing line between (i) changes to the general appearance of a webpage such as font size, color, etc, which may be used reasonably by anybody to improve its readability according to eyesight, and (ii) changes to the detailed structure and organisation of the webpage which are unreasonable from the point of view of the author(s) because they distort the intended interrelationships of the different parts of a webpage, thus damaging its artistic integrity and even raising legal issues.
"We're no longer in the days of html 3.2 (well, ok, slashdot still is, but that's beside the point). A browser nowadays has to do a lot more than just render html."
There is one thing above all else that interests me in a webpage -- ideas as expressed by words and images. The ideas are always more important to me than any web layout scheme such as CSS. It is much to Slashdot's credit that it uses good old HTML 3.x. I like reading text that is typeset in just one font, in black on a white background and at one readable and unvarying font-size, which is almost exactly what Slashdot gives. I don't like reading in the presence of distracting layouts chosen for me according to someone else's personal taste in CSS, or of distracting images that someone else has decided should appear during every mouse-over movement on buttons and dynamic menus.
The Rules of Writing for Web Authors and Designers:
Rule #1:
It is words that express ideas.
Rule #2:
Layout, CSS and scripting languages are a distraction from the main task of writing the right words to express the ideas.
Rule #3:
Is there a way to read your webpage if you have disabled CSS, JavaScript, and Java? If not, your webpage is effectively closed to some visitors. Make another version of the webpage that is more widely readable. See Rules #1 and #2.
The world's first snooker playing robot was the subject of a QED programme shown on 16th March 1988 on BBC TV in which the 1988 world snooker champion, Steve Davis, played and won a match against the robot. I helped to develop the image-processing software for the robot's vision system. The research project ran from 1986-1988 and was funded by BBC TV. There is further information about the project here.
I'm sorry but FLAC is not "off-topic" in an article about Theora. Theora is meant to be able to work with FLAC. FLAC is actually an important part of the Xiph.org project. If you haven't heard much about them, have a look at Ogg and FLAC
Has anyone managed to configure and compile any version of FLAC (Free Lossless Audio Codec) after having installed all the prerequisites like ogg* and theora*? I get the errors below despite having the recommended version of ogg devel installed and despite having tried various versions of FLAC from 2001 tarball thru to current CVS FLAC.
cd flac./configure checking for a BSD-compatible install.../usr/bin6/ginstall -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... no checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking for style of include used by make... GNU checking for gcc... gcc checking for C compiler default output... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking dependency style of gcc... gcc3 checking for ld used by GCC.../usr/i486-slackware-linux/bin/ld checking if the linker (/usr/i486-slackware-linux/bin/ld) is GNU ld... yes checking for/usr/i486-slackware-linux/bin/ld option to reload object files... -r checking for BSD-compatible nm.../usr/bin6/nm -B checking for a sed that does not truncate output.../usr/bin6/sed checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking command to parse/usr/bin6/nm -B output... ok checking how to run the C preprocessor... gcc -E checking for egrep... grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for ranlib... ranlib checking for strip... strip checking for objdir....libs checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc static flag -static works... yes checking if gcc supports -c -o file.o... yes checking if gcc supports -c -o file.lo... yes checking if gcc supports -fno-rtti -fno-exceptions... yes checking whether the linker (/usr/i486-slackware-linux/bin/ld) supports shared libraries... yes checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking dynamic linker characteristics... GNU/Linux ld.so checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking whether -lc should be explicitly linked in... no creating libtool checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking dependency style of g++... gcc3 checking whether make sets $(MAKE)... (cached) yes checking for getopt_long... yes./configure: line 8616: syntax error near unexpected token `have_ogg=yes,'./configure: line 8616: `XIPH_PATH_OGG(have_ogg=yes, { echo "$as_me:$LINENO: WAR NING: *** Ogg development enviroment not installed - Ogg support will not be bui lt" >&5'
yes, it is
dnl check for ogg library XIPH_PATH_OGG(have_ogg=yes, AC_MSG_WARN([*** Ogg development enviroment not inst alled - Ogg support will not be built])) AM_CONDITIONAL(FLaC__HAS_OGG, [test x$have_ogg = xyes]) if test x$have_ogg = xyes ; then AC_DEFINE(FLAC__HAS_OGG) fi
In my experience, being a pianist and knowing several professional concert pianists, the sound quality of the latest Yamaha digital pianos (MIDI pianos) - especially the Yamaha Clavinova CLP-170 (Flash website) - is as good as many acoustic grand pianos. In practice, the sound quality is usually better because acoustic pianos need but, often do not get, regular tuning.
Quit telling me to read what you wrote. I understood your original post. You've mistakenly taken my reply as a contradiction of your statement that there is no evidence of widespread neurogenesis in the adult human brain. I only disagreed with the rest of what you said because you went on to imply that human memory formation is primarily based on synapse formation rather than neurogenesis. You are wrong to say neurogenesis is known to play a minor part in memory formation. The relative importance of each of the currently known mechanisms is unknown. Nobody understands or even knows all of the mechanisms of human memory formation, let alone their interactions. Moreover, it's misleading to describe the hippocampus as just a "very small, specific area" because it's known to have a critical role in learning and memory formation. Be gracious enough to admit you're talking out of your hat. One of us knows a lot more about neuroscience than does the other. I wonder who that is and why.
"I realize you're just picking a nit... I'm just picking one in return." That wasn't my motivation. Was it yours? If so, how petty.
"Your brain is slowly rotting away...but it's a long process, and you've got lots of time". Why?
"a 2.6.x kernel is no longer self-bootable from floppy (it only worked on i386 anyway)"
Are you sure? I can't find any change like that mentioned in Documentation/*. In fact many of the kernel docs suggest using a boot floppy.
"Don't count on ever being able to use a non-standard formated floppy on any given machine."
All I can say is they work ok here. On the test machine both reading and writing 1760kB-formatted floppies work reliably in post-boot Linux. The bit that doesn't work is LILO + BIOS at boot time. The BIOS only understands how to boot standard 1440kB-formatted floppies.
FYI I managed to squeeze a 2.6.2 bzImage onto a 1440kB formatted floppy by a combination of
removing even more functionality in the kconfig:
CONFIG_PNPBIOS CONFIG_DEVFS_FS CONFIG_DEVFS_MO UNT CONFIG_DEVPTS_FS CONFIG_PCI_GOANY
optimizing for size under CONFIG_EMBEDDED.
which shrank the bzImage to 1381222 bytes -- just within the 1474560 bytes of a 1440kB-formatted floppy. One minor holdup: at first I couldn't get a bootable system because PnPBIOS kept crashing, so I removed it and then the system booted ok. Apparently several of the components on this very new Via motherboard are not yet supported in PnPBIOS in the 2.6.2 kernel.
Yeah I know CONFIG_EMBEDDED is standard in the sense of being in the kconfig menus. What I meant was removing functionality most people leave in would make the kernel non-standard and possibly non-functional. I wasn't sure I could afford to lose any of the functionality listed under CONFIG_EMBEDDED. You're right about "Optimize for size" - it's probably worth a try because bzImage is quite close to 1440kBytes. I'll be pleased if it does.
I wonder what's going wrong with booting by LILO from a high-capacity 1760kByte floppy. If it worked, there'd be tons of room spare. Probably enough for a 2.7 kernel:)
Yeah, it'd be ok for a PC but the current portable devices weren't designed to be deployed with anything like that so I'm looking for a bandaid that gets them up and running via the boot floppy method.
Thanks for the tips. It's an interesting build situation. I'd like to be able to use a non-standard kernel such as CONFIG_EMBEDDED or tinyLinux to get a smaller bzImage but I can't. I have to use a normal fully functional kernel and find some way of getting the 2.6.2 bzImage onto a boot floppy. There are two coupled machines - one is a normal PC, the other has the same CPU but no HD/bootROM. There are certain operational requirements which mean the same kernel image needs to be running on both machines.
The crazy thing is a 2.6.2 bzImage fits on a high-capacity formatted boot floppy and LILO can do high-capacity (/dev/fd0u1760) boot floppies but for some reason the resulting boot floppies always hang at the LILO prompt. I guess the BIOS isn't able to understand the high cap. format (no BIOS option for high cap. floppies either).
If there's no other easier way, I'll modify LILO to load a bzImage that is split over two floppies (the machine has two floppy drives), sorta like bootfloppy1, bootfloppy2, and then onto the root device.
Wow, this is a tough one. I'd like to port some 2.4.x drivers to 2.6.2 but I have to use a boot floppy for portable devices without a HD or bootROM and the kernel is so HUGE it literally won't fit onto a boot floppy and LILO doesn't seem to work with high-capacity floppies (fdformat/dev/fd0u1760, but LILO fails at the LILO prompt with "40 40 40..."):
ls -l arch/i386/boot/bzImage
1472687 arch/i386/boot/bzImage
I've kept my kernel config to the absolute minimum and made everything as modular as possible. On 2.4.24 the bzImage was only 1056223 bytes, now it's jumped by 400kBytes.
Has anyone any useful tips for cutting the "bloat"?
"Well, that 95% can't get infected with blaster anyway"
Why not? Even if a PC is in an area of the world without any internet connection it may still be connected to a local area network and can still be attacked any number of ways including by infection from an MSBlaster-infected PC on the same LAN. It's not uncommon even for a PC which doesn't usually have an internet connection to be taken occasionally to somewhere which does have internet access such as an educational institution and directly connected to the internet from there in order to download updates, send emails, etc -- the only way of getting (occasional) internet access in some places.
"1994 called. It wants its internet connection back."
Haven't you got anything useful to say? I don't have any choice but to use this nominally 56kBps but actually 19kBps internet connection. Don't forget 95% of the world's population is still stuck with a 0kBps internet connection.
When your only link to the internet runs at 19kBps or less due to telephone line noise, you're paying for the internet telephone call by the second, and you are given a PDF file which turns out to be 1.4Megabytes in size, the first thing I do is hit the cancel button and forget it. Can you summarise the conclusions or does anyone have a small ASCII version of the file please?
Actually X provides a mechanism for supporting every conceivable datatype; anyone can define a property using XInternAtom() and XChangeProperty() on an X-Window in your X application or on the root window, encoding an arbitrary datatype into the bits of the property. This is all fully described in the X design documentation. especially in Xlib C Programming X Interface, Chapter 4, Section 4.3. See also the source code for xprop.c for a detailed example of how to use X properties.
Conclusion: You don't have to change the API of X. X is already very extendable.
Your addiction to bold font is almost as charming as your tedious illogic.
Are you really unable without further assistance, as appears to be the case, to work out how to encode and decode an arbitrary datatype in a sequence of bits in an X-Window property for the purpose of implementing any standard form of inter-application communications including the limited special case of the clipboard concept? If that were the case, it would follow you are not a programmer and not very bright, or perhaps just not a programmer. Can you disprove the premise by proving you understand the concept? Please note that bits can represent non-ASCII datatypes.
Most applications for Linux, including the ones you mentioned, are written by different groups of people with different goals. Consistency of user-interfaces such as cut-and-paste facilities between several different projects requires cooperation between the projects such as mutual agreement on which datatypes they want to be able to communicate. In the case of the clipboard concept, which is easily implementable for arbitrary datatypes using X-Window properties [xprop.c and Gettys et al. (1991), "X-Lib - C Language X Interface", Chapter 4, Section 4.3], a programmer can design an X application to cut-and-paste a range of one or more datatypes D1,...,Dn within that application, whereas cut-and-paste to and from other X applications can work only in so far as they have been programmed to cut-and-paste some or all of the same datatypes D1,...,Dn. Contrary to your claims in your habitual bold font, it follows, logically, that consistency measured in terms of the number of supported datatypes for cut-and-paste among real X applications is a function of programmer choice, not of the level of complexity of the design of X. Q.E.D.
P.S. I hope you don't list the Japanese language as a forte of yours. I used "shigoto" advisedly and most appropriately to imply you wouldn't do work such as reading the X design documentation even if you were paid to do so. Of course I could comment on your grammar but I shall refrain for fear of encouraging you to return peddling new misleading exemplars, no doubt in bold font too.
On local displays X can use the shared memory extension but it is the X application programmers' responsibility to use it.
X applications which have been correctly programmed and which use the shared memory extension do run fast on local displays. The speed depends a lot on which X server software you use. If you use the free XFree86 implementation, just remember the graphics drivers for most chipsets are not optimised because they have been written by the XFree86 project without the benefit, in most cases, of having programming information for the graphics cards from the manufacturers.
Slashdot Mirror
I don't see why it is necessary to separate the words from the layout in order to be able to "re-style", as you said, the content of a webpage for different types of user agent or for readability reasons.
I'm not sure what you mean, in detail, by stripping out the "layout" or "content". As for the colors, why not use your browser settings to override them?
I don't understand why the new way is necessarily any better than the "old" way.
That can be done easily using browser settings, which are automatically remembered across sessions.
Firstly, I don't see why making such a change entails the use of CSS. Secondly, I think such a change steps over an important dividing line between (i) changes to the general appearance of a webpage such as font size, color, etc, which may be used reasonably by anybody to improve its readability according to eyesight, and (ii) changes to the detailed structure and organisation of the webpage which are unreasonable from the point of view of the author(s) because they distort the intended interrelationships of the different parts of a webpage, thus damaging its artistic integrity and even raising legal issues.
There is one thing above all else that interests me in a webpage -- ideas as expressed by words and images. The ideas are always more important to me than any web layout scheme such as CSS. It is much to Slashdot's credit that it uses good old HTML 3.x. I like reading text that is typeset in just one font, in black on a white background and at one readable and unvarying font-size, which is almost exactly what Slashdot gives. I don't like reading in the presence of distracting layouts chosen for me according to someone else's personal taste in CSS, or of distracting images that someone else has decided should appear during every mouse-over movement on buttons and dynamic menus.
The Rules of Writing for Web Authors and Designers:
Rule #1:
Rule #2:
Rule #3:
As it happens, the most cost-effective high-capacity storage technology remains the hard-drive based on magnetic media.
You must have missed something; the robot's wit was legendary.
The world's first snooker playing robot was the subject of a QED programme shown on 16th March 1988 on BBC TV in which the 1988 world snooker champion, Steve Davis, played and won a match against the robot. I helped to develop the image-processing software for the robot's vision system. The research project ran from 1986-1988 and was funded by BBC TV. There is further information about the project here.
- AMD64 CPU at or above 3000+ AMD rating
- nVidia graphics
- 17" TFT display
It seems every laptop fails to meet one or more of my above criteria.--- must have
--- not ATI or anyone else
--- not 15"
I'm sorry but FLAC is not "off-topic" in an article about Theora. Theora is meant to be able to work with FLAC. FLAC is actually an important part of the Xiph.org project. If you haven't heard much about them, have a look at Ogg and FLAC
Has anyone managed to configure and compile any version of FLAC (Free Lossless Audio Codec) after having installed all the prerequisites like ogg* and theora*? I get the errors below despite having the recommended version of ogg devel installed and despite having tried various versions of FLAC from 2001 tarball thru to current CVS FLAC.
./configure /usr/bin6/ginstall -c checking whether build environment is sane... yes /usr/i486-slackware-linux/bin/ld /usr/i486-slackware-linux/bin/ld option to reload object files... -r /usr/bin6/nm -B /usr/bin6/sed checking whether ln -s works... yes /usr/bin6/nm -B output... ok .libs ./configure: line 8616: syntax error near unexpected token `have_ogg=yes,' ./configure: line 8616: `XIPH_PATH_OGG(have_ogg=yes, { echo "$as_me:$LINENO: WAR
cd flac
checking for a BSD-compatible install...
checking for gawk... gawk checking whether make sets $(MAKE)... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking for style of include used by make... GNU checking for gcc... gcc
checking for C compiler default output... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking dependency style of gcc... gcc3
checking for ld used by GCC...
checking if the linker (/usr/i486-slackware-linux/bin/ld) is GNU ld... yes
checking for
checking for BSD-compatible nm...
checking for a sed that does not truncate output...
checking how to recognise dependent libraries... pass_all
checking command to parse
checking how to run the C preprocessor... gcc -E
checking for egrep... grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking for ranlib... ranlib
checking for strip... strip
checking for objdir...
checking for gcc option to produce PIC... -fPIC
checking if gcc PIC flag -fPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.lo... yes
checking if gcc supports -fno-rtti -fno-exceptions... yes
checking whether the linker (/usr/i486-slackware-linux/bin/ld) supports shared libraries... yes
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking dynamic linker characteristics... GNU/Linux ld.so
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking whether -lc should be explicitly linked in... no
creating libtool checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking whether make sets $(MAKE)... (cached) yes
checking for getopt_long... yes
NING: *** Ogg development enviroment not installed - Ogg support will not be bui
lt" >&5'
yes, it is
dnl check for ogg library
XIPH_PATH_OGG(have_ogg=yes, AC_MSG_WARN([*** Ogg development enviroment not inst
alled - Ogg support will not be built]))
AM_CONDITIONAL(FLaC__HAS_OGG, [test x$have_ogg = xyes])
if test x$have_ogg = xyes ; then
AC_DEFINE(FLAC__HAS_OGG)
fi
In my experience, being a pianist and knowing several professional concert pianists, the sound quality of the latest Yamaha digital pianos (MIDI pianos) - especially the Yamaha Clavinova CLP-170 (Flash website) - is as good as many acoustic grand pianos. In practice, the sound quality is usually better because acoustic pianos need but, often do not get, regular tuning.
"I realize you're just picking a nit... I'm just picking one in return."
That wasn't my motivation. Was it yours? If so, how petty.
"Your brain is slowly rotting away...but it's a long process, and you've got lots of time".
Why?
I think there's already been enough competent research based on human and primate studies to confirm beyond reasonable doubt that neurogenesis does occur in at least one region of the adult human brain, namely in the hippocampus , a region that is essential for learning .
Are you sure? I can't find any change like that mentioned in Documentation/*. In fact many of the kernel docs suggest using a boot floppy.
- "Don't count on ever being able to use a non-standard formated floppy on any given machine."
All I can say is they work ok here. On the test machine both reading and writing 1760kB-formatted floppies work reliably in post-boot Linux. The bit that doesn't work is LILO + BIOS at boot time. The BIOS only understands how to boot standard 1440kB-formatted floppies.CONFIG_PNPBIOSO UNT
CONFIG_DEVFS_FS
CONFIG_DEVFS_M
CONFIG_DEVPTS_FS
CONFIG_PCI_GOANY
which shrank the bzImage to 1381222 bytes -- just within the 1474560 bytes of a 1440kB-formatted floppy. One minor holdup: at first I couldn't get a bootable system because PnPBIOS kept crashing, so I removed it and then the system booted ok. Apparently several of the components on this very new Via motherboard are not yet supported in PnPBIOS in the 2.6.2 kernel.
I wonder what's going wrong with booting by LILO from a high-capacity 1760kByte floppy. If it worked, there'd be tons of room spare. Probably enough for a 2.7 kernel:)
Yeah, it'd be ok for a PC but the current portable devices weren't designed to be deployed with anything like that so I'm looking for a bandaid that gets them up and running via the boot floppy method.
The crazy thing is a 2.6.2 bzImage fits on a high-capacity formatted boot floppy and LILO can do high-capacity (/dev/fd0u1760) boot floppies but for some reason the resulting boot floppies always hang at the LILO prompt. I guess the BIOS isn't able to understand the high cap. format (no BIOS option for high cap. floppies either).
If there's no other easier way, I'll modify LILO to load a bzImage that is split over two floppies (the machine has two floppy drives), sorta like bootfloppy1, bootfloppy2, and then onto the root device.
ls -l arch/i386/boot/bzImage
1472687 arch/i386/boot/bzImage
I've kept my kernel config to the absolute minimum and made everything as modular as possible. On 2.4.24 the bzImage was only 1056223 bytes, now it's jumped by 400kBytes.
Has anyone any useful tips for cutting the "bloat"?
Thank you and Happy Christmas!
Why not? Even if a PC is in an area of the world without any internet connection it may still be connected to a local area network and can still be attacked any number of ways including by infection from an MSBlaster-infected PC on the same LAN. It's not uncommon even for a PC which doesn't usually have an internet connection to be taken occasionally to somewhere which does have internet access such as an educational institution and directly connected to the internet from there in order to download updates, send emails, etc -- the only way of getting (occasional) internet access in some places.
That's a tiny file. Thank you! Happy Christmas!
Haven't you got anything useful to say? I don't have any choice but to use this nominally 56kBps but actually 19kBps internet connection. Don't forget 95% of the world's population is still stuck with a 0kBps internet connection.
When your only link to the internet runs at 19kBps or less due to telephone line noise, you're paying for the internet telephone call by the second, and you are given a PDF file which turns out to be 1.4Megabytes in size, the first thing I do is hit the cancel button and forget it. Can you summarise the conclusions or does anyone have a small ASCII version of the file please?
Actually X provides a mechanism for supporting every conceivable datatype; anyone can define a property using XInternAtom() and XChangeProperty() on an X-Window in your X application or on the root window, encoding an arbitrary datatype into the bits of the property. This is all fully described in the X design documentation. especially in Xlib C Programming X Interface, Chapter 4, Section 4.3 . See also the source code for xprop.c for a detailed example of how to use X properties.
Conclusion: You don't have to change the API of X. X is already very extendable.
Are you really unable without further assistance, as appears to be the case, to work out how to encode and decode an arbitrary datatype in a sequence of bits in an X-Window property for the purpose of implementing any standard form of inter-application communications including the limited special case of the clipboard concept? If that were the case, it would follow you are not a programmer and not very bright, or perhaps just not a programmer. Can you disprove the premise by proving you understand the concept? Please note that bits can represent non-ASCII datatypes.
Most applications for Linux, including the ones you mentioned, are written by different groups of people with different goals. Consistency of user-interfaces such as cut-and-paste facilities between several different projects requires cooperation between the projects such as mutual agreement on which datatypes they want to be able to communicate. In the case of the clipboard concept, which is easily implementable for arbitrary datatypes using X-Window properties [xprop.c and Gettys et al. (1991), "X-Lib - C Language X Interface", Chapter 4, Section 4.3], a programmer can design an X application to cut-and-paste a range of one or more datatypes D1,...,Dn within that application, whereas cut-and-paste to and from other X applications can work only in so far as they have been programmed to cut-and-paste some or all of the same datatypes D1,...,Dn. Contrary to your claims in your habitual bold font, it follows, logically, that consistency measured in terms of the number of supported datatypes for cut-and-paste among real X applications is a function of programmer choice, not of the level of complexity of the design of X. Q.E.D.
P.S. I hope you don't list the Japanese language as a forte of yours. I used "shigoto" advisedly and most appropriately to imply you wouldn't do work such as reading the X design documentation even if you were paid to do so. Of course I could comment on your grammar but I shall refrain for fear of encouraging you to return peddling new misleading exemplars, no doubt in bold font too.
X applications which have been correctly programmed and which use the shared memory extension do run fast on local displays. The speed depends a lot on which X server software you use. If you use the free XFree86 implementation, just remember the graphics drivers for most chipsets are not optimised because they have been written by the XFree86 project without the benefit, in most cases, of having programming information for the graphics cards from the manufacturers.