Language Selection

English French German Italian Portuguese Spanish

openSUSE 10.2 Beta 1 Report

Filed under
Reviews
SUSE
-s

As you know openSUSE released the first beta in the 10.2 developmental cycle on the 26th and tuxmachines has been checking it out in preparation for our report. This feature and version freeze release came with quite a few annoying bugs, but most didn't apply to my testing. I did encounter a coupla problems of my own and little or no new eye candy was found. But how did the system perform overall?

The installer was the same as we've grown accustomed to basically. This release the installer went back to full screen (at least here) and something happened to the fonts. They seemed very jagged and faded out in places. That was weird. The only new feature I picked up on was the new types of installs. LVM appeared previously, but this release I noticed EVMS is now available (although there seems to be some bugs with this option). Reiserfs was still the default filesystem and reiser4 was still not available. One of the most annoying bugs concerns the installation of Grub. It will overwrite your MBR no matter what you choose in the configuration and I've seen reports that it won't even write it correctly rendering your system unbootable. I avoided this issue by choosing not to install a bootloader at all (which is my normal method anyway). But if you're gonna test this release, I'd suggest having a livecd handy. Most of my hardware was detected properly although, as stated earlier, I did have some minor issues.

I had no problems with X, but I had some sound issues. System sounds worked fine in both KDE and Gnome, but the sound in any of the multimedia applications just was not happening. I didn't dig around and try to discover why at this point. I was delighted to see KdeTV working wonderfully in Beta 1, except for the 'no sound' issue. Hopefully this problem won't be present in the later betas/rcs.

I've seen reports of usb not working correctly with this beta, but I had no problems with the few usb devices I use. My usb devices consist of a scanner, printer, webcam, and a removable usbkey. I did have to run the configuration wizard for the printer (either during install or after) and the scanner (after install), but they did function properly afterwards. My usbkey is recognized upon insertion and a dialog box opens in KDE asking if I'd like it to be opened in a filebrowsing window, as it should and always has. In addition, a listing for it appears in My Computer as well as showing different specifications depending upon its mount status.

When I started Beta 1 for the first time, my network connection was not working. Going through the settings in yast, and even changing them and restarting the network didn't bring it up. I was able to bring it up manually at the commandline. In subsequent boots however, it was available as desired. I left the option to use traditional ifup enabled during install and then changed it to openSUSE's newer Network Manager when re-configuring after the problems. So, I'm not sure if their ifup has issues, but using their Network Manager seems to bring it up at boot.

There was a new icon in the system tray for Online Updates. It seemed to duplicate the same functionality as the older Software Update icon and applet, but this newer applet seems more integrated with the new Software Manager. Clicking on 'configure update source' brings up the yast source configuration. There were no updates at this time so we weren't able to perform any further testing. Online Update through yast still brings up the Software Manager with a Patches option in the Filter drop down menu.

The Software Manager seemed to be functioning well here as far as tested. After the initial system install, a few packages were selected and installed from the DVD without issue. The categories in the Pattern windowpane continue to be refined, although XFCE was noticeably absent. This release we find our Pattern categories to be:

  • Base Technologies

    • openSUSE Base System

    • Novell AppArmor
    • Console Tools
    • Laptop
    • YaST System Administration
    • ZENworks Linux Management
  • Graphical Environments
    • Gnome Desktop Environment

    • Gnome Base System
    • KDE Desktop Environment
    • KDE Base System
    • X Window System
    • Fonts
  • Desktop Functions
    • Graphics
    • Games
    • Remote Desktop
    • XML and LaTeX Editing Tools
  • Server Functions
    • File Server

    • Print Server
    • Misc. Server
    • Mail and News Server
    • Web and LAMP Server
    • Internet Gateway
    • DHCP and DNS Server
    • Directory Server (LDAP)
    • Xen Virtual Machine Host Server
  • Development
    • GNOME Development

    • KDE Development
    • RPM Build Environment
    • Basis Development
    • Integrated Development Environments
    • C/C++ Development
    • Linux Kernel Development
    • YaST Development
    • Perl Development
    • Python Development
    • QT 4 Development
    • Web Development
  • Proprietary Software
    • Java Environment

    • Misc. Proprietary Source Package

Most of the applications found in the menus opened and functioned as far as testing except the multimedia applications as previously stated. I could get no sound out of any of the music players or tv apps and the video players wouldn't play any of the commonly found video formats.

        

One of the 2D games complained it couldn't find any 3D support. I have an nvidia card and was using "nv" graphic drivers, so of course it was correct in stating none was present. However I still wondered why X-Moto that's described as a 2D Motocross Game wanted 3D support. If it requires 3D, perhaps the name description needs to be adjusted. If I were to run this install for much longer than a few days of testing, proprietary NVIDIA drivers would be installed.

Some of the version highlights this release include:

  • kernel-default-2.6.18.1-8

  • xorg-x11-7.2-6
  • kdebase3-3.5.5-23
  • gnome-desktop-2.16.1-11
  • qt3-3.3.7-2

  • gtk2-2.10.6-4
  • gcc-4.1.3-19
  • python-2.5-11
  • OpenOffice_org-2.0.4-17
  • MozillaFirefox-2.0-2
  • gimp-2.2.13
  • gaim-1.5.0-70
  • Full RPMList this release.

As stated, there didn't seem to be any new eye candy present, except the newer splash theme is finding its way into some of the applications. For example, The GIMP's new splash graphic. The pretty SUSE windec was missing this release. Instead we find Plastik set as default with no SUSE in the drop down choices at all. Does this mean openSUSE artists are working on and we might get a new SUSE windec in 10.2? As the wallpaper that has been in place the last several development releases isn't really too pretty, I'm thinking they are holding out and making us wait for the new 10.2 wallpaper as well. I bet it's going to match the new splash screens. ...maybe.

Mozilla Firefox appears to be the newly released version 2.0, although technically, it was a pre-release cvs version from Oct. 23. The new homepage of opensuse.org is a trendy looking list of available languages which leads one to a revamped Welcome Page.

        

Some changelog highlights include:

++++ MozillaFirefox:

- Update to current CVS version of 2.0.
- Use www.opensuse.org as default home page for now

++++ OpenOffice_org:

- fixed build with gcc (GCC) 4.1.2 20061018

++++ kerry:

- update to version 0.2 release candidate:
* support new Beagle backend for KNotes
* require a minimum of 3 chars for search

++++ php5:

- update to 5.2.0RC6

++++ beagle:

- Update to 0.2.11:
- Improves search time performance
- Adds KNotes backend
- Adds KAddressbook backend

++++ freetype2:

- disable the recent fixes of the byte code interpreter because
if breaks the rendering of "Luxi Mono"

++++ udev:

- new upstream release 103

++++ qt3:

- update to 3.3.7:
* include CVE-2006-4811 patch

++++ OpenOffice_org:

- updated ooo-build to version 2.0.4.1:

++++ manufacturer-PPDs:

- Updated PPDs from the following manufacturers
to the newest available from LinuxPrinting.org:
HP, OCE, Sharp, Kyocera, Ricoh-family (Ricoh, Gestetner,
Infotec, Lanier, NRG, Savin), Brother, Oki,
but Epson cannot be updated because of non-free license.
- Added Toshiba PPDs (under GPL with additional permission).

++++ xgl:

- Update for modular X.

++++ iptables:

- updated to version 1.3.6

++++ Full Changelog



The List of Most Annoying Bugs this release are:

  • Some significant performance problems on ATA-HD with ata_piix driver Bug #214909

  • On some new installations an error occured preparing a hard disk Bug #214682. The problems show up when either installing onto a disk without valid partition table or doing an installation involving EVMS devices. If the problem was caused by an disk without valid partition table restarting the installation is a easy workaround since the problems ouccur after partitioning and therefore second install will have a valid partition table on the disk. EVMS based installations will probably be not possible with beta1 at all, but we would nevertheless be interested in any bug reports if brave people try it anyway.
  • During installation you will be asked if you want to add additional installation sources. That will often fail and cause the installation routine to abort leaving you with an incomplete configured system. Workaround: don't agree to add additional sources. Bug 214886
  • zen-updater is not installed by default Bug #214877
  • kpowersave crashes directly Bug #214881
  • Major changes in the bluez-libs might lead to problems with connecting to Bluetooth-devices
  • Help Center Integration of the openSUSE Manuals is work in progress. There are issues with the desktop files Bug #213573
  • yelp segfaults Bug #210429
  • The product is not completly localised, localisation will be done for Beta2.
  • Grub installs in MBR no matter what is selected in YaST2-bootloader Bug #213256
  • YAST2 printer module crashes rebuilding the driver database Bug 214265

Well, that's about it this time. Seems most of the work was under the hood this time. Some things were broken, but some things from last time were fixed. Take a look at the changelog to see all the changes. There were too many bug fixes and version updates to count. Beta 2 is due out Thu, Nov 9; RC 1 is expected Thu, Nov 23; and final is scheduled for release Thu, Dec 7.

Report on Alpha 5.

SuSE 10.2

I've just alpha 5 and I must say:
It's great as any .2 version of SuSE
This one is the best since 8.2

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

More in Tux Machines

Red Hat's "DevOps" Hype Again and Analysis of last Night's Financial Results

OSS Leftovers

  • Deutsche Telekom and Aricent Create Open Source Edge Software Framework
    Deutsche Telekom and Aricent today announced the creation of an Open Source, Low Latency Edge Compute Platform available to operators, to enable them to develop and launch 5G mobile applications and services faster. The cost-effective Edge platform is built for software-defined data centers (SDDC) and is decentralized, to accelerate the deployment of ultra-low latency applications. The joint solution will include a software framework with key capabilities for developers, delivered as a platform-as-a-service (PaaS) and will incorporate cloud-native Multi-access edge computing (MEC) technologies.
  • A Deeper Look at Sigma Prime's Lighthouse: An Open-Source Ethereum 2.0 Client
  • Notable moments in Firefox for Android UA string history
  • Dweb: Creating Decentralized Organizations with Aragon
    With Aragon, developers can create new apps, such as voting mechanisms, that use smart contracts to leverage decentralized governance and allow peers to control resources like funds, membership, and code repos. Aragon is built on Ethereum, which is a blockchain for smart contracts. Smart contracts are software that is executed in a trust-less and transparent way, without having to rely on a third-party server or any single point of failure. Aragon is at the intersection of social, app platform, and blockchain.
  • LLVM 7.0.0 released
  • Parabola GNU/Linux-libre: Boot problems with Linux-libre 4.18 on older CPUs
    Due to a known bug in upstream Linux 4.18, users with older multi-core x86 CPUs (Core 2 Duo and earlier?) may not correctly boot up with linux-libre 4.18 when using the default clocksource.
  • Visual Schematic Diffs in KiCAD Help Find Changes
    In the high(er)-end world of EDA tools like OrCAD and Altium there is a tight integration between the version control system and the design tools, with the VCS is sold as a product to improve the design workflow. But KiCAD doesn’t try to force a version control system on the user so it doesn’t really make sense to bake VCS related tools in directly. You can manage changes in KiCAD projects with git but as [jean-noël] notes reading Git’s textual description of changed X/Y coordinates and paths to library files is much more useful for a computer than for a human. It basically sucks to use. What you really need is a diff tool that can show the user what changed between two versions instead of describe it. And that’s what plotgitsch provides.

LWN's Latest (Today Outside Paywall) Articles About the Kernel, Linux

  • Toward better handling of hardware vulnerabilities
    From the kernel development community's point of view, hardware vulnerabilities are not much different from the software variety: either way, there is a bug that must be fixed in software. But hardware vendors tend to take a different view of things. This divergence has been reflected in the response to vulnerabilities like Meltdown and Spectre which was seen by many as being severely mismanaged. A recent discussion on the Kernel Summit discussion list has shed some more light on how things went wrong, and what the development community would like to see happen when the next hardware vulnerability comes around. The definitive story of the response to Meltdown and Spectre has not yet been written, but a fair amount of information has shown up in bits and pieces. Intel was first notified of the problem in July 2017, but didn't get around to telling anybody in the the Linux community about it until the end of October. When that disclosure happened, Intel did not allow the community to work together to fix it; instead each distributor (or other vendor) was mostly left on its own and not allowed to talk to the others. Only at the end of December, right before the disclosure (and the year-end holidays), were members of the community allowed to talk to each other. The results of this approach were many, and few were good. The developers charged with responding to these problems were isolated and under heavy stress for two months; they still have not been adequately thanked for the effort they put in. Many important stakeholders, including distributions like Debian and the "tier-two" cloud providers, were not informed at all prior to the general disclosure and found themselves scrambling. Different distributors shipped different fixes, many of which had to be massively revised before entry into the mainline kernel. When the dust settled, there was a lot of anger left simmering in its wake.
  • Writing network flow dissectors in BPF
    Network packet headers contain a great deal of information, but the kernel often only needs a subset of that information to be able to perform filtering or associate any given packet with a flow. The piece of code that follows the different layers of packet encapsulation to find the important data is called a flow dissector. In current Linux kernels, the flow dissector is written in C. A patch set has been proposed recently to implement it in BPF with the clear goal of improving security, flexibility, and maybe even performance.
  • Coscheduling: simultaneous scheduling in control groups
    The kernel's CPU scheduler must, as its primary task, determine which process should be executing in each of a system's processors at any given time. Making an optimal decision involves juggling a number of factors, including the priority (and scheduling classes) of the runnable processes, NUMA locality, cache locality, latency minimization, control-group policies, power management, overall fairness, and more. One might think that throwing another variable into the mix — and a complex one at that — would not be something anybody would want to attempt. The recent coscheduling patch set from Jan Schönherr does exactly that, though, by introducing the concept of processes that should be run simultaneously. The core idea behind coscheduling is the marking of one or more control groups as containing processes that should be run together. If one process in a coscheduled group is running on a specific set of CPUs (more on that below), only processes from that group will be allowed to run on those CPUs. This rule holds even to the point of forcing some of the CPUs to go idle if the given control group lacks runnable processes, regardless of whether processes outside the group are runnable. Why might one want to do such a thing? Schönherr lists four motivations for this work, the first of which is virtualization. That may indeed be the primary motivation, given that Schönherr is posting from an Amazon address, and Amazon is rumored to be running a virtualized workload or two. A virtual machine usually contains multiple processes that interact with each other; these machines will run more efficiently (and with lower latencies) if those processes can run simultaneously. Coscheduling would ensure that all of a virtual machine's processes are run together, maximizing locality and minimizing the latencies of the interactions between them.
  • Machine learning and stable kernels
    There are ways to get fixes into the stable kernel trees, but they require humans to identify which patches should go there. Sasha Levin and Julia Lawall have taken a different approach: use machine learning to distinguish patches that fix bugs from others. That way, all bug-fix patches could potentially make their way into the stable kernels. Levin and Lawall gave a talk describing their work at the 2018 Open Source Summit North America in Vancouver, Canada. Levin began with a quick introduction to the stable tree and how patches get into it. When a developer fixes a bug in a patch they can add a "stable tag" to the commit or send a mail to the stable mailing list; Greg Kroah-Hartman will then pick up the fix, evaluate it, and add it to the stable tree. But that means that the stable tree is only getting the fixes that are pointed out to the stable maintainers. No one has time to check all of the commits to the kernel for bug fixes but, in an ideal world, all of the bug fixes would go into the stable kernels. Missing out on some fixes means that the stable trees will have more security vulnerabilities because the fixes often close those holes—even if the fixer doesn't realize it.
  • Trying to get STACKLEAK into the kernel
    The STACKLEAK kernel security feature has been in the works for quite some time now, but has not, as yet, made its way into the mainline. That is not for lack of trying, as Alexander Popov has posted 15 separate versions of the patch set since May 2017. He described STACKLEAK and its tortuous path toward the mainline in a talk [YouTube video] at the 2018 Linux Security Summit. STACKLEAK is "an awesome security feature" that was originally developed by The PaX Team as part of the PaX/grsecurity patches. The last public version of the patch set was released in April 2017 for the 4.9 kernel. Popov set himself on the goal of getting STACKLEAK into the kernel shortly after that; he thanked both his employer (Positive Technologies) and his family for giving him working and free time to push STACKLEAK. The first step was to extract STACKLEAK from the more than 200K lines of code in the grsecurity/PaX patch set. He then "carefully learned" about the patch and what it does "bit by bit". He followed the usual path: post the patch, get feedback, update the patch based on the feedback, and then post it again. He has posted 15 versions and "it is still in progress", he said.

PostgreSQL 11: something for everyone

PostgreSQL 11 had its third beta release on August 9; a fourth beta (or possibly a release candidate) is scheduled for mid-September. While the final release of the relational database-management system (currently slated for late September) will have something new for many users, its development cycle was notable for being a period when the community hit its stride in two strategic areas: partitioning and parallelism. Partitioning and parallelism are touchstones for major relational database systems. Proprietary database vendors manage to extract a premium from a minority of users by upselling features in these areas. While PostgreSQL has had some of these "high-tier" items for many years (e.g., CREATE INDEX CONCURRENTLY, advanced replication functionality), the upcoming release expands the number considerably. I may be biased as a PostgreSQL major contributor and committer, but it seems to me that the belief that community-run database system projects are not competitive with their proprietary cousins when it comes to scaling enterprise workloads has become just about untenable. Read more