Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Show HN: Setup a fancy development environment ... on a linux system console (klaig.blogspot.be)
61 points by gbin on Sept 13, 2012 | hide | past | favorite | 22 comments


For me, the main reason not to switch 100% to the console is the web browser. There is no fb browser with proper CSS and HTML5 support.

At work, I have a dual monitor setup, one of them with a browser, the other with a console running 'screen'. If I could have the same setup in a console I would.

On the other hand, I feel like font rendering is much nicer under X11, and the clipboard support is better.


Browser support and fonts are also the things holding me back from doing more work without X. For clipboard support, try tmux[1], a screen alternative. I actually like the tmux clipboard more than X's because you can list and select from all previous copies/cuts. Tmux provides vi and emacs shortcuts to find and copy text from the console. The "tmux set-buffer" command can also be used in place of xclip.

[1] http://tmux.sourceforge.net/


Definately agree. I think a good alternative is something I used at my old job (when I wasn't required to run a clunky ide). Just use tmux for window management. Use vim for your ide. Use the shell for interacting w/ the OS and automating things. Then I use firefox with pentadactyl so I rarely have to ever resort to the mouse. Not the best dev environment, but I'm too lazy at this point to learn/develop alternatives. Maybe one day...


Check this out, I stumbled on it while making the blog post : firefox ported to directfb https://wiki.mozilla.org/Mobile/DFBPorting


But why have a huge complex browser in the first place? Do people really get much satisfaction from HTML gimmicks? Are they more interested in media (images, audio, video)?

Let's say you want to watch video. Download the video using a program designed for that. Then watch the video using mplayer which works fine with the Linux fb.

Same goes for photos. Download the photos quickly and efficiently using the command line and pipe them into a fb-friendly photo viewer.

There used to be this idea called MIME. Using separate programs to do separate things. Small simple programs that do one thing well. Mozilla has all but abandoned this concept. We all had to suffer through the hassle of Adobe Flash, only to finally admit it sucks and watch Adobe kill it. (.sfw = "small web file" - nice try guys)

And it now takes hours if not days for most consumer machines to compile Firefox. The compexity burden for a "modern web browser" is through the roof. The program is a monstrosity.

(And the codec jungle makes a simple video player like mplayer far too complex. We need some common sense here folks.)


Honestly, no.

I use gmail as my email manager, calendar, tasks, contacts, documents, and general organizer. That's why I haven't migrated to mutt or other console email client.

I agree that not all javascript is needed, but I wouldn't consider Gmail a gimmick


That would be awesome! I have an old computer which can barely run X, I could try firefox on the framebuffer


Well, to be honest a hardware-accelerated X server (which you'll get with even something as lowly as a 10-year-old S3 card) is faster than the framebuffer. What you might want to do is run X with a minimalistic window manager. Try "fluxbox" or "blackbox", both of those take about 1mb of memory :)


No need to get fancy, really

Several linux devs I know just Ctrl-Alt-F1 (or something else), screen, and there you have it.

mplayer for music, end of story


Yes but doing this keep x running in the background, wich might not be power efficient, remember that this is what he is trying to achieve.


Just stop X, easy. Or don't even start it in the first place

Use Mutt or Alpine for email


Could you send a signal to pause X so that it doesn't cause wakeups?


If I find some spare time, I'm going to try Terminology[1] (part of the Enlightenment project) in a framebuffer. Has builtin mouse, video and image support and is quite speedy.

1: http://www.enlightenment.org/p.php?p=about/terminology


Someone asks in the blog comments: What is the new watt usage after the environment is set up? I'm curious too.


The author responded in the comments:

"@sep332 @Mateus Carruccio, idle powertop doesn't change after the customizations compared to the non-customized console. Starting a framebuffer web browser pops up 200 wakeups per seconds. Also I was surprised by how much the backlight influence this number : around 5w difference, and my wireless mouse 2-3w. "

It appears it was originally at 15.2W with X and went to 9.98W in non-customized console.


It was 15.2W with X and full brightness, and 9.98W in non-customized console and a dimmed screen.

The screen brightness makes most of the difference.


> Unload X, unload a couple of daemons, dim your screen and you can get to [9.98W from 15.2W]

Your backlight makes up most of that power usage at idle. Measure your idle desktop on X with the screen dimmed, otherwise it's not a useful comparison.


Indeed, I agree cf my comment on the blog post. It is a 2w at most difference. The powertop comparison was more about the wakeups than the raw wattage.


Does TWIN (terminal windowing environment) still exist / is it maintained? If you want a rough proxy of a windowing environment, this is (or used to) exist. Seems to have dropped out of recent Debian repos though.

Screen and tmux can also help, both support vertical splits, tmux should do horizontal as well. Swapping between windows in a specific pane can give you a rough approximation of awesomewm or xmonad.

I also find the w3m console-mode browser to have better ergodynamics (mostly keybindings) than other console browsers. YMMV, but give it a shot.

Emacs, of course, is the original console windowing environment.


Very cool. And I suppose in a pinch you could always start X using FBDev when you need something that doesn't support the frame buffer directly.


I had a go at going X-less when KVM started working properly. I came to the conclusion that no matter how many neat workarounds exist for graphics on FB, it's still awkward; not worth the resource savings.


On my Debian Sid ThinkPad I've been primarily using the framebuffer console for years now. Setting up custom colors and fonts makes a big difference. Ctheme [1] is handy for making up color themes and changing them on the fly, but this [2] approach makes the colors more persistent. For fonts, I tweaked the SGI Screen fonts to my liking [3]. For viewing PDF files I found fbpdf [4] to be vastly superior to fbgs. The author of fbpdf also created fbpad [5], an alternative to fbterm. I've not tried yet fbpad yet, but the last time I gave fbterm a try I found it sort of took over every VT or something like that...hoping fbpad improves on that. Haven't heard of Terminology, will have to give that a try too. I'd be curious to see comparisons around scrolling speed and power consumption for the fbcon terminal, fbterm, fbpad, Terminology, and an XTerm/UXTerm running in X11.

In addition to tmux, Vim, Mutt and zsh, two other must-haves for me in this sort of environment are ncmpcpp [6] for music and Vifm [7] for file browsing. Note that vifm is quite actively developed (I believe there'll be a new version out in the next month or so), and the older version in the Debian repositories is much less feature-rich.

When I need something more I'll switch over to i3 running in X, but depending on the needs at hand, I've found it's possible to do quite a bit without turning on X11.

Something I've been wondering about...would it be possible to run an fbcon environment like this alongside Mozilla's B2G? I'm thinking of small, inexpensive, low-powered ARM devices where you could toggle between a full-featured modern graphical web-browser and a fast, powerful text-mode development environment.

[1] http://sourceforge.net/projects/ctheme/

[2] https://news.ycombinator.com/item?id=4413794

The colors I use:

echo 0,152,96,144,72,128,88,168,48,192,112,184,96,192,120,160 > /sys/module/vt/parameters/default_red echo 0,32,112,104,92,104,104,160,48,96,164,144,128,96,164,180 > /sys/module/vt/parameters/default_grn echo 0,32,48,80,144,176,104,144,48,96,96,80,192,176,144,176 > /sys/module/vt/parameters/default_blu

[3] http://b79.net/fields/comp#mono-bitmap

[4] http://repo.or.cz/w/fbpdf.git

[5] http://repo.or.cz/w/fbpad.git

[6] http://ncmpcpp.rybczak.net/

[7] http://vifm.sourceforge.net/




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: