Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - superwow

#61
Awesome! Thanks for the advice! Now I know how to get to the terminal sans x.

But when I run startx at CLI (ie - typing that command, 'startx', on terminal), no joy. "startx: command not found"

Aside from that, a handy cat of /etc/lightdm/lightdm.conf shows that nearly the entire file is commented out, and there is no startup or display setup script associated with those lines you mentioned, which are also commented out.

Guess I have to deal with startx first though. Or do you mean xinit?
#62
First off, VSIDIANS, sorry to post here after such a long period of silence, and then pop in as a lurker with a problem.

Initially I installed VSIDO on an internal flash volume partitioned to 8 gb (and several other partitions for various stuffs). I tend to run a fairly minimal system and have not installed too much, just scientific & data analytics software, and a slew of NCURSES lovelies, and have had flawless operations since my last post several months ago. Honestly, so few pains I have begun to get lazy! So, kudos VO, mainly a painfree (and junkfree) system.

But last weekend I installed a handfull of strategies games like chess, go, mahjong, etc. I reckon they were sizeable because a day or so later, I updated with 'up', worked a bit, shutdown, and rebooted later. On boot, I get to the screen which asks for my username and pw, enter it, and then get to an error message, approximately: 'xsession: cannot write to /tmp; xsession will not start' or somesuch. This means I cannot actually log in and am stuck on the login screen. Attempts to re-login always take me to the xsession cannot write message then back to the login screen. When I live boot from my VSIDO usbdrive, the install partition is nearly full. I am not sure if the culprits are the games, or the millions of updates I have had recently, or just my not frequently running 'apt-get clean,' or a cosmic thread or something.

I want to just log into the console/terminal, without the xsession or any graphical interface & clean house; but when I select 'e' or 'tab' from the x option in the lxde log in screen, the console options do not have apt, rm, or other bash shop cleaning utilities as far as I can tell. So, how can I log into a full console, but no xsession? I am sure there is a way to do this, but I just don't know how. Any pointers?
#63
Much obliged mighty v-ger! Working now!!  8)
#64
VastOne, thanks for the help. I do not remember removing it other than auto-remove at apt-get's prompting. But the advice seemed to do the trick. Several updates run, but no pesky messages. I will go back to pestering my coworkers now :)
#65
V-ger you are superfast! I didn't know about that command, but thanks.

Are these the droids you are looking for?


superwow@rlyeh:~$ se systemd
systemd:
  Installed: (none)
  Candidate: 204-10
  Version table:
     208-1 0
          1 http://ftp.us.debian.org/debian/ experimental/main amd64 Packages
     204-10 0
        500 http://ftp.us.debian.org/debian/ sid/main amd64 Packages
        100 /var/lib/dpkg/status

#66
Howdy all. I thought I would throw this out there in case others are having similar issues.

I updated my VSIDO system several days ago (as I do everyday when I log in) using 'up' (for those who aren't aware this is 'sudo apt-get update && sudo apt-get dist-upgrade') and have noticed 2 strange behaviors in my system. I do not know if they are related, but they started happening at the same time.

1. every time I 'up' (as above) I get a message that 'systemd' has been replaced, has been updated, and that I should run 'apt-get autoremove' to clean it. I always do. After which it always removes. Yet it always updates and says it has been replaced. Never ending cycle.

2. control+x takes me to the log out screen, but 'alt-p' for 'power off' greys the log out screen, but never shuts down my machine. Which I easily remedy with 'sudo shutdown -h now'.

I know VSIDO is now on systemd, but also know that I am OCD about system updates, so maybe things are lagging in the Debian world (100% likely). Or maybe I have thrown a wrench in my system (200% likely). Are the two issues related? Is anyone else having a similar experience?

Say the word and I will share your choice of system specs.

#67
VSIDO Discussions / Re: Chromium or Iceweasel
April 01, 2014, 04:47:52 AM
@hakerdefo, thanks for your solution. I like this solution too (in addition / substitution to Hostblock). I'll have to try it out.
#68
VSIDO Discussions / Re: Chromium or Iceweasel
March 25, 2014, 06:37:26 AM
VastOne you might try changing to AdBlock Edge. It apparently is the cutting edge blocker which hasn't sold out. Adblock has entered corporate agreements to allow ads from some retailers (for a fee).

Or you might consider blocking ads at the machine level with HostBlock. It definitely works but I am not using it at the moment (have never used it on VSIDO) since I just don't have enough time to configure at the moment. Arch friends keep an active thread, a delish read if you are like minded.

As to the browser topic, for years I was a total Firefox whore. If simply for Vertical Toolbar. I still love it, but, I have to admit, the integration of Chrome with Google services is fantastic, despite the ads. Especially if you have an Android phone or tablet. A substantial reason MS is losing marketshare to the painfree ChromeOS imho. I have a hard time sticking to Firefox/Iceweasel but I still love it. For me, it also renders webpages better in VSIDO than Iceweasel, and it's decorations are more consistent than Iceweasel. Not sure why. Plus Chrome generally outlasts the other browsers in security challenges which is a substantial concern of mine.

I agree with others on Opera too; they are innovators the others copy, even if they aren't FOSS. But for FOSS options, Midori and SeaMonkey are pretty dern good last time I used them.
#69
How To's / Zathura pdf viewer config file ... zathurarc
February 24, 2014, 02:27:49 AM
I started a thread comparing lightweight pdf viewers. Zathura i one of them and has a fairly decent following in various other distros, in part, because of its active development, the sociability of the developers themselves, and ease in cofigurability by users.

I know I have posted several times recently. This is my penance for being a help vampire in the past. Also, might as well share the fruits of my labors for comments and snarkery.

Install by


apt-get install zathura
medit ~/.configs/zathura/zathurarc


And paste your user defined configs in the newly created & opened file!

To get started, here are a few color schemes, some commented out, which provide easy viewing, soft dark colors, for those who read tons of pdfs like I do. I have not come up with any of these, but rather swiped generously from the excellent Arch forums. I am not really sure how to credit them other than links to their site. Maybe I'll create an Arch profile to thank them directly though.


#set recolor-darkcolor "#93A1A1"
#set recolor-lightcolor "#002B36"
#set recolor true

# colors
#set statusbar-bg "#000000"
#set statusbar-fg "#CC0000"
#set default-fg "#FFFFFF"
#set default-bg "#000000"

# keybindings
map [fullscreen] a adjust_window best-fit
map [fullscreen] s adjust_window width
map [fullscreen] f follow
map [fullscreen] <Tab> toggle_index
map [fullscreen] j scroll down
map [fullscreen] k scroll up


I haven't really been able to do what I want with it yet, which is to have several color schemes. Ideally, I want pdfs to open in their native colors and toggle several different predefined color schemes for different lighting conditions or for different levels of eye fatigue, etc.
A keybinding "control+I" to toggle invert colors.
A keybinding "control+s" to toggle sepia/parchment type coloration (like a kindle)
A keybinding "control+a" (or some other key) to toggle the aqua/blue color scheme above

Here's my contribution for the time being. If you come up with a different config, either keybindings or color palattes, please share!
#70
How To's / Re: Lightweight pdf viewers
February 24, 2014, 01:45:45 AM
Ok so I am back with a little more info, having taken up hakerdofo's challenge.

***   Qpdfview
Size archive: 1,025 kB
Size install: 4,048 kB
Dependencies: libc6, libcomerr2, libcups2, libgcc1, libgcrypt11, libgnutls26, libgssapi-krb5-2, libk5crypto3, libkrb5-3, libmagic1, libpoppler-qt4-4, libqt4-dbus, libqt4-sql, libqt4-svg, libqt4-xml, libqtcore4, libqtgui4, libstdc++6, zlib1g, libqt4-sql-sqlite
Gui control: yes, visible menu, visible gui control buttons
Right click: yes
Keybindings:
Control+I   invert colors
F11      full screen
Control+6   show two pages up (like an open book)
Control+Up/Down   zoom in/out (nonstandard implementation of zoom)
Strangely no keybinding for exit. Exit is accessible from Alt+f (File menu) > X.

Though I did not do this, apparently it is configurable via a configuration file.

This app is more what one automatically expects, graphically, from a run of the mill pdf viewer giving the user both a visible menu structure, a right click menu, and GUI controls at the top of the file. Gui elements are rendered by the Qt library. Qt is a crossplatform application development environment used for a while by Nokia for its former linux mobile phone platforms, Maemo/Meego (so sad to see it go). Since it has been open sourced, it has been picked up by many developers. It has come under recent some criticism by being very Google controlled though. You can search the webs for articles about this. Personally I do not think this is a bad thing at all as it allows for a common framework that developers can easily develop one app for Android, Linux, MSW, Mac (if the user installs the Qt framework), and potentially other platforms. I instaled Chrome yesterday, which I think uses Qt as well. But I know some people are big Google haters so, there, again, fwiw.

Also, unlike the other pdf viewers, qpdfview lets you select, highlight, and copy text to clipboard, according to various sites and as implied by the menu. I could not get this to work on my system. If anyone has recommendations about how to do this please let me know. In my opinion this is a defining feature, IF it works.

Another nice feature the others do not have is tabbed viewing. Zathura is supposed to have this feature (requiring some fiddling around with config file), though I have not tried it (or figured it out yet).

***   Apviv
I could not get apviv to install from Debian/Sid sources:

superwow@rlyeh:~$ sudo apt-get install apviv
[sudo] password for superwow:
Reading package lists... Done
Building dependency tree       
Reading state information... Done
E: Unable to locate package apviv

Since it isn't there, I won't consider it for my own home/work usage due to IT restrictions at work. When it installs via apt-get from regular repositories, I can take a look.

Speaking of additional pdf viewers, there are apparently command line options for viewing pdfs. I do love me some CLI :D but sadly never got them to display pdfs correctly on CLI, just jibberish. But others apparently can get it to work. Three methods...


less path/to/some.pdf


or


lesspipe path/to/some.pdf


or


lesspipe path/to/some.pdf | less


Like I said, I never got them to work.
#71
Thanks for the feedback on pdf apps. I don't want to hijack this thread and turn it into a pdf viewer thread, so I created another thread for comparing pdf viewers in light of their built in functions, dependencies, and configurability. If it is of interest to you, go check it out.

As for Roxterm, I have done a little reading and it seems pretty capable. I'm still not sure why it seems to be so popular here and elsewhere, other than configurable keybindings maybe. That in itself is pretty cool, especially since the keybindings don't have to have vim-like/tmux-like keybindings (that activation key business is kinda tedious imo). I'll play around with Rox...
#72
How To's / Lightweight pdf viewers
February 23, 2014, 08:20:05 AM
Lightweight pdf viewer comparison

Having used Apple's Preview for years, I will say that it is one of the best reasons to stay with an Apple. I left Apple for other reasons, and now I am on a distro that doesn't ship with a pdf viewer. VSIDO is different than Apple of course, going for both more up to date software (comparison of installed bash on Mac and VSIDO is a good example here), and a more parsimonious, smaller base install. Even with the trimmed size, VSIDO seems to be rolling gangbusters here. Fast install, low low CPU usage. So, in terms of fleshing out my system, I too want to keep out the cruft and stick to a leaner install.

In another thread I made the comment I would like a pdf viewer installed by default since, as a scientist, I am continuously viewing pdfs. They are the medium of transport for scientific journals, regulatory communications, white papers, etc. Most distros I have tried already ship with a pdf viewer, and mostly the viewer does the job. I have never really had to compare them. So, as a first time comparison for me, I thought I would share and save anyone the time it took me. Here's what I found.

The recommended pdf viewers, all lightweight, were mupdf, epdfviewer, xpdf, zathura. Here's what I found.

***   Mupdf   ***
Archive Size: 2,985 kB
Install size: 8,158 kB
Dependencies: libc6, libfreetype6, libjbig2dec0, libjpeg8, libssl1.0.0, libx11-6, libxext6, zlib1g
GUI controls: no
right click: no
Keyboard shortcuts:
q      quit
<shift+r>   rotate clockwise
<shift+h>   fit to height
<shift+w>   fit to width
<shift+g>   go to end
<shift+l>   rotate widdershins/counterclockwise
<alt+b>      go to beginning
<alt+f>      full screen
<alt+j>      go down
<alt+k>      go up
<alt+q>      quit
<alt+i>      inverse colors (good feature!)

"man mupdf" will show all the keybindings.

I like the built in function to invert colors, however, I do not think it can be modified via configuration file. The other two pdf viewers mentioned here are configurable.

Also worth mentioning is the mupdf-tools package, installed separately. Adds security features etc.
Size: 3,060 kB

***   Xpdf
Archive size: 1,427 kB
Install size: 4,584 kB
Dependencies: libc6, libgcc1, libpoppler37, libstdc++6, libx11-6, libxm4, libxt6
GUI controls: yes, a little (they don't suit my taste, but also, I don't like a lot of GUI)
right click: yes
Keyboard shortcuts:
q      quit
"man xpdf" will give you al the keybindings
Compared to the other two pdf viewers, xpdf has the most preconfigured keyboard shortcuts - a LOT. Is very fast despite the early 90's looking gui elements.


***   Zathura
Archive size: 171 kB
Install size: 571 kB
Dependencies: libc6, libcairo2, libgirara-gtk3-1, libglib2.0-0, libgtk-3-0, libmagic1, libpoppler-glib8, libsqlite3-0
right click: no
Keyboard shortcuts:
alt+q      quit
d      split screen
h,l,j,k      scroll left, right, down, up
a      zoom to fit the page 
s      zoom to fit the width of the page 
F5      full screen mode 
"man xpdf" will give you all the keybindings
Compared to mupdf, Zathura has a lot of preconfigured keyboard shortcuts, but not as many as xpdf. On the other hand, there appear to be more options for configuration than the other two. Inverse colors or color replacements can be preconfigured in the config files and keybound. And dang if there are some excellent discussion threads about zathura modding.


***   epdfview
Sorry but I could not find this in the Debian repository.


superwow@rlyeh:~$ apt-cache search epdf
comparepdf - command line tool for comparing two PDF files


Since my whole idea in jumping from #! to VSIDO was because my IT dept at work said #! was not a permitted distro, and that distros can only pull from large vetted repositories (Debian, Suse, maaayybe Ubuntu) then I am not concerned with anything in git or some private repository.


Quick impressions:

Out of the box, I like Mupdf the most. It has no distracting, or ugly, GUI. It has a nice invert color function (which is almost a requirement for me since inverted colors are much less tiring to read). It is very fast.

However the other two are fast as well. Xpdf seems to be the fastest on my machines and with the files I tried. Also, I don't really like screen real estate wasted by gui elements, and when they are present, I want them to look and feel unobtrusive and a tad stylish, which is not the case for xpdf. It is quite fast though..

The install sizes are misleading I think. If you install any of these on your machine, your install size might be different because the dependencies apt-get pulls down may be slightly different for you, since, my installs of these pdf viewers was successive, meaning that each successive install had dependencies which were already installed on my machine. Judging by archive size though, Zathura wins the race by a longshot.

I will probably keep all three for the moment, but, with Zathura's extensive configurability (including multiple methods of inverting colors, substituting colors, and building in functions) I predict I will wind up with it, with a handful of inverted and muted color options. Seriously, you could add more text sizing and coloring options than my kindle has. All are good and quick though.
#73
I'm a new guy here but here's what I have installed:

ranger, dmenu, clamtk (good netizen that I am), wordgrinder, joe

I also added the Debian menu into my Fluxbox menu because sometimes i cannot remember what I installed.

I will probably install catfish and tie it into dmenu too.

I would like a good pdf viewer preinstalled. I think #! (where I just came from) had Evince, though could be mistaken. I thought it was pretty decent, but when I checked yesterday, I seem to recall it had hefty dependencies. So, whatever pdf viewer is economically feasible in your disk image. I have not yet researched this fully but ... I view a LOT of pdfs.

For streaming music, mpg123/321 is already there, cli-radio is just a wrapper for a bunch of bash aliases I think, so I just make my own bash aliases. But, also regarding music, I will prob install plait, plaiter, and/or https://github.com/np1/mps which I think is from mrneilypops. I spend all day in specialized terminals for scientific analysis and just want everything to get out of the way, so, I am always attracted to new terminal apps (which I can easily script or alias) for music.  ;D

As to a terminal menu, yep, the BBQ has lovely terminal menus in all their roasts. Actually, for some of the BBQ roasts, if it had not been for that menu, whoa! woulda been lost (moment of panic with Pidsley lol). I think I am gradually moving everything into the terminal.

Question: Everyone likes it, so, what's so good about Rox terminal?
#74
How To's / Brightness control keybindings
February 16, 2014, 01:16:28 AM
I found that my brightness control keys did not work after installing VSIDO. According to the googles & reddits, this is a fluxbox thing. Openbox will readily map your power related keys automatically in most situations. Flux does not do this for you.

To get your brighness control keys to work, you could use the already installed xrandr. Go ahead, "man xrandr" on terminal, scroll down, yep, there it is, "--brightness". Yes, you can query and change your screen brightness on terminal with xrandr. It accepts absolute brightness values.


xrandr --output  --brightness 0.6


should set your brightness to 60%. For me this did not work. I went back to the manpage.

Reading on a bit, there's a blurb about hardware control keys. The man page says you probably want xbacklight. Familiar little app, I have installed it before in other distros.

Install xbacklight, then go edit your keybinding file. If you used xev like I did, it will tell you the key number of the screen dim and brighter keys. For me using the number in the keybinding file did not work. Using its name though did.


sudo apt-get install xbacklight
cp /home/superwow/.fluxbox/keys /home/superwow/.fluxbox/keys_default
medit /home/superwow/.fluxbox/keys


Medit will open the keys file. Here, you can drop in the keybindings I use. Or permutate them and repost here. Also, if anyone uses xrandr itself to change brightness, tell me what I did wrong.


# screen brightness
# keys: dim 232, bright 233
XF86MonBrightnessDown : Exec xbacklight -dec 10
Mod1 XF86MonBrightnessDown : Exec xbacklight -dec 3
Mod4 XF86MonBrightnessDown : Exec xbacklight -set 15
XF86MonBrightnessUp : Exec xbacklight -inc 10
Mod1 XF86MonBrightnessUp : Exec xbacklight -inc 3
Mod4 XF86MonBrightnessUp : Exec xbacklight -set 100

#75
How To's / Volume control keybings
February 16, 2014, 01:15:33 AM
For the sake of anyone having trouble with audio keybindings, I thought I would post mine. For some reason the defaults did not work on my system.

The problem: you just installed VSIDO and you want to listen to music, and when you start playing something, you are blown across the room by the sonicblast. Fortunately you were not wearing headphones. If your relative has been labotomized by a headphone experience, I feel ya.

Start here: ~.fluxbox/keys

On my machine, it was in /home/superwow/.fluxbox

This is the fluxbox keybinding file. Keybindings make me happy in all situations, my coworkers have often been awed by my high functioning lack of mouse use, but on this machine, my trackpad is psychotic, so keybindings are even more betterer.

Before you do anything, like opening or editing the file, make a backup of the file. You can do this in spacefm. I did not, due to my trackpad's need for heavy sedation. I do this junk in the terminal. The first time I edit a config file I append _default to the default config file's name to let me know it is a special kind of backup.


cp /home/superwow/.fluxbox/keys /home/superwow/.fluxbox/keys_default
medit /home/superwow/.fluxbox/keys


Find the section for volume settings. For simplicity, I'll just drop the section here for your inspection.


# volume settings, using common keycodes
# if these don't work, use xev to find out your real keycodes
176 :Exec amixer sset Master,0 1+
174 :Exec amixer sset Master,0 1-
160 :Exec amixer sset Master,0 toggle


The number to the left of the colons is the key number, after the colon is "Exec" for execute, and following that is a terminal command to amixer. There are lots of different ways to program this baby, and I am just reusing settings from a previous distro I had installed. See there, that thing that says xev blah blah, nice little app. Ideally it should tell you what key you just pressed. On my computer, xev's output used with amixer did nothing as far as I could tell. (FYI, strangely xev outputs the values for the enter key, even though I did not press enter. If you happen to put that in the keybinding file, your system will seem like it is borked! Nothing will run correctly because the enter key has been remapped. No worries, just fix it back and all will be ok.)

Here's the text of my file, edited with a couple of usage options to control volume. Fit for immediate consumption or season to taste.


# volume settings, using common keycodes
# if these don't work, use xev to find out your real keycodes
#123 :Exec amixer sset Master,0 1+
#122 :Exec amixer sset Master,0 1-
#122 :Exec amixer set Master 5-
XF86AudioRaiseVolume :Exec amixer -q -D pulse sset Master 10%+ unmute
Mod1 XF86AudioRaiseVolume :Exec amixer -q -D pulse sset Master 3%+ unmute
Shift XF86AudioRaiseVolume :Exec amixer -q -D pulse sset Master 1%+ unmute
XF86AudioLowerVolume :Exec amixer -q -D pulse sset Master 10%- unmute
Mod1 XF86AudioLowerVolume :Exec amixer -q -D pulse sset Master 3%- unmute
Shift XF86AudioLowerVolume :Exec amixer -q -D pulse sset Master 1%- unmute
121 :Exec amixer sset Master,0 toggle


Also, if you have advice on other ways to do this, by all means, the more the merrier!