Language Selection

English French German Italian Portuguese Spanish

SUSE Linux 10.0 Beta 2 Report

Filed under
Reviews
SUSE
-s

The "Lizard Blizzard" continues as OpenSUSE released Beta 2 of the upcoming SUSE Linux a coupla days ago. So what's new in this release since the August 9th release of Beta 1?


Most of the changes appear to have taken place beneath the hood, updating software versions, squashing bugs, kernel patches and the like. But to the nekked eye, upon boot one notices the koffice icon on the desktop has been replaced by an OpenOffice.org icon. The late developemental version 1.9.123 of OOo is presently included with OpenSUSE. I've been running a pre-2.0 version of OOo for months on my gentoo install due to some bugs (or updated dependencies), and have found it to be very stable and much nicer looking. Novell lays claim to a "Novell Edition" on OpenSUSE. I didn't note anything special about it other than a nice start splash. If anyone knows, please feel free to respond.

Another addition to the desktop is a systray icon for Beagle. Clicking on that opens the Beagle search tool. I supposed that could be a handy feature. Speaking of the Beagle search utility, it now also has a systray icon in gnome as well. So, now Beagle opens each login not only in KDE but gnome as well. I'm sure this has got to be a bug, I hope so.

Also included is KAT. It's not installed by default, but I did note references to updating to version 0.6.2. I first became aware of this wonderful utility with the release of Mandriva's 2006 Beta 2. In subsequent communication with the author I found it to be much more comprehensive than Beagle and I hope OpenSUSE will consider using it as default as opposed to Beagle, especially if that feature of opening each and every login continues.

Oh man, speaking of logins, if one logs in, one must inevitably log back out. Another bug that reared it ugly head in Beta 2 is the total lock up of the system when logging out KDE, gnome, or icewm. This happens if you choose log out or reboot. How annoying. I had to hit reset 3 times in researching SUSE Linux for this article. Fortunately I chose the reiser filesystem and haven't lost data or my install yet.

Also new are many more modules in yast. Many deal with more options for networking and more hardware configurations. I thought I'd test out installing and configuring Zen. It made it through the extensive install, however, all of yast crashed and burnt when it was time to do the configuring and finish the install.

So, all in all, I found that Beta 2 introduced several new bugs and a few new features. An old friend at Mandrake once told me that sometimes the more bugs you squash, the more you make. ...Meaning that sometimes you fix one bug and it introduces two more. He said that's why sometimes you have to choose to release even though you know there are some bugs as they might be preferrable to the ones you make when you fix the first ones.

Some highlights in the 6 mb ChangeLog include:

  • ifolder3:

    • changed prefix to /usr/lib/ifolder3 [#104474]
  • installation-images:
    • fixed /etc permissions (#104715)
  • nmap:
    • Don't strip binaries
  • yast2
    • Lots of typo fixes, and bug fixes
  • OpenOffice_org:
    • fixed some potentially dangerous warnings

    • fixed to build portaudio with RPM_OPT_FLAGS
    • updated branding for 10.0 [#102355]
  • hotplug:
    • removed also desktop templates

    • removed all files except hotplug.functions and desktop templates
      package will be dropped completely in next beta
  • hwinfo:
    • added hdtv cards (#102933)

    • find input device udi (#102575)
    • fixed usb device udi matching (#102575)
    • read modules.alias, not modules.pcimap
    • updated X11 data
  • initial:
    • minor string format changes to ease the translators' work

    • updated po/{de,fr}.po
    • added po/{cs,hu,nb,pa,pt}.po
  • installation-images:
    • added sfdisk
  • kernel-source:
    • update to 2.6.13-rc6-git7

    • config.conf: Enable Xen build.
    • series.conf: Re-activated ntfs-subfs
  • Lots and lots of application version updates
  • Way too much to list here

I've carved down the changelog to only include since the last beta release and posted it here.

I've posted the License.txt here, as some expressed interest in it. Glancing over it, I'm not sure it's exactly the same one as in the installer, but this is the readable version on the install isos.

I've posted a complete list of rpms included as tested here if you wanted to check on the progress of your favorite app.

I've posted some screenshots of some of the new features here.

For a more complete report of the goodies in SUSE Linux by OpenSUSE, consult my previous report.

re: better experience

Oh wonderful! Good news. Thanks for your input. Smile

----
You talk the talk, but do you waddle the waddle?

Comment viewing options

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

More in Tux Machines

Games: Newer Windows Games On Wine, Steam on Chrome OS and Soldat's Source Code

  • A New Kernel Patch Is Being Discussed That's Needed For Newer Windows Games On Wine

    Newer Windows games/applications are making use of system call instructions from the application code without resorting to the WinAPI and that is breaking Wine emulation support. A Linux kernel patch is now being worked on for addressing this issue in the form of system call isolation based on memory areas while having a smaller performance hit than alternatives. With newer Windows software executing system call instructions without going through the Windows API, Wine isn't able to intercept and emulate those system calls and thus breaking the support. Wine can't really rework its handling of every system call as that would thrash the performance. So a Linux kernel-based solution is being sorted out.

  • Cloud FTW: Steam on Chrome OS may not look like we thought

    Back in January, word got out that Google and Valve were collaborating to bring some form of native Steam client to Chrome OS. Director of Product Management Kan Liu told Android Police that the project would leverage Crostini, aka Linux on Chrome OS. Because I spend a good portion of my days tinkering with Linux on my Chromebook, I hastily presumed that Steam would be delivered in some sort of Chrome OS-optimized Linux package. While that could still be a possibility, it appears that Valve may look to the Clouds in Steam’s next evolution.

  • Soldat source code released and a story of how it all started

KDE Development: Adriaan de Groot and New GSoC Students

  • Timezones, yes please

    One of the bits of Calamares that I think is most terrible is the timezone selector. So I was very happy to read Volker’s ideas about timezone-mapping. Calamares is a universal Linux installer, used by some dozens of Linux distro’s. It is built as a framework, customizable by downstreams to their liking. This is basically a service to the small-distro Linux community, and PRs are very welcome .. but I digress. Part of installation is picking a timezone to put the system in. Calamares offers a map, and you click on it, and it picks a likely location, and off you go. The technology used is simple: there’s a PNG for each timezone (this sounds familiar). The user clicks on the PNG of the world map, and the mouse coordinates are mapped to a location (longitude and latitude), the location is mapped to a zone offset that gets mapped to a timezone image, and the image is drawn.

  • The Community Bonding Period Ends

    It has been almost a month, since the commencement of community bonding period and the phase was mostly good. I spent most of my time lurking over the IRC in passive reconnaissance mode, force of habit I mostly speak less and I know it is not a good one especially being part of an open-source community. I used to attend all the meetings and tried to get accustomed with the workflow of the community and got to know about everything hot and spicy that is taking place whether it is Krita finally on android or new contributors working on some bugs.

  • KDE Conference India 2020: A very late post

    KDE India Conference 2020 was successfully organized in Maharaja Agrasen Institute of Technology. It was a three-day event, from Jan 17 to Jan 19. There were talks about Libre, Open Source Software and how software is developed using C++ and the Qt Framework. Hands-on workshops were also organized on C++, Qt and QML which gave attendees a good start on how to start their journey with C++ and Qt Framework. The conference was able to educate 200+ attendees throughout the conference. Refreshments were provided to all present for the conference on all 3 days. Every day of the conference concluded with dinner at various good places in Delhi with all the speakers, organizers and volunteers.

  • About me, who am I?

    I am Shubham, a final year undergraduate student, pursuing B.E(Bachelor of Engineering) at BMS Institute of Technology and Management, Bangalore, India. I am an open source enthusiast and developer, mostly working with C++ with Qt framework. I also have decent knowledge of C, Java, Python, bash scripting, git and I love developing under linux environment. Previously I was selected as one of many GSoC students to be mentored by this amazing organization, which is KDE. This year also, I applied again to KDE as a student and was fortunate enough to get selected. I will be developing for Cantor project. Apart from coding, in my spare time I go for Cricket or Volleyball to keep myself refreshed.

  • Integrated Documentation in Cantor

    Cantor is an application that lets user use their favourite mathematicalapplications from within a nicely KDE-integrated worksheet interface. It offers assistant dialogs for common tasks and allows users to share their worksheets withothers. Cantor is one of many KDE educational projects. It supports a variety of backends, be it Maxima, Octave, Python, R and many more and that too packed in a single intuitive GUI. The current version of Cantor does not have support for viewing backend's documentation inside the application itself. For example, to view Maxima’s documentation or help, the application provides an external link pointing to the Maxima’s official documentation page which is opened in a fresh browser window. This has the obvious drawback of requiring an active internet connectivity.

The Linux Kernel Deprecates The 80 Character Line Coding Style

The Linux kernel has officially deprecated its coding style that the length of lines of code comply with 80 columns as the "strong preferred limit". The Linux kernel like many long-standing open-source projects has a coding style guideline that lines of code be 80 columns or less, but now that while still recommended is no longer going to be as enforced. This stems from Linus Torvalds commenting on Friday that excessive linebreaks are bad and is against ugly wrapped code that is strictly sticking to 80 characters per line. This is part of the broader trend that most are no longer using 80x25 terminals but with today's high resolution displays the terminal sizes are often larger though some preferring the default in order to allow more terminals to be displayed simultaneously on their nice displays. Read more Original from Torvalds:

  • clean up kernel_{read,write} & friends v2
    Not necessarily.
    
    Excessive line breaks are BAD. They cause real and every-day problems.
    
    They cause problems for things like "grep" both in the patterns and in
    the output, since grep (and a lot of other very basic unix utilities)
    is fundamentally line-based.
    
    So the fact is, many of us have long long since skipped the whole
    "80-column terminal" model, for the same reason that we have many more
    lines than 25 lines visible at a time.
    
    And honestly, I don't want to see patches that make the kernel reading
    experience worse for me and likely for the vast majority of people,
    based on the argument that some odd people have small terminal
    windows.
    
    If you or Christoph have 80 character lines, you'll get possibly ugly
    wrapped output. Tough. That's _your_ choice. Your hardware limitations
    shouldn't be a pain for the rest of us.
    
    Longer lines are fundamentally useful. My monitor is not only a lot
    wider than it is tall, my fonts are universally narrower than they are
    tall. Long lines are natural.
    
    When I tile my terminal windows on my display, I can have 6 terminals
    visible at one time, and that's because I have them three wide. And I
    could still fit 80% of a fourth one side-by-side.
    
    And guess what? That's with my default "100x50" terminal window (go to
    your gnome terminal settings, you'll find that the 80x25 thing is just
    an initial default that you can change), not with some 80x25 one. And
    that's with a font that has anti-aliasing and isn't some pixelated
    mess.
    
    And most of my terminals actually end up being dragged wider and
    taller than that. I checked, and my main one is 142x76 characters
    right now, because it turns out that wider (and taller) terminals are
    useful not just for source code.
    
    Have you looked at "ps ax" output lately? Or used "top"? Or done "git
    diff --stat" or any number of things where it turns out that 80x25 is
    really really limiting, and is simply NO LONGER RELEVANT to most of
    us.
    
    So no. I do not care about somebody with a 80x25 terminal window
    getting line wrapping.
    
    For exactly the same reason I find it completely irrelevant if
    somebody says that their kernel compile takes 10 hours because they
    are doing kernel development on a Raspberry PI with 4GB of RAM.
    
    People with restrictive hardware shouldn't make it more inconvenient
    for people who have better resources. Yes, we'll accommodate things to
    within reasonable limits. But no, 80-column terminals in 2020 isn't
    "reasonable" any more as far as I'm concerned. People commonly used
    132-column terminals even back in the 80's, for chrissake, don't try
    to make 80 columns some immovable standard.
    
    If you choose to use a 80-column terminal, you can live with the line
    wrapping. It's just that simple.
    
    And longer lines are simply useful. Part of that is that we aren't
    programming in the 80's any more, and our source code is fundamentally
    wider as a result.
    
    Yes, local iteration variables are still called 'i', because more
    context just isn't helpful for some anonymous counter. Being concise
    is still a good thing, and overly verbose names are not inherently
    better.
    
    But still - it's entirely reasonable to have variable names that are
    10-15 characters and it makes the code more legible. Writing things
    out instead of using abbreviations etc.
    
    And yes, we do use wide tabs, because that makes indentation something
    you can visually see in the structure at a glance and on a
    whole-function basis, rather than something you have to try to
    visually "line up" things for or count spaces.
    
    So we have lots of fairly fundamental issues that fairly easily make
    for longer lines in many circumstances.
    
    And yes, we do line breaks at some point. But there really isn't any
    reason to make that point be 80 columns any more.
    
                      Linus
    

today's howtos