It seems that people are starting threads for Statler in various scenarios, so I hope this is correct--otherwise, moderators, please move it to the proper location

Installing from USB (without doing any reseach) I first ran into the known issue of it not being able to find the installation source.  There's a solution on the wiki, but I was already familiar with adding

cdrom-detect/try-usb=true

and used that.  This is a machine that already has Fedora, Arch, and Ubuntu Lucid on it.

The next issue was with the network.  It detected both cards, but was unable to get a DHCP address from the wired card.  I just continued without network. 

Then it was unable to install grub.  It also, to my annoyance, didn't offer any alternative, just went to install grub in the MBR, which I didn't want.  I was actually glad it failed.  However, it wouldn't give me the option to continue without installing grub.  When I tried, it just went back to the menu, highlighting installing grub.  At this point, I tried again, but it failed again.  I then chose finish the installation, but it refused.  So, I chose abort the installation.

My original plan (I use Fedora's grub on the machine) was to not install grub at all, and just point Fedora's grub.conf to the proper vmlinuz and initrd.img files.  So, even though it had aborted, I went ahead with doing that and tried to boot.  It booted successfully, but wouldn't let me log in as root or as the user I'd created.

So, I rebooted again, and noticed that Fedora, Arch, and Ubuntu were no longer able to see the wired network card.  It was as if, in failing to be able to use it, #!Crunchbang had eliminated it.  smile 

This wasn't a big deal--I'd had the same thing happen with Arch--it's one of those oddities--in both cases, the install recognized the card, tried to assign DHCP, couldn't and then, upon reboot, though the card showed in the BIOS, none of the previously installed systems could see it.  I already knew, from experience with the Arch install, that shutting it down, waiting a minute or so, booting, and then, repeating the process if necessary, would bring the card back, so this was more an annoyance than some sort of Oh nooooooooooo thing. 

I booted into Fedora, mounted the #!Crunchbang partition, and did a chroot into it, which worked.  While chrooted, I reset root's password. I had to re-add the user--although there had been no sign of it failing during the install, apparently, when the install aborted, the user didn't get added.

Once this was done, I booted up (by this time, I'd gotten the wired card working again.)  Everything was then as expected.

Curious about this, I then rebooted, this time choosing live. (Without adding the usb=true parameter.)  It booted without issue, and both wired and wireless worked.

Becoming more curious, I reinstalled--this time, when it wanted to configure the network, I wasn't able to tab over to cancel, but let it try with the wireless, which failed--as expected, I didn't put in the wireless network name or password.  Then, I had the option to cancel, which I did.  I ran into the same issue of grub not installing (nor giving me a real option to not install grub--if one chooses continue without grub, it just kept coming back to the main menu).   So, once again, aborted installation, it booted properly when given vmlinuz and intrd.img paths, and again wouldn't allow me to log in. Once again, fixed with booting into Fedora, mounting and using chroot.   This time, the network card showed up in Fedora--I didn't test this with a reinstall of Arch, but it seems that trying to configure the wired ethernet is what causes the problem with other systems upon reboot.

Once password had been set for root and the user added (both through the chroot), and the lines for it added to Fedora's grub, it booted without problem.  Both wired and wireless ethernet also worked without an issue.

As I don't really consider #!Crunchbang aimed at the Windows refugee type of user, (as, generally speaking, openbox is preferred by more experienced users), I wouldn't call any of these showstoppers for someone with experience.  Seems, once installed, to be very very nice, and congratulations on yet another nice version. 

Needs more packages of course, but I know you're working on that. 

Thank you.

Unfortunately, these days I have little time to play with #!Crunchbang, but did decide to try Statler. I notice the wiki gives instructions for a USB installation at

http://crunchbanglinux.org/wiki/statler … stallation

A simpler, IMHO, way to do it is to, if using unetbootin, when it say hit tab to edit at the boot screen, hit said tab key and add, at the end of the line

cdrom-detect/try-usb=true

Just seems a bit easier to me.  (Although habit of course, is a factor)  smile

Well....pulseaudio.  Start advertising Crunchbang on Ubuntu and Fedora forums as "One of the few that doesn't use pulseaudio" and the problem is, it will probably crash the server with folks trying to download it.

Pulse audio, as the developer complained--his complaint was that people were saying this---is a solution in search of a problem. Aside from breaking Skype for awhile, breaking sound for many, being a general nuisance, and showing no improvement over previous alsa sound, I can't think of a reason to ban it.  smile

Reasons against banning it---avoiding previously mentioned overload on servers.

Glad to be of help.  Keep in mind that sooner or later, scim is probably going to be almost completely replaced by ibus, in the same way that scim-anthy gradually almost completely replaced the kinput-canna combination.

Ok, I just tried this on CentOS, and this is what I found.  Using LC_CTYPE=en_US, I could not get it to work.  (I didn't even get anthy to open).

When I tried export LC_CTYPE=ja_JP.UTF8 , that worked.

So, in a terminal try.
echo $XMODIFIERS

It should come back @im=SCIM

If it doesn't then

export XMODIFIERS='@im=SCIM'

export LC_CTYPE=ja_JP.UTF-8

export GTK_IM_MODULE="scim"

after you've typed all that, in the same terminal, type something like uxterm, which will open up another terminal.  The reason we're doing this is to make sure that the values of these variables were properly exported.  In that second terminal, do a check

echo $XMODIFIERS $LC_CTYPE $GTK_IM_MODULE

If they come out correctly, we're good.

Now in that second terminal try typing

abiword

Abiword will open, and this may fix the issue.

Yup, I see--I was on page one.  Sigh....

@awebb, that's the best way to thank those that come before you.  It's actually, IMHO, better when such things are written by those who are less familiar with the program, because they're more likely to realize what will stump a new comer.  Whereas, someone more experienced might write, for example, set your LC_CTYPE.  The newcomer will look and wonder--How do I set LC_CTYPE? 
Whereas, someone who just figured it out will *explain* how to set the LC_CTYPE.

@Tooolz--.bash_profile is read once, when you log in, .bashrc is read each time you open a shell.  Therefore, in theory, it saves resources to put things you *should* only need to be read once in .bash_profile, as in .bashrc, it has to be read and acted upon each time you open a terminal.

@Awebb, I'm not sure.  I would try, after logging in, running

source .bash_profile

and seeing if it fixes it.  As #! is Ubuntu based, and therefore has too many system thingies tied into the GUI, it's probably some kind of weirdness inherited from Gnome.  It's one reason I much prefer starting in runlevel 3--my main distro is Fedora (which I have to use at work) and I find that doing this helps me avoid many things that others find to be common problems.

I would put it in .bash_profile then, which would work each time you log in.  That is, in .bash_profile

export XMODIFIERS='@im=SCIM'
export LC_CTPYE=en_US.UTF-8
export GTK_IM_MODULE="scim"
export QT_IM_MODULE="scim"

Then, when you log in, do scim  -d in a terminal. That terminal can be closed as soon as it starts. (You might be able to do scim -d in .bash_profile as well.)

I haven't done it that way in awhile, but IIRC, that should work.

And thank you for clarifying as well, I didn't realize what you meant.   smile

10

(57 replies, posted in Help & Support (Stable))

The first two characters were kotae (answer) after that a thank you.  He was just thanking me for the answer. 

You should be able to read Asian characters, go to view=character encoding (or something similar--I'm in opera right now, and look for UTF-8.   smile

11

(57 replies, posted in Help & Support (Stable))

Sigh, I've really got to go to sleep (almost midnight here) so I hope my answer will be understandable.  smile

I think if you do, from a terminal

XMODIFIERS='@im=SCIM' LC_CTYPE=en_US.UTF-8 GTK_IM_MODULE="scim" firefox

that it will probably work. If that doesn't work, try changing en_US.UTF-8 (assuming that's your usual language, of course) to ja_JP.UTF-8

I'll give more of an explanation tomorrow (though probably not till the evening).  Just a really brief explanation---often all you need to do is set XMODIFIERS and LC_CTYPE.  I've found this to vary with distribution (and OS, e.g., the BSDs) and the application.  For example, Firefox is a GTK app so it will probably work with *either* ja_JP.UTF-8 OR GTK_IM_MODULE.  However, sometimes, it needs both.  I'm writing this from CentOS, so can't do a hands on test at this instant.

12

(57 replies, posted in Help & Support (Stable))

What application are you using? 

I assume scim is installed.  (and scim-anthy).

You might need a UTF-8 capable terminal. 

Would you try, after making sure the scim daemon is started (with scim -d)

XMODIFIERS='@im=SCIM' LC_CTYPE=en_US.UTF-8 uxterm

See if you are able to input Japanese in that terminal.

13

(57 replies, posted in Help & Support (Stable))

Ah thank you.  To be honest, I usually use fluxbox, so hadn't realized that.

The Locale warning sometimes has to do with using utf8 rather than UTF-8.  You might even want to do something like dpkg-reconfigure locales and make sure you have the necessary ones.  (I hope I have the command right, I'm in CentOS as I type this, so can't check.) 

Also do locale -a |grep ja_JP and see how they list it, if it's UTF-8, utf8 or whatever.  If the dpkg-reconfigure locales (locale?  Again, can't check at this instant) doesn't fix it, sometimes playing with the case and hypenation of utf-8 will fix it.

Also, it will sometimes work, even if you get that message.  (And sometimes, it won't).

14

(57 replies, posted in Help & Support (Stable))

clemens, have you tried something like, from an xterm

XMODIFIERS='@im=SCIM' LC_CTYPE=ja_JP.UTF-8 firefox

Then hit ctl+space to bring up the Japanese input box?
OpenOffice can sometimes be tricky. Sometimes, one has to specifically add language support from the Tools=>Options menus and play around with the language options.  I'm afraid I can't be of any help with Chinese and Korean.

I believe that putting in your .bash_profile
export XMODIFIERS='@im=SCIM'
export LC_CTYPE=en_US.UTF-8
export GTK_IM_MODULE="scim"
export QT_IM_MODULE="scim"
scim -d

might accomplish your other desire, that of having it work each time at startup.  I haven't done that in awhile though, as my need for it is relatively infrequent.

That still might not work with openoffice.  Assuming you're doing the above, and it doesn't, then I would open it from the command line with

LC_CTYPE=ja_JP.UTF-8 <whatever the latest command to open openoffice may be>
OpenOffice, depending upon version, distribution and many other things which seem to change from time to time (or more likely, I've found my quick fixes so never kept track), often seems to require setting the LC_CTYPE to ja_JP.

15

(10 replies, posted in Off Topic / General Chat)

It seems the only moderately active fluxbox based one is antiX, based on Mepis.  Not quite as convenient as #!, as for one, it doesn't easily boot from a USB drive, there's something in there complaining about no CD.

(It can be done, but I've forgotten the procedure.)

Even that isn't all that active.  There was a release in August and there's been another beta out since December 20th.

Though I prefer fluxbox to openbox,  #! is quicker to install and configure (for me) though I like the default antiX background.  (Trees and such, very nice.)  (That's not an effort to start a war over the two *boxes, they're both great window managers, it's simply my own personal taste, and no doubt, years of habit.) 

Fluxbuntu has seemed relatively inactive.  Fluxbox version of Mint also exists, but always seems a bit behind. 

No offense meant to any of them, just #! comes a bit closer to my personal tastes, plus it's quick to install.

16

(7 replies, posted in Help & Support (Stable))

Frankly, I think my own howto is better.  smile

http://home.roadrunner.com/~computertai … .html#5007

@nik_doof, I know that some people have issues with ath5k.  (I haven't been one of them, however.)  I wasn't sure this version of #!Crunchbang would include it because the newer EEE's no longer use the AR5007EG.

Just for fun, I tried this on my Aspire One.  One nice thing is that the ath5k module is included, meaning wireless works out of the box. (Ubuntu's made the, IMHO VERY wrong decision to exclude it for the moment, although it's installable with the backports for Intrepid). 

Great job, even if it's for a different netbook.  Now, we need one for the MSI Wind with the 802 N card.  smile

Actually, even in its normal and Lite forms, I've found Crunchbang to just be better on this netbook than a few other lightweight distributions.

19

(4 replies, posted in Help & Support (Stable))

Heh, well, to a dinosaur like myself, it was much better than alsa.   The BSDs still make use of it, and although I haven't followed it that closely, I believe that on both Ubuntu and Fedora forums, some folks have found it necessary for some things (but I don't remember the specifics and could easily be wrong on that.)

At any rate, it's what was there before someone decided alsa was a good solution.  From the coding/developer end, I have no idea, but along with the BSD crowd, I always considered alsa a regression.  smile  Pulseaudio is even more of one.  smile

20

(4 replies, posted in Help & Support (Stable))

Pulse audio is still very new, and not working properly for many many people.  It's even worse in Fedora, where, when someone has sound problems, on their forums the usual advice is to start by removing pulseaudio.  smile

The fact that #!Crunchbang doesn't use it is a definite plus to many people.

21

(8 replies, posted in CrunchBang Talk)

What I admire most about the fellow is that he went on IRC and took the abuse to get the information.  Their (the dwm people) whole thing about remaining elitest and keeping clueless newbies away, does make one wonder if the program was written by 12 year olds.  smile 

Actually, I think it was Einstein who said something to the effect of, "If you can't explain it simply, you don't understand it well enough."

22

(8 replies, posted in CrunchBang Talk)

Here's another, IMHO better tutorial

http://www.xsnake.net/howto/dwm/dwm-eng.php

Here's one for ya.  In CentOS 5.2, with opera beta 10 and FF3. 
I go to the Linksys site.  If I go to choose the time, the drop down box won't work properly in opera.  I have to use firefox.

However, once I'm at the item, if, for example, I want to download firmware, *that* won't work in firefox.  Instead, I have to copy the url and open it in opera to download.

As has been said, some sites are better with one, others with the other. As FF is so popular, many developers make sure that their site works with it.

With opera, its more standards compliant, so I've heard.  (As in, "I saw it somewhere on the Internet, it MUST be true.")  Regardless, it seems to have trouble with more sites than does FF.

I think much of it is a matter of personal taste.

24

(526 replies, posted in CrunchBang Talk)

I'm not sure if this is a stupid idea or a good one. 
At any rate, after core's post, asking for feedback about the description, and various other posts in, for example, the introduction section, I thought it *might* be worthwhile. 

So....why did you try #!Crunchbang?  Why do you still use it?  I guess I'll go first.  smile

I'm a FreeBSD lover at heart, but my current job revolves around CentOS servers, so I came back to the Linux world.  I use Fedora as my main desktop, the logic being that fixing things that break on a desktop will help me when things don't go right with the servers. 

Fedora is almost broken by design--that's an exaggeration, but as it's more or less a test bed for RedHat, regardless of what the official line is, they tend to put things in that don't work properly.  In addition, they're heavily Gnome-centric, and many things will work out of the box in Gnome, but not with Fluxbox, Openbox or other lightweight window managers. 

As many friends, as well as a few of my users, run Ubuntu, I usually try to more or less keep up with it as well, running it on a laptop as a secondary O/S.  One thing I noticed was that when compared with Fedora, many things work much better.  I suspect that this is partially due to the different goals--Ubuntu's stated number one bug is that Windows is more popular.

Although something like ArchLinux will always be one of my favorites, I find that in my old age, I get impatient having to configure sound, wireless, etc., and grow to appreciate the distros where it just works.  It leaves me more time to do my work. 

So, Crunchbang interested me when I read about it.  Based on Ubuntu, which often just works, but without its bloat.  Although I prefer Flux to Open, I like Openbox too.  The Fluxbox-cum-Ubuntu based distros usually seem to be a bit behind whatever is current, which was one reason I never really settled on any of them. 

So, I tried Crunchbang.  After fixing my Openbox and panel to my liking, I changed my desktop to Fluxbox.  (I just wanted to make sure I could still configure Openbox.)  I've found that it gives me enough to do my work without getting in my way.  I've frequently, on these forums, referred to it as an ArchLinux for busy people, and the more I use it, the more I like that expression, misleading though it is.

So, even though I change the desktop and basically waste all of corenominal's hard work on getting sane defaults for panels, menus and the like, it's almost like doing a command line Ubuntu install, then customizing it afterwards--however, without the time and effort spent in doing so.  The basics have been done for me--sound, multimedia, X, plugins and the like.  It gives me access to the Ubuntu repos, which are far more complete than Fedora's--just as an example, Xbuffy an XBiff-ish program that can watch multiple mailboxes, is available.  It isn't in Fedora, and as it's a very old program, it's not even easy to build from source anymore.

So, #!Crunchbang gives me, with little effort, a nice base which doesn't complain if I customize it.  (Unlike both Ubuntu and Fedora, both of which seem to fight you if you decide to not use Gnome.)

That might even be a slogan if it was polished up a bit.  It gives you enough to let you do your work and doesn't give you so much that it gets in your way.

25

(57 replies, posted in Help & Support (Stable))

My pleasure.  More correct Japanese would probably be (I'm using romaji as I don't have scim running right now)

sukotto san ni ha (ha being wa in this case) tasukete itadaite arigatou gozaimashita.  (Also gozaimasu is seldom written in kanji--mostly we foreigners do it.)  smile  (My first name is Scott, so it's actually sukotto rather than sukottro, but that's not important).

(That's rather polite, especially using itadaite, the same verb base as itadakimasu.) So, to a native Japanese, you'd probably do it that way, tasukete itadaite, and not use kanji for gozaru.  (gozaimasu).

However, as I think we're a fairly casual bunch here, and you don't know that I'm ancient in years (or didn't till just now) doing tasukete kurete (as in kurimasu, ) would be fine. 

Actually, if writing to a native Japanese, you might even make it more polite to the point of exaggeration and use

itsudemo tasukete itadaite.  smile

(I'm not sure how advanced you are in Japanese, so if this was yokei na osewa, yurushite kudasai.)

As I mention on my page, it seems to depend not only on application, but on the system.  For example, in BSD and CentOS, I need to use LC_CTYPE=ja_JP.UTF-8 for Openoffice to work.  On  Ubuntu, en_US.UTF-8 works fine with OO as long as I have the GTK_IM_MODULE.   You can also at QT_IM_MODULE for safety in case you use some KDE apps.

(Just as an additional argument in the script, on the same line as the rest of it.)

The GTK_IM_MODULE is, as you've realized, necessary for GTK apps. (Though, you can sometimes skip it if you use LC_CTYPE=ja_JP.UTF-8).  I left it out of the first set of instructions because it's not necessary for uxterm, but I should have explained it a bit better.

As I said, it can vary, not only between applications, but between distributions and O/S's (e.g., Linux and BSDs.)
Generally speaking the GTK and QT IM_MODULES and LC_CTYPE, as your native language (with UTF-8) and the XMODIFIERS should do it.

There are other GUI centric ways, which I don't use, so I'm not really sure of how they work--e.g., in Ubuntu, I think you can choose input method or something like that from a right click menu.  The way I've given you here, however, should work on all systems with any sort of window manager.