Monday, February 08, 2010
OpenSUSE Survey
http://www.surveymonkey.com/s/6MJYV7T
Tuesday, January 05, 2010
Desktop virtualization
The executive summary of our findings: It costs about the same amount of money as the normal regular PC and imaging cycle, but saves some labor compared to the existing environment.
Verdict: No cost savings, so not worth it. Labor savings not sufficient to commit.
Every dollar we saved in hardware in the labs was spent in the VM environment. Replacing $900 PCs with $400 thin clients (not their real prices) looks cheap, but when you're spending $500/seat on ESX licensing/Storage/Servers, it isn't actually cheaper. The price realities may have changed from 12 months ago, but the simple fact remains that the stimulus fairy bequeathed her bounty upon the salary budget to prevent layoffs rather than spending on swank new IT infrastructure.
The labor savings came in the form of a unified hardware environment minimizing the number of 'images' needing to be worked up. This minimized the amount of time spent changing all the images in order to install a new version of SPSS for instance. Or, in our case, integrating the needed changes to cut over from Novell printing to Microsoft printing.
This is fairly standard for us. WWU finds it far easier to commit people resources to a project than financial ones. I've joked in the past that $5 in salary is equivalent to $1 cash outlay when doing cost comparisons. Our time management practices generally don't allow hour by hour level accounting for changed business practices.
Labels: opensuse, virtualization
Wednesday, December 02, 2009
OpenSUSE depreciates SaX2
There is an ongoing thread on opensuse-factory right now about the announcement to ditch SaX2 from the distro. The reason for this is pretty well laid out in the mail message. Xorg now has vastly better auto-detection capabilities, so a tool that generates a static config isn't nearly as useful as it once was. Especially if its on a laptop that can encounter any number of conference room projectors.
This is something of the ultimate fate of Xwindows on Linux. Windows has been display-plug-n-play (and working plug-n-play at that) for many, many years now. The fact that XWindows still needed a text file to work right was an anachronism. So long as it works, I'm glad to see it. As it happens, it doesn't work for me right now, but that's beside the point. Display properties, and especially display properties in an LCD world, should be plug-n-play.
As one list-member mentioned, the old way of doing it was a lot worse. What is the old way? Well... when I first started with Linux, in order to get my Xwindows working, which was the XFree86 version of Xwin by the way, I needed my monitor manual, the manual for my graphics card, a ruler, and a calculator. I kid you not. This was the only way to get truly accurate ModeLines, and it is the ModeLines that tell Xwindows what resolution, refresh rate, and bit-depth combinations it can get away with.
Early tools had databases of graphics cards and monitors that you could sort through to pick defaults. But fine tuning, or getting a resolution that the defaults didn't think was achievable, required hand hacking. In large part this was due to the analog nature of CRTs. Now that displays have all gone digital, the sheer breadth of display options is now greatly reduced (in the CRT days you really could program an 800x800x32bit display into Xwin on a regular old 4:3 monitor, and it might even have looked good. You can't do that on an LCD.).
In addition, user-space display tools in both KDE and Gnome have advanced to the point that that's what most users will ever need. While I have done the gonzo-computing of a hand-edited xwindows config file, I do not miss it. I am glad that Xwindows has gotten to this point.
Unfortunately, it seems that auto-detect on Xwindows is about as reliable as Windows ME was about that. Which is to say, most of the time. But there are enough edge cases out there where it doesn't work right to make it feel iffy. It doesn't help that people tend to run Linux on their crappiest box in the house, boxes with old CRTs that don't report their information right. So I believe SaX2 still has some life in it, until the 8 year old crap dies off in sufficient numbers that this tool that dates from that era won't be needed any more.
Wednesday, November 25, 2009
Upgrading woes
I had two problems:
- The XWindows hot-plug support for input devices just plain doesn't work on my system. This was introduced in 11.1, so that would have bit me then.
- VMWare Workstation just wouldn't compile the modules. The 11.2 kernel is too new.
I don't know why the 'evdev' stuff in xorg is failing on me. It's on my list to figure out, but as I have a working config at the moment that's kind of low priority. But that needs fixing, since 11.3 will most assuredly reintroduce that fault.
VMWare.... reportedly version 7 works without a hitch. But I can't have that yet, so I had to get 6.5 in somehow. The crowbar I mentioned was killing certain processes the vmware installer spawns to compile the kernel modules it requires. Once those were ruthelessly murdered, the installer completed and it would work. Clearly, I have to be leery of kernel updates until I can use 7.
Other than some theme tweaks that I needed to redo, this was the cleanest upgrade I've had. All the Gnome stuff worked right out of the gate, which is a first. In the past I've had to blow away most of my Gnome configs and restart from scratch. I'm glad those bugs have been ironed out.
Tuesday, September 01, 2009
Pushing a feature
With that handy "@[machinename]" in it. These days it is much less informative.
If you're using SSH X-forwarding to manage remote servers, it is entirely possible you'll have multiple YaST windows open. How can you tell them apart? Back in the 9 days it was simple, the window told you. Since 10, the marker has gone away. This hasn't changed in 11.2 either. I would like this changed so I put in a FATE request!
If you'd also like this changed, feel free to vote up feature 306852! You'll need a novell.com login to vote (the opensuse.org site uses the same auth back end so if you have one there you have one on OpenFATE).
Thank you!
Monday, August 24, 2009
Trying KDE
My first reaction? It probably matched what a lot of long-time Windows users had when they saw Vista for the first time and wanted to do something that wasn't run a web browser:
Dear God, I can't find anything, and none of my hotkeys work. THIS SUCKS!In time I calmed down. I installed gnome, and lo it was good. I also noted certain settings that I needed on the KDE side. I switched back and explored some more. Found out where they kept the hotkeys. Found out where the sub-pixel hinting settings were hiding. This made my fingers and eyeballs happier.
Now that I've tried it for a while, in fact I'm posting from it right now, it's not that bad. Another desktop-dialect I can learn. I've gotten over that initial clueless flailing and have grasped the beginnings of the basic metaphor of KDE. I still prefer the Gnome side, but we'll see where I go in the future.
Wednesday, June 24, 2009
Why ext4 is very interesting
- Large directories. It can now handle very large directories. One source says unlimited directory sizes, and another less reliable source says sizes up to 64,000 files. This is primo for, say, a mailer. GroupWise would be able to run on this, if one was doing that.
- Extent-mapped files. More of a feature for file-systems that contain a lot of big files rather than tens of millions of 4k small files. This may be an optional feature. Even so, it replicates an XFS feature which makes ext4 a top contender for the MythTV and other linux-based PVR products. Even SD video can be 2GB/hour, HD can be a lot larger.
- Delayed allocation. Somewhat controversial, but if you have very high faith in your power environment, it can make for some nice performance gains. It allows the system to hold off on block allocation until a process either finishes writing, or triggers a dirty-cache limit, which further allows a decrease in potential file-frag and helps optimize disk I/O to some extent. Also, for highly transient files, such as mail queue files, it may allow some files to never actually hit disk between write and erase, which further increases performance. On the down side, in case of sudden power loss, delayed writes are simply lost completely.
- Persistent pre-allocation. This is a feature XFS has that allows a process to block out a defined size of disk without actually writing to it. For a PVR application, the app could pre-allocate a 1GB hunk of disk at the start of recording and be assured that it would be as contiguous as possible. Certain bittorrent clients 'preallocate' space for downloads, though some fake it by writing 4.4GB of zeros and overwriting the zeros with the true data as it comes down. This would allow such clients to truly pre-allocate space in a much more performant way.
- Online defrag. On traditional rotational media, and especially when there isn't a big chunk of storage virtualization between the server and the disk such as that provided by a modern storage array, this is much nicer. This is something else that XFS had, and ext is now picking up. Going back to the PVR again, if that recording pre-allocated 1GB of space and the recording is 2 hours long, at 2GB/hour it'll need a total of 4 GB. In theory each 1GB chunk could be on a completely diffrent part of the drive. An online defrag allows that file to be made contiguous without file-system downtime.
- SSD: A bad idea for SSD media, where you want to conserve your writes, and doesn't suffer a performance penalty for frag. Hopefully, the efstools used to make the filesystem will be smart enough to detect SSDs and set features appropriately.
- Storage Arrays: Not a good idea for extensive disk arrays like the HP EVA line. These arrays virtualize storage I/O to such an extent that file fragmentation doesn't cause the same performance problems as would a simple 6-disk RAID5 array would experience.
- Higher resolution time-stamps. This doesn't yet have much support anywhere, but it allows timestamps with nanosecond resolution. This may sound like a strange thing to put into a 'nifty features' list, but this does make me go "ooo!".
Monday, June 15, 2009
openSUSE 11.2 milestone 2
See?
Also, as of milestone 2, ext4 is the default file-system.
Tuesday, October 28, 2008
The gift of security
Between then and now I haven't really been able to use it at work. And since transporting files between work and home is one of the nicer features of it, it has largely sat unused. But right this moment it is mounted to my openSUSE 10.3 workstation. This beats a floppy disk for transporting pgp/gpg keys.
Monday, August 18, 2008
My favorite compiz plugin
I love that plugin. Ad-hoc screen captures. I use it all the freaking time. It has managed to engrain itself into my expectations about how computers should work to the extent that I started swearing at XP the other day since I couldn't do that. Such a simple thing, but my how effective it is at capturing a quick snippet of what I want. No more do I have to...
- PrtScrn the application I want
- Open Paint
- Paste the screencap
- Copy the section I need
- Create new canvas
- Paste the copied section
- Save to file
Monday, June 30, 2008
Novell Client for Linux, packaged for OpenSUSE
It should also be mentioned that Ubuntu is a very frequently requested target for another NCL, but I have reason to believe that'll never happen. First of all, any Novell Client involves closed source 3rd party licensed code, which makes it hard to port to Linux in the first place (a relic of being based on code from the days when open-source was just an ethical standpoint rather than a tangible market force). Second, Novell has proven to be rather light in developer resources in certain areas, and linux integration with non-SUSE linux distros is very minimal.
Wednesday, March 05, 2008
Flash on openSUSE 10.3
But. No sound for my YouTube! So, I had to fix that.
Right now I'm running openSUSE 10.3, and using Seamonkey as my primary browser (though Firefox was broken for flash too). It took me close to two hours to figure out what the heck went wrong and how to fix it.
Everything I found said I should run the following command to just make it work:
nspluginwrapper -v -i /usr/lib/browser-plugins/libflashplayer.so
Except I kept getting this error:
nspluginwrapper: no appropriate viewer found for ./libflashplayer.so
What ultimately ended up fixing it is the following series of commands:
As root:
- zypper rm nspluginwrapper nspluginwrapper-i386. This removed the existing nspluginwrapper install, which I suspect was borked.
- zypper in nspluginwrapper nspluginwrapper-i386. This installed both packages. Both packages ARE required for this to work on x86-64 machines. Remember, nspluginwrapper allows you to run 32-bit plugins in a 64-bit browser, so it has to cross the boundaries.
- nspluginwrapper -v -i /usr/lib/browser-plugins/libflashplayer.so This gave the following output:
- Install plugin /usr/lib/browser-plugins/libflashplayer.so
into /home/[user]/.mozilla/plugins/npwrapper.libflashplayer.so
Also of note, I believe that running the nspluginwrapper -v -i process may have to be done every time nspluginwrapper gets updated. But, it would seem I have to explicitly upgrade it so remembering to do it shouldn't be an issue.
Labels: opensuse
Friday, October 05, 2007
openSUSE 10.3 is in
Labels: linux, opensuse, virtualization
Friday, September 28, 2007
Novell client for Linux, part 2
KB reclen write rewrite read rereadCompare that with the earlier numbers for that record size and you can see the problem.
51200 256 9178 9189 9130 8898
KB reclen write rewrite read rereadSee? It has to be something in the Xen Dom0 environment.
51200 256 595 587 8551 8491
This would be a lot easier if Wireshark would stop freezing hard when I try to save a capture.
Novell Client for Linux
Performance was... not good. Unfortunately, right now I can't tell if that is a side effect of running it on openSUSE 10.2, inside a Dom0 Xen domain. I want to re-run it running the standard kernel and see if the performance also doth suck.
random randomAs you can see, performance at record sizes over 8 is not great for writes. Reads, on the other hand, are quite zippy. Still not as zippy as the Windows client, which I've seen get up to 11000 on those tests. But still, zippy. I don't know where the problem is. I did some sniffing to try and figure it out, but nothing really stuck out as a cause. I'm seeing some 160ms delays in ACKs, but they're coming from the server. I can't tell what condition of the client-side write is causing the delayed ACK. Need more testing.
KB reclen write rewrite read reread
51200 4 3259 3218 3875 4026
51200 8 5144 4925 5404 5215
51200 16 193 196 6980 6788
51200 32 593 599 8371 8309
51200 64 609 594 8213 8437
51200 128 589 590 8399 8432
51200 256 595 587 8551 8491
51200 512 598 595 8528 8439
51200 1024 596 588 8580 8295
51200 2048 594 596 8595 8542
51200 4096 597 609 8258 8548
51200 8192 595 599 8683 8683
51200 16384 608 599 8673 8585
Friday, August 24, 2007
openSUSE news
http://news.opensuse.org
They had a nice article today about the results of a recent desktop linux survey. Bucky had a nice bit of analysis about it too.
This is nice to see. As I've mentioned before, I'm using openSUSE 10.2 at work (and right now). I can't use SLED because we're not entitled to it, nor will my boss pay for it. That said, I probably could do what a co-worker is doing and run SLES10sp1 instead ;). OpenSUSE now has 10.3 beta 2 out, which I'm not going to test quite yet as I don't have a test system for it; I wish I did have one.
One of the nice things that'll be in 10.3 (or rather, not in) is they're doing away with zmd for updates, and using a libzypp based process instead. This cheers me, as I've had a lot of trouble with the zmd one. It's better than it was in 10.0/1, but still not good.
Also, of course, openSUSE code forms the basis for what'll eventually become SLED.
Wednesday, July 11, 2007
Novell Client for Linux beta 2.0 release on openSUSE
- Install the referenced RPM. I did it with an "rpm -i [rpm-name]". Use the RPM for your processor type. I'm using 64-bit and it worked just fine for me.
- Run the "ncl-install" from the beta download.
See that little sliver of an icon between the magnifying glass and the vertical bar? That's the nwtray icon. It's about 2 pixels wide. If I can click on it I get the full NWTRAY menu just fine, but it's hard to hit.
The other problem is the "Novell Services" button in nautilus. When I click that button, it looks like gnome crashes. I haven't been able to find out where the dump traces are going so I don't know what's up with that. If I access the services from the 2-pixel wide NWTRAY things work just fine, though.
Throughput still sucks, though. The Windows client is still better for that. But... throughput is w-a-y better than using a WebDav connection! Progress!
Friday, May 18, 2007
Acessing NetWare from openSUSE
- I have WinXP running in a Xen VM that I use for 90% of it. Network throughput blows chunks, though.
- NetStorage (MyFiles for you WWU people) supports WebDav, and so does Nautilus.
As you can see. In fact, I used the above screen to drop the screen-cap I made into my myweb folder for publication.
That said, there IS a way to get the Novell Client for Linux 1.2 installed to openSUSE, I just haven't done it yet. You can find instructions in the Novell newsgroups, which google handilly archives. I must mention that NCL1.2 will be getting service-packed when SLES10 SP1 comes up within the next month. These instructions may not be valid once SP1 is being published from download.novell.com.
Thursday, May 17, 2007
A peeve
I'm also using openSUSE 10.2 for my work desktop.
OpenSUSE has compiled Seamonkey as a 64-bit package, rather than 32-bit. This made flash a rather dodgy thing until Adobe released v9 for Linux. Unfortunately, Adobe has yet to release a 64-bit version of flash so I'm stuck using NSPluginwrapper to get flash. And since flash is on about, oh, 80% of commercial web pages it gets loaded a lot.
Something, somewhere causes nspluginwrapper to hang in such a way as to consume 100% CPU. I have a dual core, so this is livable. It also happens often enough that I've modified my seamonkey launcher to "nice" the seamonkey process to as low priority as I can get it. I don't know what causes it to spike like that, but cnn.com seems to trigger it, and YouTube vids are very likely to trigger it too. I've taken to using Firefox, 32-bit on 10.2, to view that sort of thing if I have to.
Once adobe gets off their butts and released a 64-bit flash plugin for Linux I'll be a very happy camper.
Friday, February 09, 2007
NetStorage and gnome davs::
Monday, January 29, 2007
An incompatibility
When run on a Windows XP virtual machine running on Xen 3.0.3 that comes with openSUSE 10.2, it causes the clock in the VM to slow w-a-y down. On the order of 1 tick per 30 ticks on the host machine slow. This makes it unusable in a rather significant way.
It also is completely unfixable! Running Windows in a full VM in Xen on openSUSE 10.2 is an unsupported operation. I have the CPU for it, and it runs pretty well in every other way. But something the inventory process does causes some Xen emulation to go 'poink' in a bad way. It is so bad that even after the VM is powered off and the BIOS is putting the virtual machine to rest, it STILL takes a very long time for the VM to unload. No idea where to report this one.
In general, the product looks interesting. Getting it rolled out everywhere will take a lot of work. Plus, for some reason it isn't accepting my license code. But that's something that can be fixed with a call in to Novell.
Labels: opensuse, virtualization, zenworks
Thursday, December 14, 2006
openSUSE 10.2 on the ASUS P5B Deluxe
There are two big areas that cause problems with this board:
- The chipset, Intel 965G, has no native PATA support so ASUS attached a JMicron PATA controller. The JMicron PATA controllers are broken in all but the newest kernels (2.6.18 or newer). There is a limp-mode for 2.6.16 and older that can work (google all-generic-ide). This is a b-i-g problem when you consider almost all Optical drives are still PATA.
- The kernel included with the Goldmaster media (2.6.18.2-34) locks up the install hard. The cause of which is, as of this writing, unknown [Update: the kernel falsly detects AGP, which is the source of the lock, using the boot option "agp=off" may bypass this detection]. This will probably change when they remaster the install media later on.
On the MAIN page in BIOS there is a sub-menu for IDE Configuration. You want to set 'Configure SATA as' to IDE. Don't use ACHI, so far only Vista can use ACHI right there. Linux will eventually support it. (and if you're reading this article two years from now, Linux probably has figured it out. Google harder.)
The second setting is on the ADVANCED menu, in the OnBoard Devices Configuration sub-menu. Set 'JMicron Controller Mode' to ACHI. That's right, ACHI. Not IDE. This allows the PATA optical devices to be detectable. This looks counter intuitive, but this is what seems to work.
Now that you've done that, you have put the shiny DVD into the optical drive and booted from it. You hit 'install from DVD' on the front screen, and.... it bombs, unable to detect the media.
That's because 10.2 isn't quite smart enough yet to detect it. You can force the issue by putting the following line on the "Boot Options" line on the front screen:
insmod=pata_jmicron
This tells the kernel to force-load the JMICRON driver. This allows the kernel to locate the DVD drive with which it'll continue the installation process.
Now comes the harder problem, the kernel shipped with 10.2 Goldmaster will hard lock the P5B. There is a work-around which you can find in Bug 229365.
- When the install gets to the 'now we will reboot your machine', click SKIP.
- [Control]+[Alt]+[F5] to get to a shell
- cd to /mnt/etc/
- vi modprobe.conf.local
- Append this text to the file "blacklist intel_agp"
- Save the file
- Reboot
[revised 12/21/2006]
Update 4/2/2007:
Turns out there have been some key problems in the Linux kernel relating to this particular P965 chipset. From a bug I reported a few weeks ago:
Looking at the lspci output I get the understanding thatWhich is a long way of saying that if Intel AGP is loaded, either compiled in or falsely loaded due to a bad detection by the kernel, it'll have problems. The kernel falsely detects an integrated graphics controller and attempts to load agp_gart, which if loaded does Bad Things. It looks like the openSUSE guys are now aware of this problem, so we may have a new kernel in the not too distant future to fix this. Or perhaps this is just on the list for 10.3 when it comes out. Don't know yet.
intel-agp shouldn't initialize at all - there's not Intel Integrated Graphics
controller. The code in intel-agp, however, blindly assumes an 845 if there's a
host bridge with no matching IG (in agp_intel_probe()).
Labels: opensuse
Monday, December 11, 2006
More on openSUSE 10.2
agpgart: Detected an Intel 965G Chipset.
Then locks the computer hard. Kinda useless.
On the up side I now can boot the Windows partition so I have access to big hard drives again. Yay. I'm currently re-downloading RC1, since I KNOW that worked. I'll then selectively bootstrap packages from 10.2-Final after I get it in. I'll avoid the kernels since I know those don't work. I'll wait for new kernels to get checked in that hopefully fix my problems.
I have a bug report in on it, but it's ranked 'normal' so won't get special attention.
Labels: opensuse