For openSUSE 13.2, I thought I would try installing it on three very different computers before posting my experiences
to the forum:
- Laptop - upgrade from 13.1 using DVD.
- Desktop - new install from DVD.
- Workstation - new install from DVD.
LAPTOP
Hardware: Intel Core i7-4500U with Intel HD integrated graphics.
Software: openSUSE_13.2_x86_64_KDE dual-boot (alongside Win8)
Probably, one of the main strengths of openSUSE is the seemless procedure for incremental upgrades. I believe this
really sets openSUSE well above the many *buntu-based distributions that offer no such facility. The installer detected
the UEFI boot and /etc/fstab entries flawlessly and the upgrade went without a hitch. It appears the GRUB screen for
UEFI boots from DVD looks different compared to BIOS boots. I wondered why. I suspect it’s something to do with GRUB-EFI
vs ISOLINUX.
There were only a couple of minor issues for me. The first was simply a number of gcc libraries that went awol after the
upgrade that caused gcc to complain when compiling a couple of my C++/C/IAx86_64 programs. However this was easily
resolved by reinstalling them using zypper. The second issue was the use of Wicked to connect to wireless networks. I
could connect to wireless networks after being assigned an IP address, but the connection refused to allow TCP/IP
traffic (I couldn’t even ping). This was resolved was resorting to KDE’s Network Manager.
Although openSUSE 13.2 comes with gcc 4.8, it’s reassuring that 4.9 is a straightfoward option for the future. I’m sure
the under-the-hood improvements to YaST and Btrfs support are all good, but in all honesty they have little impact on my
day-to-day activities on this computer. Similarly the KDE improvements are probably a little wasted on me because I
spend most of my time in consoles. I prefered the darker styling of openSUSE 12.3 and 13.1 compared to 13.2, but this is
of course just a matter of personal taste. The contour desktop wallpaper looked reasonable, but I preferred to switch
back to a plain black desktop (although I kept the default wallpaper for openSUSE 12.3 an 13.1). Overall, however, it
was a very smooth upgrade.
DESKTOP
Hardware: Intel Core i7-975 with AMD Radeon graphics card (dual GPU).
Software: openSUSE_13.2_x86_64_KDE quad-boot (alongside Win7, Linux Mint 17, and Gentoo)
I was concerned about this particular installation because whatever I did in openSUSE 13.1, the proprietary AMD graphics
driver (fglrx) failed spectacularly. Although there were a lot of helpful suggestions from the forum in sorting it out,
it never worked and finally I was advised by a forum moderator to report the problem to the kernel developers or AMD.
However, I knew it wasn’t a driver or kernel issue because the proprietary drivers worked perfectly well in other
distributions running identical kernel versions, and so the cause must having been openSUSE patching. I was tempted to
bugzilla it, except I didn’t want to distract the openSUSE developers with a problem that didn’t seem to affect other
AMD users and was downstream from a closed-source blob. However, rather than upgrading from 13.1, I decided to perform a
fresh install and hope for the best.
In the light of previous experience, I first checked that the BIOS had disabled the floppy disk controller and I booted
the DVD. The installer started well until it came to the Suggested partitioning'. As if a punch in the face, the installer suggested’ XFS for /home and Btrfs, and then a multitude of Btrfs subvolumes for /opt/, /srv/, /tmp/,
/usr/local/. and loads for /var/*? Was the openSUSE installer programmer on drugs? And does openSUSE ever want to
appeal to GNU/Linux newcomers? I guess not. If you want really put someone off GNU/Linux forever, then this is a
perfect way to start.
There’s not even a help' button to inform the newcomer, who might understand nothing more from this then please
completely rape my hard drive’. Honestly, the suggested partitioning' tool should _preceded_ by a dialogue box with a drop-down for which hard drive to use and checkboxes for use Btrfs with/without subvolumes for /tmp/ directory and
/var/ subdirectories’ and use separate ext4/XFS/Btrfs home partition'. I realise that you can Edit Proposal Settings’
but this should be done before the suggested partitioning.
So if you decide to do something simple' you all of a sudden must click Expert Partitioner’ or clicking on Custom Partitioning (for experts)'. Sorry, but common sense - this is not! In the days of the Suggested partitioning’ from
S.u.S.E. comprising nothing more than a root volume and swap (+/- separate home), fair enough. But the Btrfs default
with multitudinuous subvolumes is infinitely more `expert’ than the custom partitioning - why the hell might I want a
separate subvolume for /var/lib/pgsql anyway??? I know that Chris Fisher from the Linux Action Show was impressed by
this nonsense but I, and more importantly potential GNU/Linux newcomers, would not be impressed. Come on openSUSE
developers! Try not to scare people!
Not to feel too outdone by the suggested partitioning', I deviated from my usual simple 4 partition setup (/boot/, /, /swap/, /home/), and opted for a 6 partition arrangement (/boot/, /, /swap/, /tmp/, /var/, /home/), with the last 4 as logical volumes within a single extended partition. Again the installer attempted to confuse, asking (for no obvious reason) whether the Role’ of each new partition was for Operating System', Data and ISV Applications’, Swap', or Raw Volume (unformatted)’. If I truly am an expert' partitioner, why the hell should I tell _anyone_ the intended role? Again, common sense distinctly absent. To rebel against the installer, I decided to format / with XFS and /home/ with Btrfs! My /home/ only comprises of symlinks to ntfs_3g partitions so I don't particularly care if it breaks. Still whenever I run mkfs.btrfs’, I am warned btrfs' is experimental’, and I therefore think it irresponsible therefore to
adopt it as a default filing system for anything meaningful. I’ll start to take Btrfs for / seriously once SLES proposes
it by default.
The rest of the installation programme is virtually identical to S.u.S.E./SuSE/SUSE/openSUSE installers for the last 15
years: functional but uninspiring. At least the openSUSE developers should take notice of modern installers which ask
for things like the locale regionalisation, NTP configuration, and default user and root passwords while deploying the
kernel images and installing the packages onto the hard drive. This isn’t rocket science. And upon rebooting, the first
thing I see on console after GRUB2 is `vga??? is deprecated’, which doesn’t exactly inspire confidence in a newly
released operating system.
So upon logging into openSUSE_13.2_KDE, and changing the desktop to plain black, I remain disappointed that Kate isn’t
installed by default since it is much better than Kwrite or Kedit. The network was running perfectly, which suggested
that although the Wicked Service might not replace KDE’s Network Manager adequately, it seems a promising successor to
ifup. The inevitable `zypper up’ downloaded only 157 MB after a week from release, and mostly for GTK and KDE updates. I
then rebooted.
In attempt to get rid of the vga???? is deprecated' message, I opened YaST's bootloader configuration only for it to hang when I clicked on the Kernel Parameters’ tab. A second reboot corrected this and I was able to change VGA mode' to Unspecified’ to remove the deprecated' warning. The third reboot confirmed success in my attempt. I then proceeded to edit my repository add script "%s/13.1/13.2/gc", with only the pacman Essentials’ and `Multimedia’ URLs not found.
Installation of my usual suspects (e.g. vim-enhanced, gcc-c++, make, kernel-devel, cgdb, mutt, slrn, irssi, lynx, sc,
mpd, ncmpcpp, etc…) went perfectly, except for the now normal but nevertheless stupid >1000 packages for texlive…
And with baited breath I went into YaST’s software manager to install the fglrx64_amdcccle_SUSE132 package. I rebooted
and I was absolutely delighted to see that `fglrxinfo’ resulted in no error. Good riddance 13.1!
WORKSTATION
Hardware: Intel Xeon E5-2640-v3 X2 with Nvidia Quadro graphics card
Software: openSUSE_13.2_x86_64_KDE treble-boot (alongside Win7 and Gentoo)
OK. Not the right place for Windows. However, I have a Win7 partition in case the motherboard manufactorer (Asus)
releases BIOS updates only as Win64 executables (sadly Supermicro still haven’t heard of M.2 SSDs…). Also, I agree
openSUSE is not the ideal distribution for this hardware or indeed any binary GNU/Linux distribution, but I wanted to
have a standby in case I broke my primary distribution, Gentoo (easily done!). However, the saga of my frustrating
experience of getting openSUSE 13.2 onto this machine I think distils all the worst things about the openSUSE installer
(perhaps with the exception of the `Suggested partioning’ algorithm!).
Win7 and Gentoo were perfectly happy with UEFI boot so I booted the openSUSE install DVD in UEFI mode. The screen went
blank with a hard crash upon leaving the UEFI boot menu, with no option to change the kernel parameters (which I
understand is not straightforward in UEFI mode). There was not even a safe-boot' or recovery-boot’ option. Pressing
`e’ achieved nothing. So unless I’m missing something obvious, there’s no way for me to install openSUSE 13.2 directly
with UEFI boot without performing some sort of hack (which I had to do for Gentoo, but hacking in Gentoo is the expected
norm!).
So I booted the DVD in standard BIOS mode accepting I had no choice but a non-UEFI install of openSUSE 13.2.
Fortunately, GPT partitioning in openSUSE does not depend on UEFI. Of course, the standard BIOS DVD boot still resulted
in a hard crash. After disabling local APIC, I saw the console output, but again this proceeded to another hard crash
when the installer attempted to load X. So disabling local APIC and setting the kernel parameter nomodeset' finally allowed me to load the openSUSE installer. Apart from the same Btrfs subvolume nonsense I described the above, the rest of the installation proceeded perfectly well. Again, there were only modest updates on the first zypper up’ and softare
installed just fine (still no pacman repo). Curiously removing the kernel parameter `nolapic’ still resulted in a
crash-free boot from hard-drive.
The proprietary Nvidia graphics driver blob installed flawlessly and it combined with openSUSE’s KDE rendered a
beautiful desktop. Of course, it’s not very different to Gentoo’s KDE on this box, apart from the default wallpaper and
Geeko icon on taskbar. Overall, I’m relieved that I was able to install openSUSE 13.2 as a fallback OS on this machine,
even if I had to do so without UEFI boot.
OVERALL_IMPRESSIONS
There’s no question the openSUSE remains a strong and fantastic distribution. I have to admit that from my heart, I have
a squidgely soft spot for openSUSE since S.u.S.E. was my first ever GNU/Linux distribution back in the late 1990s. But
the release of 13.2 confirms my suspicions beyond doubt: it is not, and has never has been for GNU/Linux newcomers. It’s
also not particularly designed for console hackers (a la Arch) or source compilers (a la Gentoo). It’s a midway
desktop-multivalent open source distribution that offers Enterprise-level control at the click of the button (through
YaST) - a cutting-edge testing bed for SLED/SLES. While, tbere’s a lot to commend this approach, it comes with a number
of costs.
-
Complexity: the Btrfs subvolume nonsense must stop or at least not remain a default option. I’ve used GNU/Linux for
many years; admittedly, I only made the transition from GRUB Legacy to GRUB2 at the time openSUSE 12.3, and still remain
suspicious of Btrfs. One day I might even switch from Python 2.X to Python 3.X! But I’m sure most would agree that I’m
not being too conservative to suggest that the many Btrfs subvolume arrangement is wholly inappropriate default
`suggested partition’ proposal with at least some help/documentation/explanation for the poor installer! -
Precariousness: while it’s fine to assume a reasonably experienced GNU/Linux user will know to do things like disable
floppy controllers, disable UEFI boot, set no local APIC, and set nomodeset - if there are problems, it is without
question unreasonable to expect this of a GNU/Linux newcomer. There can be no greater demotivater or confidence-killer
than an OS installer DVD that crashes whenever it boots. I’m pleased to see that that the installer no longer tries to
boot from kexec after installation since this always hard-crashed for me and instead it wisely reboots. Since the kernel
is reloading anyway, there’s absolutely no need for the DVD kernel image to load with all bells and whistles. If the DVD
kernel image can’t load safely on every x86 GNU/Linux capable system, then set the default parameters so that it does! -
Lassitude: if openSUSE is trying to be everything to everyone occuping the mid-ground between
newbie' andguru’, it
may end up not being particularly attractive to anyone. With version 13.2, openSUSE’s installer is rubbish to GNU/Linux
newcomers while being patronising toexperts' at the same time. Upon booting KDE, there's little indication that you're inside openSUSE beyond the wallpaper and Geeko icon on the taskbar, not to mention the long-standing omission of kate. Beyond a Ruby recode, YaST hasn't particularly changed for the last dozen years, and there's still no YaST utility to browse packages listed within http://software.opensuse.org - which would be a clear no-brainer to appeal to those unfamiliar with openSUSE repositories. While the switch to systemd and Btrfs does show a progessive ethos among the developers, the positive effects remain largely confined to realm ofgeekdom’ rather than the real world. If this is
all the developers want, then they’re doing well. But I suspect their aspirations are a somewhat loftier, and they
should consider releasing an ISO with a DVD that reliably boots at the very least. But if the developers continue to
exercise lethargy in such `basics’, then openSUSE could only ever appeal to a niche and therefore somewhat limited
population.
But I’d like to finish on the positives:
-
Seemless upgrading: although non-Tumbleweed versions cannot be regarded as rolling releases, my faith in incremental
version upgrades in openSUSE remains as strong as it ever was. -
Graphics support: proprietary drivers for AMD and Nvidia worked from repositories on first attempt without having to
resort to any `hard way’ (i.e. direct blob installation). This is the first time I’ve experienced this on an openSUSE
release. -
GNU/Linux versions: I’ve had very good experiences with kernel 3.16.X and gcc 4.8.X, and was therefore very pleased
to see their inclusion in openSUSE 13.2. -
Post-install zypper updates: these were minimal, particularly when compared to openSUSE 12.3.
-
Wicked appears to be a worthy successor for ifup (albeit maybe not for wireless connections from a laptop).
The only real question is whether the developers have a focussed future for openSUSE, and if so, where? But overall, a
wonderful job: well done!