Jump to content
Read the Funtoo Newsletter: Summer 2023 ×

uudruid74

Members
  • Posts

    141
  • Joined

  • Last visited

  • Days Won

    9

Posts posted by uudruid74

  1. OK ... I'm pulling my hair out and I feel stupid ... especially since I'm all out of hair.  *doh!*

     

    less is not interpretting the files I give it. For example, if I give it an HTML, it just shows me the raw HTML than formatting it.   Its supposed to do this via the lesspipe program (installed) and the LESSOPEN environment variable, which is set and exported.  lesspipe isn't getting run.  Its in the PATH and I can run it manually.

     

    Anyone else seeing this?

     

  2. Someone has done it! Awesome. Wish it was the default rather than an odd on, like if you don't have the variable specified, emerge would just look at the flags and go, but... we don't always get what we want!

     

    Thanks for mentioning that package though. Trying it now

  3. And what I was confused about is WHY  I should have to make such a change.  This should be set up one way or the other, not have packages tell me to change my directory structure back and forth.   Its not making any sense.

  4. I have an SDK update manager on my desktop, but it mainly installs Java libs and its a GUI tool. I just want the cross compiler, not a dull Android ask, and must be able to install it from a shell. There is no GUI on the devel box. I'd prefer not to break the package manager, but if I have to I will.

     

    Do have a URL for the download? I was thinking of using a deb or rpm package and just manually installing it.

  5. There should be some option that peeks at /proc/cpuinfo for all the flags to see what your CPU supports and uses -march=native for the usual architecture build.   No good if building for another host, but most people are building on their own box.

  6. What's the status of crossdev?  I'm getting a message to convert /etc/portage/package.mask to a directory.   My magic wand is broken.  WTF am I supposed to do to the file?

     

    And IRC is saying crossdev is broken permanently.  I just want to cross-compile 1 stinking package (need not be an ebuild, I can build from source tarball) so I can stick it on my phone (its rooted).   Whats the fastest way to get a cross-compiler installed?   I can build it manually.  I did it about 15 years ago but I can't remember how the  F&^% I did it!

     

     

  7. Or -j1 to run 1 at a time, and if the BIOS lets you underclock, do it. Also try to set your CPU governor to something slow and boring like powersave. The slower it runs the cooler. If you don't have a tool to set the governor, and you have support for cpu frequency scaling in your kernel,let me know and I can paste you a small script to set it that doesn't need any special tools.

  8. All good advice, the only thing I would add is to limit how much you tackle at once.  Some of that perl stuff you could emerge separately so that you have a smaller chunk to deal with.  Also, I would tackle getting X and getting it working before you worry about nvidia-drivers.  I'm guessing thats the binary?   That will avoid a lot of hassles you could likely defer to later, such as having 32-bit compatible binaries.  I still don't understand why the game companies complain about Linux not being advanced enough for them, but all the games and drivers require 32 bit libraries.  Linux was the first system to go pure 64 bit, and I don't think many games will work at all on a system so old that it can't run 64 bit pointers.  Maybe I'm missing something?

     

    When you have problems, break the problem down into chunks that are easier to manage.  Reduce the number of variables in your equation.

  9. Here's another stupid admin trick ...

     

    How often do you have about a dozen shell windows open?   Let's add two capabilities to make that easier.  These are controlled with a line that looks like this in the script:

    export PROMPT_COMMAND="shareHistory; testWindow"
    

    You can simply remove the feature you don't want from your PROMPT_COMMAND, or change it on a window-by-window basis if you like.

    1. shareHistory - Consolidate the bash history so that it is available through any bash that your username controls.  The history will sync after every command.  The only drawback is that it's AFTER every command, so you might want to hit enter if you just switched windows to ensure that the commands you just used in the other window are available in this window.  Hit ENTER to sync up, then use up-arrow, history, or ! commands as if you never swiched windows.
    2. fixTitle - This one happens as part of the testWindow command below.  It updates the window title to the command you just ran so that you always know whats running in that window. 
    3. testWindow - You probably switched windows because you are waiting on something to finish, like an emerge.   Wouldn't it be nice to know when it's done?  This command will look and see if its currently on top and if not, it will issues a notification to your desktop to let you know the last command finished.  It even selects an appropriate icon.  Its silent as long as window is on top.  This is sort of a hack since bash doesn't know anything about your window stack.  Instead, a couple commands are aliased to look at the window that currently has focus (which should be itself since you are typing the command!) and records this.   You shouldn't use commands that record the window in a script.  You can also force it to remember the window with the new command n.

    Also, the testWindow functionality is set up to not try to remember the window when the script starts.  This is because your bash profile starts to run before the window is open and gets focus creating a race condition.  You have to specifically turn on the feature with 'n'.  I've also aliased 'ls' and 'emerge' to turn this on as well (and record the window via 'updateWindowId').   None of the fixTitle or textWindow features work until you use one of these commands.

     

    To use, save the following script as /usr/local/bin/windowtricks.bash

    #!/bin/bash
    #-
    #- This is to display notifications when you aren't watching the window
    #- and updates the window title with the currently running command.
    #- The command is reset when it finishes, unless the window is on top.
    #- In this case, the window title is kept so you can find it.  You
    #- may use the 'n' command to manually reset the window title.
    #-
    #- We should only update the WindowId when the window has focus!
    #- This means the first update can't be inside .bashrc
    #-
    #- The new 'n' command updates the 'notify' and resets title to $SHELL
    #-
    #- source this file from your .bashrc
    #-
    
    shopt -s histappend
    
    alias n='updateWindowId; fixTitle; initTrap'
    
    #- These commands will automatically call n to turn on the features
    alias ls='n; ls --color=tty'
    # alias cd='n; cd'
    alias emerge='n; emerge'
    
    #- keep this info
    resetTaskName() {
      LC_TASK=$(basename ${SHELL})
    }
    
    #- need to remember this
    updateWindowId() {
        LC_XWINDOWID=$(xdotool getactivewindow)
        #resetTaskName
    	if [ -z "$LC_NAME" ]; then
    	  LC_NAME=$(xdotool getwindowname $LC_XWINDOWID)
    	fi
    }
    
    #- actually set the window title
    fixTitle() {
    	#- If we have a 'screen' type terminal, name the screen, not the window
        case $TERM in
            screen)
                echo -ne "\033k${LC_TASK}\033\\"
                ;;
            xterm|xterm-256color|xterm-color|Eterm|aterm|rxvt|kterm|rxvt-unicode|gnome|interix)
                echo -ne "\x1b]0;${LC_NAME}: ${LC_TASK}\x07"
                ;;
        esac
    }
    
    #- get command for title
    autoTitle() {
      case $BASH_COMMAND in
        fixTitle) ;;
        testWindow) ;;
        updateWindowId) ;;
        getLastCommand) ;;
        sendNotify) ;;
        *)
            LC_TASK=$BASH_COMMAND
            fixTitle
            ;;
      esac
    }
    
    #- grab from history
    getLastCommand() {
      LC_TASK=$(history 1 | cut -c 8-)
      LC_ICON=$(basename $LC_TASK 2>/dev/null)
      if [ -z "$LC_ICON" ]; then
        LC_ICON="utilities-terminal"
      else
      	#- FIXME: This is a bad/slow hack.
        eval $(locate $LC_ICON.desktop | xargs cat | grep Icon | head -1 | sed 's/Icon/LC_ICON/') 2>/dev/null
      fi
    }
    
    #- notification of task completion
    sendNotify() {
      getLastCommand
      notify-send -t 10000 -i "$LC_ICON" "Task Complete in $LC_NAME" "$LC_TASK"
    }
    
    #- test to see if window is on top
    testWindow() {
      LC_ACTIVE=$(xdotool getactivewindow 2>/dev/null)
      if [ -z "$LC_XWINDOWID" ]; then
         return 0;
      fi
      if [ "$LC_ACTIVE" != "$LC_XWINDOWID" ]; then
         #- This command is forked because it takes too long
         sendNotify & disown 2>/dev/null
      else                  		#- comment these 3 lines to keep last command in title
         resetTaskName      		#- above and this one
         fixTitle           		#- and this one
      fi
    }
    
    #- This trick shares history in all open bash windows
    shareHistory() {
      history -a
      history -c
      history -r
    }
    
    #- the magic!  Executed when prompt is displayed
    export PROMPT_COMMAND="shareHistory; testWindow"
    
    #- some magic for updating window title
    initTrap () {
        if [ -z "$LC_INIT" ]; then
        	#- These commands update the windowid in case
        	#- our shell moved from one window to another
    		alias ls='updateWindowId; ls --color=tty'
    		alias cd='updateWindowId; cd'
    		#- The rest we just unalias
    		unalias emerge
    
    		LC_INIT="DONE"
    		trap autoTitle DEBUG
        fi
    }
    

    Now change your .bashrc and add a line like this at the end.

    source /usr/local/bin/windowtricks.bash
    

    Enjoy!

  10. You had the boot order right the first time! Never doubt yourself.

     

    Bootloader loads kernel and initrd, a temporary root filesystem with more drivers/modules so that it can autodetect the root filesystem (which could means raid drivers filesystem drivers, nfs, etc)

     

    The kernel loads initd and initd runs OpenRc scripts and anything else needed to start up the system.

  11. I'm not someone who hasn't read the handbook. I also have several other books, that say "don't worry about installing every module now, just the essential...because they can be installed later". In fact I've installed a custom kernel, so i won't be reverting to anything simpler any time soon.

    What I'm asking for is a generic yet accurate explaination of what happens when a module (driver) is installed later on (Your musings, far less taxing than an overly technical hurdle).

    Is it "registered with the kernel" somehow? is the entire kernel recompiled each time? is there an intermediate program that handles new modules "mod[something something]" Is it a standard or non-standard way of dealing with modules?

    What are the essential (abstract?--though I doubt I'd ever consider accurate summation abstract... the crux of my burden in life) elements of the addition of a module to a system?

    In general, you wont be adding kernel level drivers. You can go into the kernel source and do a make menuconfig, select some additional modules and then do a make modules and make modules_install. This wont build modules that are already built or the kernel. However, most people just build all the modules they might need and don't mess with it anymore.

     

    When it comes to binary video drivers, they are built against the existing kernel sources so that they can build a module

    If you update your kernel, you will need to update those modules at the same time or you lose your GUI. I don't recommend using proprietary binary video drivers.

     

    Its actually possible to load modules built for one kernel version into a different one, but its so error prone and kinda pointless since the source for them all is right there. Much safer to rebuild the modules with the kernel.

     

    Technical (not totally accurate, but here's the simple version): the modules are placed in a /lib/modules/{kernel version}/ directory and then depmod is run which looks through the module headers to create a module database of supported device ids and what module is available for each device. The udev daemon listens to kernel gernerated insertion events and then loads the right module via modprobe based on the device ids from the kernel, the module database, and user preferences. It also generates the correct /dev entries for the new device.

  12. Time for another STUPID Admin Trick ... running a CGI on Nginx / Tengine !

     

    There are plenty of ways to do it, most involve installing a wrapper around the fastCGI interface.  However, I already have FPM installed, and figured that PHP could execute a program, so why not wrap a PHP wrapper?   I would NOT recommend this for production use as there is probably more than one security issue, compatibility issue, or whatever.  Then again, you aren't using CGI for production system's anyway, right?

     

    First a bit of magic in your server { } section of your web server config file :

    location ~ ^/cgi-bin(.*)$ {
                    gzip off;
                    include /etc/tengine/fastcgi.conf;
                    fastcgi_split_path_info ^/cgi-bin/(.*cgi)(.*)$;
                    fastcgi_param CGI_FILENAME $fastcgi_script_name;
                    fastcgi_param SCRIPT_FILENAME $document_root/cgi-bin.php;
                    fastcgi_param PATH_INFO $fastcgi_path_info;
                    fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock;
                }

    Now, you need a wrapper called cgi-bin.php (in server root):

    <?php
    
    $scriptname = "{$_SERVER['DOCUMENT_ROOT']}/cgi-bin/{$_SERVER['SCRIPT_NAME']}";
    
    if (array_key_exists('HTTP_REFERER',$_SERVER)) {
        putenv ("HTTP_REFERER={$_SERVER['HTTP_REFERER']}");
    }
    putenv("DOCUMENT_ROOT={$_SERVER['DOCUMENT_ROOT']}");
    putenv("QUERY_STRING={$_SERVER['QUERY_STRING']}");
    putenv("REMOTE_ADDR={$_SERVER['REMOTE_ADDR']}");
    putenv("REMOTE_PORT={$_SERVER['REMOTE_PORT']}");
    if (array_key_exists('REMOTE_USER',$_SERVER)) {
        putenv("REMOTE_USER={$_SERVER['REMOTE_USER']}");
    }
    putenv("REQUEST_METHOD={$_SERVER['REQUEST_METHOD']}");
    putenv("REQUEST_URI={$_SERVER['REQUEST_URI']}");
    putenv("SCRIPT_FILENAME=$scriptname");
    putenv("SCRIPT_NAME={$_SERVER['SCRIPT_NAME']}");
    if (array_key_exists('PATH_INFO',$_SERVER)) {
        putenv("PATH_INFO={$_SERVER['PATH_INFO']}");
    }
    
    $output = shell_exec ($scriptname);
    
    echo preg_replace('/^.+\n/', '', $output);
    
    ?>
    

    Now, assuming you have a /cgi-bin directory, you can run scripts like this  /cgi-bin/mycgi.cgi?h=45&y=6  or whatever.   The script must be executable and must end in cgi and must be in the /cgi-bin directory.

     

    I'm no PHP programmer, and new to Tengine/Nginx (using Apache too long), so if you are shaking your head at some of the above hackery, feel free to correct it!  I'm sure its pretty bad, but I couldn't find any examples online that did anything like it.

     

    Have fun.

  13. It works, but you are getting a 'B' rating on ssllabs.com.   Weak DH key exchange parameters and support of older RC4.   I recently set this up (tengine/nginx) so if you want a copy of the config file, lemme know  (I get an A+, and that's with the free certificate from startssl).  Took me awhile to find all the tweaks for tengine/nginx to lock everything down.   Time to update the HOWTOs.

     

    In fact, getting Joomla to work with Tengine requires some magic regex that was incredibly hard to find!  I added some extras to detect mobile browsers and redirect (to another domain or a directory via URL rewrite) which you can turn off via "Request Desktop Site", and this is ignored for the joomla URLs since it detects this stuff itself - it's just a regex.  And the virtual mail server how-to was pretty dated as well.

     

    Whats the procedure for updating these?  I might go ahead and take a stab at it.

  14. GLXVBlank probably should be on.  I think this tells the driver to wait for vblank to do updates, which will stop tearing.  Tearing is a result of changing the display while the hardware is reading it, so you get half of one frame and half of another.

     

    The ATI binary drivers have all sorts of anti-tearing settings in the control panel, but I have not been able to get them to work with Gnome.  Mutter uses some new Xrandr call that isn't supported by the ATI drivers.  I have a couple really STRANGE problems with the radeon drivers so I'm always tempted to try the binary ones, but as long as I can't get Gnome to work, its a dead issue.

     

    If anyone has fglrx and gnome 3.16 together, I want to hear from you!

×
×
  • Create New...