After many months during which the
FileZilla FTP client would eat a ton of CPU and basically stop working in Fedora, whatever was wrong has been fixed, and the program is working once again.
After a FileZilla update caused the problem (and yes, I did contribute to the bug report), I set up
gFTP because I need a working FTP client. And gFTP gets the job done. It's super fast. It's also not actively developed.
Maybe I'll go back to FileZilla. Maybe not. But it's nice to have the option.
I wasn't even going to write about how I used to run Citrix on Windows 8 instead of Linux on my HP laptop because my particular Citrix-delivered application reacted poorly to the horrible DSL Extreme broadband service at home and its frequent (every three minutes or so) total dropouts. Maddeningly, the crucial link to "reconnect" to my application was present the Firefox and Chrome web browsers under Windows but absent in those same browsers under Linux.
No, I was instead going to write about how to configure Citrix in Linux to allow you to access local drives via your Citrix apps. I'd like to thank the Ubuntu community for that very helpful portion of an overall Citrix-on-Linux page that has helped me many times.
But since I'm already going this road, here is how and why I decided to do my Citrix-based production work in Fedora Linux instead of Windows 8.
Initially I thought I "had" to use Windows for the ungainly Citrix-delivered apps that my employer requires, including Adobe InCopy (which I wouldn't wish on anybody) and a proprietary CMS from Hell. That was when I was having Internet issues at home and kept getting disconnected from my Citrix apps.
But since then I've "solved" my broadband issue, and the connection is slow yet consistent (as opposed to slightly faster but extremely inconsistent; thanks DSL Extreme, who I'm dropping as soon as my contract ends).
So once I had "consistent" broadband, I thought I was home free. I could run my Citrix apps under Windows 8 (the 8.1 upgrade fails for me every time, probably because I dual-boot Fedora, and an encrypted Fedora at that) and all would be well.
Except that Win 8 started crashing. Yeah, I'm stressing the #$%& out of it, but that's how I work.
Buried in this blog post is a great tip: Using the Apache web server utility
ab to determine web site availability and speed.
Definitely check out the post (which is about hosting static sites on Amazon S3), and if you are interested, install ab, which comes bundled for Debian/Ubuntu-style Linux systems in
apache2-utils and for Fedora/RHEL/CentOS-style systems in
The article linked above gives you the command to install
apache2-utils in Ubuntu/Debian, and I could provide a similar
yum command for Fedora/CentOS, but you probably already know how to install packages both from the command line and a GUI, right?
(I'm not sure how you'd get the
Apache utilities in Mac OS X or Windows -- maybe someone else knows.)
Once you have the appropriate package installed (I already had it and didn't even know it), you just run the
ab program from a terminal. This line hits my site with 1,000 requests:
$ ab -n 1000 -c 40 http://stevenrosenberg.net/blog
And the output is:
This is ApacheBench, Version 2.3 <$Revision: 1604373 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking stevenrosenberg.net (be patient) Completed 100 requests Completed 200 requests Completed 300 requests Completed 400 requests Completed 500 requests Completed 600 requests Completed 700 requests Completed 800 requests Completed 900 requests Completed 1000 requests Finished 1000 requests Server Software: nginx/1.6.2 Server Hostname: stevenrosenberg.net Server Port: 80 Document Path: /blog Document Length: 309 bytes Concurrency Level: 40 Time taken for tests: 4.828 seconds Complete requests: 1000 Failed requests: 0 Non-2xx responses: 1000 Total transferred: 530000 bytes HTML transferred: 309000 bytes Requests per second: 207.14 [#/sec] (mean) Time per request: 193.109 [ms] (mean) Time per request: 4.828 [ms] (mean, across all concurrent requests) Transfer rate: 107.21 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 71 82 32.9 76 1077 Processing: 76 106 31.6 96 431 Waiting: 76 105 29.9 96 282 Total: 148 188 46.7 182 1157 Percentage of the requests served within a certain time (ms) 50% 182 66% 189 75% 199 80% 209 90% 232 95% 259 98% 283 99% 312 100% 1157 (longest request)
That's a pretty useful utility, am I right?
And it also shows that Ode can easily handle 1,000 simultaneous requests. Not bad at all.
It's a simple app. On Linux systems equipped with PulseAudio (which these days is most of them), it will record both sides of a conversation you are having on any application that pushes that audio over PulseAudio. The default is recording both sides of the conversation to a single OGG file. There is an "advanced" setting that records each side of the the conversation as a separate, uncompressed WAV file.
It's a simple app, and I can tell you that it works well. The wiki suggests that you use it with VOiP apps like Ekiga and Twinkle. Let me tell you now that it also works just fine with the non-free, freedom-hating Skype.
If you wanted to record a podcast, or just a VoIP call with someone else (and yes, PulseCaster warns you not to record without the other party's permission), it couldn't be easier than this.
PulseCaster is packaged for Fedora, but you can get the code from the links on the project home page (which is generated out of GitHub).
It's a simple app that works. What more could you want?
Why is PostgreSQL on the upswing while Oracle and the Oracle-controlled MySQL are going the other way? Matt Asay aims to explain it all at ReadWrite.
I had a pretty good day yesterday running the dodgy over-Citrix apps I need for my $Dayjob. But when bandwidth is poor and I keep getting disconnected, the only way I can manage to keep working is to run the Citrix apps in Windows (in my case Windows 8, not even 8.1 because that update went pear-shaped when I tried it months ago).
What happens is the bits on my DSL connection stop flowing for a minute or so, and I get disconnected from my Citrix apps. In Windows, there's an option on the Citrix page in my browser to reconnect to my "paused" resources. That option doesn't exist on the web page in Linux. Could it be because I'm using a slightly older version of Citrix Receiver / Wfica / ICA / Whatever the hell it is in Linux?
All I know is that it's a pain in the ass. When I'm on a "strong" networking connection with a ton of bandwidth, this isn't a problem, and I can probably run the Citrix apps in Linux. But with my not-so-great home "broadband," I need the extra cushion of being able to easily reconnect to my Citrix apps in order to stay working.
If you're having the same problem I am with Google Chrome crashing while running the proprietary AMD Catalyst video driver in Fedora 20 (or any other version of Linux), I have a fix.
My thought was that I could play with command-line switches to "trick" Google Chrome into running.
(Note before we begin: I think different distributions have different commands to run Google Chrome or Chromium in the first place. In Fedora, calling
google-chrome runs the browser.)
I found a huge list of command-line switches for Chrome and Chromium from Peter Beverloo's web site and started looking it over and trying a few.
This one worked:
$ google-chrome --disable-gpu
Peter's page describes
--disable-gpu this way (and links to this portion of the content-switches code for Chromium):
Disables GPU hardware acceleration. If software renderer is not in place, then the GPU process won't launch.
This means that I'm back in the Google Chrome-running business. I'll have to add this modified command-with-switch to my Xfce panel so I can run Chrome without the terminal.
And now you can, too.
Am I really the only person having trouble with the Google Chrome web browser while running the propretary AMD Catalyst video driver in Linux?
I pulled the AMD Catalyst driver from my Fedora 20 system to do some tests. Among the things that started working: The Google Chrome web browser, which in recent weeks kills X while running under the proprietary driver.
It turns out that Google Chrome runs fine with the open Radeon driver.
As always, AMD Catalyst giveth (cooler operation, working suspend/resume) and taketh away (Google Chrome fails, trouble updating when driver doesn't support new kernels, general wonkiness).
A couple days ago, there was a Google Chrome update, and for some reason the browser began working once again on my Fedora 20 system.
Now it's broken again.
It could have been a Mesa update in Fedora. Or something completely different. It could be the dubious AMD Catalyst/fglrx installation I have going, using Fedora 19 packages in Fedora 20.
Whatever it is, Google Chrome is broken again.
I even tried Spot's Chromium repo for Fedora. Chromium crashes X just the same.
Is it just me, or is anybody else having a problem with Chromium/Google Chrome in Fedora?