diff options
Diffstat (limited to 'RELEASE_NOTES')
| -rw-r--r-- | RELEASE_NOTES | 106 |
1 files changed, 70 insertions, 36 deletions
diff --git a/RELEASE_NOTES b/RELEASE_NOTES index 99059a67..ef1aad34 100644 --- a/RELEASE_NOTES +++ b/RELEASE_NOTES @@ -1,5 +1,5 @@ -Slackware 14.0 release notes. Wed Sep 19 21:47:07 UTC 2012 +Slackware 14.1 release notes. Mon Nov 4 16:09:25 UTC 2013 Hi folks, @@ -7,32 +7,55 @@ Hi folks, information, but once again Robby Workman has covered the important technical details in CHANGES_AND_HINTS.TXT. Thanks! - Linux has finally moved past 2.6.x versions (yay!) and already -has several different maintained 3.x branches. After extensive -testing, we chose to ship this release with a kernel from the 3.2 -branch (3.2.29), which Ben Hutchings says will be maintained on -kernel.org for an indefinite amount of time (probably at least 2 more -years), making it a good choice for a production release. As usual, -the kernel is provided in two flavors, generic and huge. The huge -kernel contains enough built-in drivers that in most cases an initrd -is not needed to boot the system. The generic kernels require the -use of an initrd to load the kernel modules needed to mount the root -filesystem. Using a generic kernel will save some memory and possibly -avoid a few boot time warnings. On the 32-bit side of things, there -are both SMP (multiple processor capable) and non-SMP (single -processor) kernels. The non-SMP kernel is mostly intended for machines -that can't run the SMP kernel, which is anything older than a Pentium -III, and some models of the Pentium M that don't support PAE. On -32-bit, it is highly recommended to use the SMP kernel if your machine -is able to boot with it (even if you have only a single core) because -the optimization and memory handling options should yield better -performance. - - If you'd like to try out some of the newer kernel branches, you'll -find .config files for Linux 3.4.11, 3.5.4, and 3.6-rc4 in the -/testing/source/ directory. - - Slackware 14.0 contains updated versions of both KDE and Xfce, and + After jumping ahead through various Linux kernel branches over +the course of this development cycle, we ended up on the 3.10.x +branch and decided to stick with it. Greg Kroah-Hartman's +announcement back in August that the 3.10 series would be getting +a long-term support for two years helped to cement this decision +and should be good news for anyone wanting to keep a maintained +stable kernel on their system. As usual, the kernel is provided in +two flavors, generic and huge. The huge kernel contains enough built-in +drivers that in most cases an initrd is not needed to boot the system. +The generic kernels require the use of an initrd to load the kernel +modules needed to mount the root filesystem. Using a generic kernel +will save some memory and possibly avoid a few boot time warnings. +On the 32-bit side of things, there are both SMP (multiple processor +capable) and non-SMP (single processor) kernels. The non-SMP kernel +is mostly intended for machines that can't run the SMP kernel, which +is anything older than a Pentium III, and some models of the Pentium M +that don't support PAE. On 32-bit, it is highly recommended to use the +SMP kernel if your machine is able to boot with it (even if you have +only a single core) because the optimization and memory handling +options should yield better performance. + + If you'd like to try out the latest kernel branch, you'll find +.config files for Linux 3.12 in the /testing/source/ directory. There +are also .config files for Linux 3.4.66 (the previous long-term support +kernel series) which might be useful for anyone wanting to drop back +to a 3.4.x kernel, but I doubt there will be many people who will want +to do this. The 3.10.x kernels have been stable and working well for +many releases now. + + One of the big changes in Slackware 14.1 is support for systems +running UEFI firmware (x86_64 Slackware edition only). We've added +several new packages for UEFI, including elilo, GRUB 2, and efibootmgr, +and all of the installation media supports booting under UEFI, as do +the USB boot sticks generated during installation. At this point +there is no support for running the system under Secure Boot, but a +dedicated user could add their own Machine Owner Key, sign their +kernels, modules, and bootloader, and then use shim to start the +bootloader. We'll be looking into adding support for this in the +next development cycle. Documentation for installing on UEFI machines +is provided in a README_UEFI.TXT found in the top-level Slackware +directory. + + Slackware ISO images (both the ones available online as well as +the discs sent out from the Slackware store) have been processed using +isohybrid. This allows them to be written to a USB stick, which can +then be booted and used as the install source. This works on machines +running both regular BIOS as well as UEFI. + + Slackware 14.1 contains updated versions of both KDE and Xfce, and both of these have been split as much as possible into their component packages rather than larger bundles. This not only makes it easier to remove software that you don't need, but also makes it easier to @@ -41,6 +64,15 @@ easier to issue a patch for only the affected item. This saves storage space on the archive sites, and your time and bandwidth downloading the updates. + Although Slackware does not ship the GNOME desktop, we can recommend +a couple of places to look if you're interested in trying to add it to +your system. The Dropline project ( http://www.droplinegnome.net ) has +put together a set of packages for running GNOME 3.x on Slackware. +There's also the MATE desktop, which is a fork of GNOME 2.x. SlackBuild +scripts are available to compile MATE packages for Slackware from +http://mateslackbuilds.github.io - thanks to Chess Griffin and +Willy Sudiarto Raharjo for making this option available. + Need more build scripts? Something that you wanted wasn't included in Slackware? Well, then check out slackbuilds.org. Several of the team members work on the scripts there. @@ -60,19 +92,21 @@ work with the team at slackbuilds.org, and lots of package upgrades, Piter Punk for slackpkg work, Stuart Winter for more updates to linuxdoc-tools, slacktrack, and for all kinds of fixes throughout the installer and system (he finds my bugs all the time while porting packages -to ARM for the Slackware ARM port: http://www.armedslack.org/), Mark Post -for his assistance porting our website to a newer PHP, Vincent Batts for -keeping Ruby working well and other miscellaneous fixes, Heinz Wiesinger -for working on PHP, mysql, icu4c, LLVM, and lots of other stuff, -Amritpal Bath for various bugfixes and helping with release torrents, -mrgoblin for testing RAID, bluetooth, and well, everything (and fixing a -lot of it, too), other very honorable mentions go to Alan Hicks, -Erik Jan Tromp, Karl Magnus Kolstø, Fred Emmott, and NetrixTardis, +to ARM for the Slackware ARM port: http://www.armedslack.org/), Vincent +Batts for keeping Ruby working well, for helping kickstart our +transition to MariaDB, and other miscellaneous fixes, Heinz Wiesinger +for working on PHP, MariaDB (especially!), icu4c, LLVM, and lots of other +stuff, Amritpal Bath for various bugfixes and helping with release torrents, +mrgoblin for testing RAID, bluetooth, and being a master of regex, and to +mancha for patching many packages to handle the changed crypt() function +in glibc-2.17+ (and for backporting many security fixes over the course +of the development cycle). Other very honorable mentions go to Alan Hicks, +Erik Jan Tromp, Karl Magnus Kolstø, Mark Post, Fred Emmott, and NetrixTardis, and anyone else I'm forgetting (including the other team members who contributed little fixes and suggestions here and there along with general moral support). Special thanks to the folks who mailed in bug reports (and fixes) and helped collaborate on this release. This was -a stellar release cycle for community participation, especially on the +another great release cycle for community participation, especially on the LinuxQuestions.org Slackware forum. Thanks for the help, for keeping this project fun, and making it possible for us to keep up with the rapid pace of Linux development. Thanks to Honeypi and Doodle, too! |