Page 4 of 6 FirstFirst ... 23456 LastLast
Results 31 to 40 of 56

Thread: The Linux Kernel Console Is Being Killed Off

  1. #31
    Join Date
    Nov 2011
    Posts
    267

    Default

    Well, it looks like they intend to make libudev optional, it just hasn't been done yet.
    I can't get any numbers on size of a static binary though:
    Code:
    $ ./autogen.sh 
    autoreconf2.50: Entering directory `.'
    autoreconf2.50: configure.ac: not using Gettext
    autoreconf2.50: running: aclocal --force --warnings=all -I m4
    configure.ac:25: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=libxkbcommon
    autoreconf2.50: configure.ac: tracing
    configure.ac:25: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=libxkbcommon
    autoreconf2.50: running: libtoolize --copy --force
    libtoolize: putting auxiliary files in `.'.
    libtoolize: copying file `./ltmain.sh'
    libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
    libtoolize: copying file `m4/libtool.m4'
    libtoolize: copying file `m4/ltoptions.m4'
    libtoolize: copying file `m4/ltsugar.m4'
    libtoolize: copying file `m4/ltversion.m4'
    libtoolize: copying file `m4/lt~obsolete.m4'
    configure.ac:25: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=libxkbcommon
    autoreconf2.50: running: /usr/bin/autoconf --force --warnings=all
    configure.ac:25: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=libxkbcommon
    autoreconf2.50: running: /usr/bin/autoheader --force --warnings=all
    configure.ac:25: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=libxkbcommon
    autoreconf2.50: running: automake --add-missing --copy --force-missing --warnings=all
    configure.ac:25: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=libxkbcommon
    Makefile.am:90: user target `src/xkbcomp/parser.h' defined here...
    automake: ... overrides Automake target `src/xkbcomp/parser.h' defined here
    autoreconf2.50: Leaving directory `.'
    checking for a BSD-compatible install... /usr/bin/install -c
    checking whether build environment is sane... yes
    checking for a thread-safe mkdir -p... /bin/mkdir -p
    checking for gawk... gawk
    checking whether make sets $(MAKE)... yes
    checking whether to disable maintainer-specific portions of Makefiles... yes
    checking for style of include used by make... GNU
    checking for gcc... gcc
    checking whether the C compiler works... yes
    checking for C compiler default output file name... a.out
    checking for suffix of executables... 
    checking whether we are cross compiling... no
    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 ISO C89... none needed
    checking dependency style of gcc... gcc3
    checking how to run the C preprocessor... gcc -E
    checking for grep that handles long lines and -e... /bin/grep
    checking for egrep... /bin/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 minix/config.h usability... no
    checking minix/config.h presence... no
    checking for minix/config.h... no
    checking whether it is safe to define __EXTENSIONS__... yes
    checking build system type... i686-pc-linux-gnu
    checking host system type... i686-pc-linux-gnu
    checking for a sed that does not truncate output... /bin/sed
    checking for fgrep... /bin/grep -F
    checking for ld used by gcc... /usr/bin/ld
    checking if the linker (/usr/bin/ld) is GNU ld... yes
    checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
    checking the name lister (/usr/bin/nm -B) interface... BSD nm
    checking whether ln -s works... yes
    checking the maximum length of command line arguments... 1572864
    checking whether the shell understands some XSI constructs... yes
    checking whether the shell understands "+="... yes
    checking for /usr/bin/ld option to reload object files... -r
    checking for objdump... objdump
    checking how to recognize dependent libraries... pass_all
    checking for ar... ar
    checking for strip... strip
    checking for ranlib... ranlib
    checking command to parse /usr/bin/nm -B output from gcc object... ok
    checking for dlfcn.h... yes
    checking for objdir... .libs
    checking if gcc supports -fno-rtti -fno-exceptions... no
    checking for gcc option to produce PIC... -fPIC -DPIC
    checking if gcc PIC flag -fPIC -DPIC 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.o... (cached) yes
    checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes
    checking whether -lc should be explicitly linked in... no
    checking dynamic linker characteristics... GNU/Linux ld.so
    checking how to hardcode library paths into programs... immediate
    checking whether stripping libraries is possible... yes
    checking if libtool supports shared libraries... yes
    checking whether to build shared libraries... yes
    checking whether to build static libraries... yes
    checking for gcc option to accept ISO C99... -std=gnu99
    checking for pkg-config... /usr/bin/pkg-config
    checking pkg-config is at least version 0.9.0... yes
    /mnt/mesa/src/BRK/xkbcommon-0.2.0/configure: line 11156: XORG_MEMORY_CHECK_FLAGS: command not found
    checking whether to build documentation... yes
    checking for doxygen... /usr/bin/doxygen
    checking for inline... inline
    checking for typeof syntax and keyword spelling... typeof
    checking for flex... flex
    checking lex output file root... lex.yy
    checking lex library... -lfl
    checking whether yytext is a pointer... yes
    checking for bison... bison -y
    checking for bison... /usr/bin/bison
    checking for strcasecmp... yes
    checking for strncasecmp... yes
    checking for eaccess... yes
    checking for euidaccess... yes
    /mnt/mesa/src/BRK/xkbcommon-0.2.0/configure: line 11683: syntax error near unexpected token `CFLAGS,'
    /mnt/mesa/src/BRK/xkbcommon-0.2.0/configure: line 11683: `XORG_TESTSET_CFLAG(CFLAGS, -fvisibility=hidden)'
    Debian squeeze doesn't have libxkbcommon, so I can't just apt-get it.

    Edit: Nor does wheezy, just experimental--and libxkbcommon is tagged rc-buggy.
    Somehow this doesn't look promising.
    Last edited by Ibidem; 02-08-2013 at 09:37 PM.

  2. #32
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,861

    Default

    Quote Originally Posted by Ibidem View Post
    Well, it looks like they intend to make libudev optional, it just hasn't been done yet.
    I can't get any numbers on size of a static binary though:
    Code:
    $ ./autogen.sh 
    autoreconf2.50: Entering directory `.'
    autoreconf2.50: configure.ac: not using Gettext
    autoreconf2.50: running: aclocal --force --warnings=all -I m4
    configure.ac:25: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=libxkbcommon
    autoreconf2.50: configure.ac: tracing
    configure.ac:25: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=libxkbcommon
    autoreconf2.50: running: libtoolize --copy --force
    libtoolize: putting auxiliary files in `.'.
    libtoolize: copying file `./ltmain.sh'
    libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
    libtoolize: copying file `m4/libtool.m4'
    libtoolize: copying file `m4/ltoptions.m4'
    libtoolize: copying file `m4/ltsugar.m4'
    libtoolize: copying file `m4/ltversion.m4'
    libtoolize: copying file `m4/lt~obsolete.m4'
    configure.ac:25: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=libxkbcommon
    autoreconf2.50: running: /usr/bin/autoconf --force --warnings=all
    configure.ac:25: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=libxkbcommon
    autoreconf2.50: running: /usr/bin/autoheader --force --warnings=all
    configure.ac:25: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=libxkbcommon
    autoreconf2.50: running: automake --add-missing --copy --force-missing --warnings=all
    configure.ac:25: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=libxkbcommon
    Makefile.am:90: user target `src/xkbcomp/parser.h' defined here...
    automake: ... overrides Automake target `src/xkbcomp/parser.h' defined here
    autoreconf2.50: Leaving directory `.'
    checking for a BSD-compatible install... /usr/bin/install -c
    checking whether build environment is sane... yes
    checking for a thread-safe mkdir -p... /bin/mkdir -p
    checking for gawk... gawk
    checking whether make sets $(MAKE)... yes
    checking whether to disable maintainer-specific portions of Makefiles... yes
    checking for style of include used by make... GNU
    checking for gcc... gcc
    checking whether the C compiler works... yes
    checking for C compiler default output file name... a.out
    checking for suffix of executables... 
    checking whether we are cross compiling... no
    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 ISO C89... none needed
    checking dependency style of gcc... gcc3
    checking how to run the C preprocessor... gcc -E
    checking for grep that handles long lines and -e... /bin/grep
    checking for egrep... /bin/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 minix/config.h usability... no
    checking minix/config.h presence... no
    checking for minix/config.h... no
    checking whether it is safe to define __EXTENSIONS__... yes
    checking build system type... i686-pc-linux-gnu
    checking host system type... i686-pc-linux-gnu
    checking for a sed that does not truncate output... /bin/sed
    checking for fgrep... /bin/grep -F
    checking for ld used by gcc... /usr/bin/ld
    checking if the linker (/usr/bin/ld) is GNU ld... yes
    checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
    checking the name lister (/usr/bin/nm -B) interface... BSD nm
    checking whether ln -s works... yes
    checking the maximum length of command line arguments... 1572864
    checking whether the shell understands some XSI constructs... yes
    checking whether the shell understands "+="... yes
    checking for /usr/bin/ld option to reload object files... -r
    checking for objdump... objdump
    checking how to recognize dependent libraries... pass_all
    checking for ar... ar
    checking for strip... strip
    checking for ranlib... ranlib
    checking command to parse /usr/bin/nm -B output from gcc object... ok
    checking for dlfcn.h... yes
    checking for objdir... .libs
    checking if gcc supports -fno-rtti -fno-exceptions... no
    checking for gcc option to produce PIC... -fPIC -DPIC
    checking if gcc PIC flag -fPIC -DPIC 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.o... (cached) yes
    checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes
    checking whether -lc should be explicitly linked in... no
    checking dynamic linker characteristics... GNU/Linux ld.so
    checking how to hardcode library paths into programs... immediate
    checking whether stripping libraries is possible... yes
    checking if libtool supports shared libraries... yes
    checking whether to build shared libraries... yes
    checking whether to build static libraries... yes
    checking for gcc option to accept ISO C99... -std=gnu99
    checking for pkg-config... /usr/bin/pkg-config
    checking pkg-config is at least version 0.9.0... yes
    /mnt/mesa/src/BRK/xkbcommon-0.2.0/configure: line 11156: XORG_MEMORY_CHECK_FLAGS: command not found
    checking whether to build documentation... yes
    checking for doxygen... /usr/bin/doxygen
    checking for inline... inline
    checking for typeof syntax and keyword spelling... typeof
    checking for flex... flex
    checking lex output file root... lex.yy
    checking lex library... -lfl
    checking whether yytext is a pointer... yes
    checking for bison... bison -y
    checking for bison... /usr/bin/bison
    checking for strcasecmp... yes
    checking for strncasecmp... yes
    checking for eaccess... yes
    checking for euidaccess... yes
    /mnt/mesa/src/BRK/xkbcommon-0.2.0/configure: line 11683: syntax error near unexpected token `CFLAGS,'
    /mnt/mesa/src/BRK/xkbcommon-0.2.0/configure: line 11683: `XORG_TESTSET_CFLAG(CFLAGS, -fvisibility=hidden)'
    Debian squeeze doesn't have libxkbcommon, so I can't just apt-get it.

    Edit: Nor does wheezy, just experimental--and libxkbcommon is tagged rc-buggy.
    Somehow this doesn't look promising.
    You're running your impression off of software that you're pulling in across multiple releases...from Debian? Try running Arch and see how "stable" or "Buggy" it is, then get back to me. Or Gentoo. Or Ubuntu with up-to-date-PPA's. Arch even has it packaged in Community or Extra, tried running it today on my new laptop. Works great. The only issue I had was when I did Linux-VT -> Kmscon -> plymouthd && plymouth --show-splash I got a soft-lockup. (Keyboard wouldnt respond but one press of the power button had systemd doing a clean shutdown) Which I'm thinking was caused by KMSCON and Plymouth both fighting over the DRM simultaneously. (Dvdhrm, if youre reading this. This was a fully updated Arch system, so latest versions across the board, KMSCON stable, not from git. Plymouth from stable, not git.)

  3. #33
    Join Date
    Jul 2011
    Posts
    348

    Default

    huu, it was extremely fast and smooth output relative the old console. Nice looking printing is good

  4. #34
    Join Date
    Nov 2011
    Posts
    267

    Default

    Quote Originally Posted by Ericg View Post
    You're running your impression off of software that you're pulling in across multiple releases...from Debian? Try running Arch and see how "stable" or "Buggy" it is, then get back to me. Or Gentoo. Or Ubuntu with up-to-date-PPA's. Arch even has it packaged in Community or Extra, tried running it today on my new laptop. Works great. The only issue I had was when I did Linux-VT -> Kmscon -> plymouthd && plymouth --show-splash I got a soft-lockup. (Keyboard wouldnt respond but one press of the power button had systemd doing a clean shutdown) Which I'm thinking was caused by KMSCON and Plymouth both fighting over the DRM simultaneously. (Dvdhrm, if youre reading this. This was a fully updated Arch system, so latest versions across the board, KMSCON stable, not from git. Plymouth from stable, not git.)
    Anytime I need something newer in Debian, I get a backport or make my own. I don't pull stuff from multiple releases.

    I'm currently running a patched mesa ~8.0, with libdrm 2.4.39 backported from git, and kernel 3.4.24.
    I don't want to move to a current distro, since I have a Radeon HD3200M. Newer Mesa doesn't currently work here, and I keep seeing the claim that Radeon is broken for the HD3xxx series (I could try debugging, but after I bisected they moved the problem code for me from Mesa to libdrm without fixing anything, and I really prefer a system that is functional), while you probably have read about the state of the proprietary drivers...

    That post was because xkbcommon (the tarball autocreated by cgit for the 0.2.0 tag) didn't build.
    Fetching a proper tarball worked, but there's more issues:
    KMSCON wants autoconf 2.68 (2.67 what's in Squeeze), which is easily fixed because it's someone who just decided to require what they had rather than what they needed.
    Patch that, and try...oops, --with-fonts=8x16 isn't supported.
    Read configure, OK, it seems it changed names to unifont. That's not documented, of course. Fair enough, since I'm building from git.
    And it thinks I don't have libudev...because it expects 172 or higher. I have 168. I missed that in the README, since they put it so concisely.
    OK, that was added 1 day after kmscon-6 was released, but it seems to be a fix rather than a new dependency.

    All right, I don't care enough about getting the size of a static binary enough to bother with this. I would be surprised if it's under 1.5MB linked to glibc.
    If one of you wants to get that information yourself, it would be informative. But to me, this post by Luc Verhaegen seems to be somewhat relevant: The linux desktop is dead!

  5. #35
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,861

    Default

    Quote Originally Posted by Ibidem View Post
    Anytime I need something newer in Debian, I get a backport or make my own. I don't pull stuff from multiple releases.

    I'm currently running a patched mesa ~8.0, with libdrm 2.4.39 backported from git, and kernel 3.4.24.
    I don't want to move to a current distro, since I have a Radeon HD3200M. Newer Mesa doesn't currently work here, and I keep seeing the claim that Radeon is broken for the HD3xxx series (I could try debugging, but after I bisected they moved the problem code for me from Mesa to libdrm without fixing anything, and I really prefer a system that is functional), while you probably have read about the state of the proprietary drivers...

    That post was because xkbcommon (the tarball autocreated by cgit for the 0.2.0 tag) didn't build.
    Fetching a proper tarball worked, but there's more issues:
    KMSCON wants autoconf 2.68 (2.67 what's in Squeeze), which is easily fixed because it's someone who just decided to require what they had rather than what they needed.
    Patch that, and try...oops, --with-fonts=8x16 isn't supported.
    Read configure, OK, it seems it changed names to unifont. That's not documented, of course. Fair enough, since I'm building from git.
    And it thinks I don't have libudev...because it expects 172 or higher. I have 168. I missed that in the README, since they put it so concisely.
    OK, that was added 1 day after kmscon-6 was released, but it seems to be a fix rather than a new dependency.

    All right, I don't care enough about getting the size of a static binary enough to bother with this. I would be surprised if it's under 1.5MB linked to glibc.
    If one of you wants to get that information yourself, it would be informative. But to me, this post by Luc Verhaegen seems to be somewhat relevant: The linux desktop is dead!
    I do have a response but since we have the developer here in the forums I won't derail things and just let him respond since its a choice of dependency issue. Dvdhrm, response?

  6. #36
    Join Date
    Feb 2013
    Posts
    9

    Default A huge bless to the CJK community

    Quote Originally Posted by asdx View Post
    I hope this project takes off. Please ignore all the dirty neckbeards crying over this project.

    When can we start using this project? Or when it will be implemented in distros like archlinux, etc?
    Now. Archlinux already packages it. Link: https://www.archlinux.org/packages/c...x86_64/kmscon/

    I have been using KMSCON as my main console since last December. The experience has been very smooth.

    People in the west might not realize this, but this project is a huge blessing to the entire CJK community.
    The good old linux-console is practically useless to us except as the emergency console, 'cause it has no
    capability of displaying CJK characters. There's been various efforts within the CJK community, but none has
    worked out well. KMSCON is the first proper solution to this problem.

  7. #37
    Join Date
    Mar 2012
    Posts
    13

    Default

    Quote Originally Posted by Ibidem View Post
    Anytime I need something newer in Debian, I get a backport or make my own. I don't pull stuff from multiple releases.

    I'm currently running a patched mesa ~8.0, with libdrm 2.4.39 backported from git, and kernel 3.4.24.
    I don't want to move to a current distro, since I have a Radeon HD3200M. Newer Mesa doesn't currently work here, and I keep seeing the claim that Radeon is broken for the HD3xxx series (I could try debugging, but after I bisected they moved the problem code for me from Mesa to libdrm without fixing anything, and I really prefer a system that is functional), while you probably have read about the state of the proprietary drivers...

    That post was because xkbcommon (the tarball autocreated by cgit for the 0.2.0 tag) didn't build.
    Fetching a proper tarball worked, but there's more issues:
    KMSCON wants autoconf 2.68 (2.67 what's in Squeeze), which is easily fixed because it's someone who just decided to require what they had rather than what they needed.
    Patch that, and try...oops, --with-fonts=8x16 isn't supported.
    Read configure, OK, it seems it changed names to unifont. That's not documented, of course. Fair enough, since I'm building from git.
    And it thinks I don't have libudev...because it expects 172 or higher. I have 168. I missed that in the README, since they put it so concisely.
    OK, that was added 1 day after kmscon-6 was released, but it seems to be a fix rather than a new dependency.

    All right, I don't care enough about getting the size of a static binary enough to bother with this. I would be surprised if it's under 1.5MB linked to glibc.
    If one of you wants to get that information yourself, it would be informative. But to me, this post by Luc Verhaegen seems to be somewhat relevant: The linux desktop is dead!
    Why didn't you try out kmscon-6? If you use git-builds, please don't complain if the documentation isn't up to date. I usually update documentation before doing a release. 8x16 font is now built-in so you no longer need to pass it to --with-fonts. libudev-172 is required (as mentioned in the README) because it introduced udev_device_has_tag().

    udev is currently used in one single file (uterm_monitor.c). The TODO list includes an item "make udev optional". I haven't done this yet, because no-one showed me good reasons to do so and I am still working on more important stuff. Please note, kmscon is still experimental. I haven't advertised it anywhere, so please consider it experimental.

    And please, if you have issues with it, open a bug-report, write an email or contact me via any other medium. But don't complain in public forums and expect the developers to find this and fix stuff.
    For instance, why didn't you open a bug-report that autoconf 2.67 is enough?


    Regarding the problem with plymouth:
    You cannot use plymouth together with any other application that uses graphics devices. Why do you want to use plymouth --show-splash from the console? It simply acquires all input/video devices and shows the splash screen. This doesn't work if another application (like xserver or kmscon) currently uses the devices.
    I don't understand why anyone would want that? Could you elaborate a bit more?

    Regards
    David

  8. #38

    Lightbulb

    Quote Originally Posted by dvdhrm View Post
    The TODO list includes an item "make udev optional". I haven't done this yet, because no-one showed me good reasons to do so and I am still working on more important stuff.
    good reason for making udev optional:
    udev is not a core component required to run a linux system. but the linux console is.
    and udev is not a de-facto standard either, because even for systems that require hot plug functionality, there exist alternatives, namely mdev, as i mentioned on page 3 of this thread.

    distro builders like me that build lightweight distros will be pissed if they need to install libudev even if they dont need hot plug functionality or use busybox' mdev instead, forcing them to waste precious memory resources (my distro runs even on devices with only 2MB ram), storage resources and build time etc for this entirely unneeded stuff.

    keep in mind that linux has much more use cases than just the typical ubuntu desktop system.

    Quote Originally Posted by dvdhrm View Post
    Please note, kmscon is still experimental. I haven't advertised it anywhere, so please consider it experimental.
    as long as it is only experimental, removing the good old linux console in favor of it is just ... insane.

  9. #39
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,861

    Default

    Quote Originally Posted by dvdhrm View Post
    Regarding the problem with plymouth:
    You cannot use plymouth together with any other application that uses graphics devices. Why do you want to use plymouth --show-splash from the console? It simply acquires all input/video devices and shows the splash screen. This doesn't work if another application (like xserver or kmscon) currently uses the devices.
    I don't understand why anyone would want that? Could you elaborate a bit more?

    Regards
    David
    It was for TESTING plymouth, I had just installed plymouth on my Arch box and was testing different splash screens. I just happened to run
    Code:
    plymouthd && plymouth --show-splash
    from a KMSCON console. While I agree that you don't want to manually run plymouth and that no one would do that normally, I do feel like it is a bug that kmscon and plymouth --show-splash clash if you do want to one day have KMSCON being the full-blown replacement for the kernel VT's since you do sometimes want to test plymouth and it works just fine under the normal VT's.

  10. #40
    Join Date
    Jul 2011
    Posts
    348

    Default

    Quote Originally Posted by asdx View Post
    I hope this project takes off. Please ignore all the dirty neckbeards crying over this project.

    When can we start using this project? Or when it will be implemented in distros like archlinux, etc?
    Arch has in their repositories. What I can see it work today, at lest in the limited use I tried it in.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •