Now, although I'd worked with Linux (Fedora) in the COSC labs before (and previously with a flaky partial install of Cygwin on an old computer at home), this would probably have been my first real Linux box where I could actually go through and play with setting things up (i.e. /me has admin rights). Here are some thoughts/findings so far...
1) Package Managers
Having played with the package managers for installing software (mostly from the command-line, and issuing stock commands from some recipe books), I've come to see the logic and beauty of this system of software distribution.
Installing software is just a matter of going to a central place using a consistent interface, and telling it to install ($ sudo apt-get install some-package-name). Usually it works, though sometimes there are conflicts which force a little digging and perhaps some purging of stuff, but that's usually a minor occurrence.
No need to worry whether about getting the right version of software if you need a tightly integrated set of packages; just use whatever default set is offered by that version of the distro. Hopefully the versions they've got aren't too horrible ;)
And in the event that you want an updated version of one particular package, it's really just a matter of telling the system to search an additional repository which just contains up to date versions of particular packages. In my case, it was Geany (Ubuntu gave me 0.18, but IMO you really need 0.20 at least to get some of my recent favourite workflow loves, such as hotkeys for moving lines up/down and also the ability to put its symbol list/documents tabs on the right. It's a pity that I still can't set the symbol list to default to Appearance order vs Alphabetical, but at least I know that it's easy to hack if the need arises ;) given that since I was doing a fair bit of dev work on this platform, a nice text editor is necessary.
2) Open in Terminal
In the COSC labs, there would be an "Open in Terminal" entry in context menus (RMB) in any open file browser window. That was one of the things I really loved about working in that Linux environment (as well as the "flash drive still plugged in" warning with loud squaking buzzer, which I've only come to really appreciate recently when I had to drive back to the office and fumble with the after hours card access to retrieve my flash drive accidentally left still plugged into the machine).
However, I soon found that actually, this is NOT INSTALLED BY DEFAULT! It turns out that you have to explicitly install the "nautilus-open-terminal" package, and then restart the Gnome Desktop Manager (or simply login and logout).
The command line for reference
$ sudo apt-get install nautilus-open-terminal
3) Running Python Scripts
Due to the IT setup at the University, all internet traffic must be directed through a proxy server (or something along those lines). On a Linux box, that involves telnetting to a server to enable access, while on Windows, there is an executable provided. Anyhow, I've ended up hacking a Python script to automate this connection dance (you need to connect once for everytime you want to do an atomic login or atomic logout), which I usually just leave running for the entire session after typing in the password when it asks (for security reasons, I eventually decided not to store my password in plaintext in the script, since other users can browse everyone else's files!).
However, even after marking the file as executable and placing a shebang at the start, I'm still not having any luck trying to double-click to run this script. On past boxes that I've worked with, it's usually been possible to get at least a dialog box to choose between running or editing. But here, it silently fails, and I have to resort to using a shell to fire it up. Not really a biggie with tab completion and "Open in Terminal" available everywhere, but still...
Suggestions to get this working are welcome!
4) Intermittently failing USB Drive Detection
From time to time, I've had a few problems getting my flash drive to mount properly when connecting it up. Usually this occurs after having done this earlier in the day, though I haven't found any pattern, and after having tried by "Safely Remove.." and "Eject" as well as just forcibly pulling the thing out when done.
The last time this happened, I ended up doing some searching until I found a posting suggesting that "gparted" be run (Note: it seems to require sudo powers to run) to try and get access to it. When I tried this, after booting it up and identifying the port that the drive was plugged into, it suddenly came back to life and I was able to use it normally, without having clicked on or doing anything. Dunno if I'll be this lucky again next time.
Anyone have any ideas why this keeps going wrong?
5) Fast startup, impossible shutdown
I've often heard Linux-based people brag about how their machines start up much faster than a comparable Windows. In my experience so far, this is true for some machine+distro combinations, but not for others. At least with the one I've been using, I guess this is true.
As a result of the convoluted IT setup at the Uni though, it also seems that I've been getting a bit of login troubles on a fresh startup in the mornings, ranging from authentication errors on passwords to very slow performance (with things like terminals repeatedly failing to show up when requested). The only effective solution I've found is to startup and login to an auxiliary account I've added in, then forcibly manually restarting the machine (power off, power on).
Why not do a proper restart from the system bar? Well, it turns out that logging out and/or shutdowns from there aren't always reliable. In fact, there can at times be a good 30 second wait for even a dialog to show up (if it does at all). For an OS with fast startup, it doesn't like to shutdown... perhaps that's why people talk of having half-year uptimes ;)
With the Fedora setup in the COSC labs, I can't say that I've encountered this problem before. It was always quite good at logging out and shutdowns. However, the same can't be said for a Linux Live CD I liked to tinker around with for a while, which would actually tend to just hang itself on a black screen with blinking cursor on shutdown. So, perhaps Linux doesn't really do shutdowns in all cases...
6) Incompatibility with HP Touchsmarts?
Originally, I played around with a HP Touchsmart for a while (it ran Win7, but that's another matter for another time). As I've found, their touch screens are generally ok in the middle, but really really bad on the edges (as in, will not register finger touches). In fact, I generally found it better to use a soft but reasonably pointy pen cap instead of a finger for touching this surface, since fingers often ended up registering clicks which would miss their targets by a good few mm's everytime - a problem which is made worse when dealing with the typically tiny desktop widgets tightly packed on a high-res screen (designed for "sitting use" in standard computer use position, but not that great anywhere else).
An initial attempt was made to try and boot Ubuntu onto this thing. The CD drive for this box was a slit in the side of the case, with no indication of which side the data side should go. It took two attempts to figure out how to get the disk into there - the first time, after the machine failed to read the disk and booted into windows, it was clear that perhaps the disk had gone in the wrong way (though thankfully there weren't any serious scratches when it came back out). However, when the disk finally did make it into the machine, the screen would eventually go blank (after initially showing a promising purple screen with some branding graphics on it), the disk drive go silent, and the whole thing just being unresponsive to anything (though interestingly, some key presses would cause to disk drive to flare up for a few seconds, before going back to sleep).
Anyways, in the end, I now have two machines, with two sets of mice and keyboards on my desk. It's actually quite nice working like that, and IMO better than just a single machine with multiple screens, as long as you don't need direct access to the same files between both machines without an external shared filesystem.
7) "Gnome Default Keyrings"
When working with SVN to access a SSH protected repository, the first time I tried to set this up, I ended up inadvertantly setting up such a password+username combination for this thingy.
Anyhow, I wonder if there's any way to get access to this thing via a GUI, so that I can either type in the required password on startup, or (my preferred option) get rid of the password on this so that it just magically passes through without butchering my SVN ups when not running from commandline first. /me hates passwords.
For 3 - the main thing I think relates to this is the environment - I have found that various env variables like PATH can be set in the shell startup script that may not be present in a gui run program environment - I recall vars being able to be set in x11 login config files but can't remember off the top of my head. The main point being use full paths, don't rely on any env variables to be set - or explicitly read in files to define them.ReplyDelete
For 7 - look at ssh-askpass for gui ssh auth - often accessed through env variable SUDO_ASKPASS (see issue 3 above). The other option is using keys. Basically generate an rsa key and copy the public part to ~/.ssh/authorised_keys2 in the target ssh server. This allows you to log to remote ssh servers without passwords.
My experience with flash drives/cameras, and occasionally DVDs, in 10.10 anyway: they don't really seem to unmount properly the first time, when you unmount them it kind of acts like it has but comes right back after a few seconds; unmounting a second time makes it actually happen. Perhaps any mounting issues stem from it thinking something else is supposed to be there.ReplyDelete
You’ve probably figured out by now that double-clickable icons are not executable programs/scripts as such, but .desktop files that contain a command to execute them.ReplyDelete