| DistroWatch Weekly
|DistroWatch Weekly, Issue 657, 18 April 2016
Welcome to this year's 16th issue of DistroWatch Weekly!
One of the more exciting aspects of the open source community is that there are always people trying something new. There is always a new design on the horizon, waiting to be tested and either adopted or discarded. This week we focus on new technologies that are currently available or will soon be ready to download. We begin with a look at Redox, a UNIX-like operating system written in Rust that includes some interesting design choices. In our News section we cover improvements to Linux Mint's update manager and changes planned for the next release of Fedora. Plus FreeNAS has decided to upgrade older versions of Samba following the Badlock bug and we discuss Canonical's plan to support Snappy packages in Ubuntu 16.04. In our Questions and Answers column we talk about menus and short-cuts in various desktop environments. Then we share the torrents we are seeding and explore last week's releases. In our Opinion Poll we raise the idea of voting for distributions on our waiting list. Plus we share a new resource where readers can find hardware that works with open source operating systems. We wish you all a wonderful week and happy reading!
Listen to the Podcast edition of this week's DistroWatch Weekly in OGG (22MB) and MP3 (30MB) formats
|Feature Story (by Jesse Smith)
An introduction to Redox
Back in March, a young operating system project attracted attention in the open source community. The project is called Redox and its developers are working on a Unix-like operating system written in the Rust language. The Redox operating system features a microkernel design (like MINIX), the permissive MIT license and some interesting design ideas.
While I read a lot of opinions in March about the developers and their design goals, I encountered very little commentary on what it was like to use the young operating system itself. This led me to become curious and download the project's small installation ISO which is just 26MB in size.
Before getting into my experiences with Redox, I want to talk briefly about some of the design decisions the developers have made. They seem to feel that Unix (or related operating systems like Linux distributions) has a generally good design, but with some key flaws or hangovers from past decades. For example, the project's documentation suggests that Unix's "Everything is a file" concept is dated and their modern design declares "Everything is a URL". In a way, this makes sense. On Linux, our hard drive is treated like a file under the /dev directory, so we can end up in some strange conceptual territory when we realize we are working in a directory on a device that is located in another directory. Redox's "Everything is a URL" philosophy works around such issues by giving users a way to access devices which are not part of the file system. Personally, I think the developers are trading one set of problems for another by using URLs, but I acknowledge they have highlighted an issue and provided a workaround.
The Redox project also takes the stance that the C programming language may produce fast running applications, but quite often security and stability issues can be traced back to quirks of the C language or common mistakes made by C programmers. Rust strives to be more secure and offers some protection against common implementation problems. By using Rust instead of the traditional C language in development the Redox programmers hope to make a more stable and more secure operating system.
Design aside, let's look at what happens when we boot from Redox's installation media. Booting from the Redox media takes about three seconds and brings us to a text console. We are presented with a message suggesting we run "redox-installer" to set up the operating system. A quick examination of the command line interface reveals that we are running a minimal shell and we have root access. Exploring a little further I found that the installation media actually runs a minimal Linux distribution. The usual /etc, /bin and /proc directories exist along with the BusyBox collection of Unix utilities. We have access to the vi editor and commands to browse directories, monitor system processes and read manual pages (though no documentation files exist on the system). In the background the installation media runs version 4.4.3 of the Linux kernel. The whole live environment uses approximately 10MB of memory, making it a surprisingly compact Linux implementation.
Of course I did not download the Redox ISO in order to play with Linux, I wanted to experience something new. I looked at the redox-installer file and discovered it is a simple, 12 line shell script. The script presents us with a list of local hard drives and asks on which one we wish to install Redox. The script then confirms our choice and, without further customization or prompts, uncompresses a file containing the Redox operating system and writes it to our hard drive using the dd command. Hopefully nothing of importance was on that hard drive.
I tried working with Redox in a VirtualBox virtual machine and on a physical desktop computer. In both instances, the Linux-based installation media booted, but the installed Redox operating system did not. For the time being, it seems Redox is not yet at a point where I can run it in any practical sense, though I have heard from another user who was able to get Redox installed in a virtual machine.
For those lucky folks who are able to get Redox running, the operating system is not yet at a point where development of Redox can be performed on Redox. Put another way, there are not yet enough tools and development utilities in place to work on Redox from within Redox. The operating system exists in more of a proof-of-concept stage than as a practical platform at this point.
When Redox first started getting attention on various open source forums, there were many negative voices criticizing the project. And, to a point, that is to be expected. If someone mentions on-line that they are enjoying a salad for lunch, by supper someone will have drawn a parallel to Hitler being a vegetarian. But sifting through the reactions to Redox I found that most of the critics seemed to be engaged in shooting the messenger.
From what I have read of their design plans, the Redox developers have correctly identified some problems with Unix, GNU/Linux and the BSDs. Some of their opinions on operating design I may not agree with, but I do believe they raise points worth considering and, in some cases, are correct in pointing out issues with existing operating systems which could be fixed. The Redox developers point out the C language, which is typically used for kernel development, has weaknesses when it comes to protecting memory and using variable types. Hardly a day goes by when I do not read a bug report that traces back to these same weaknesses, making it difficult to argue with the Redox developers. Rust, the Redox team claims, would avoid these common problems and they may be right. I do not think we are likely to see anyone try re-write the Linux kernel in Rust, but doing more to mitigate the dangers of using C to develop Linux should be considered.
Likewise, the Redox team points out that having a smaller kernel with drivers running outside of the core kernel makes the system safer and possibly more stable. I tend to agree and some projects, like MINIX, have done some remarkable things to help systems recover from faulty modules or to upgrade drivers in place without requiring a reboot.
My point is that the Redox team has come along and pointed out various issues with how our favourite operating systems are designed and developed. This makes some people defensive and leads to people lashing out against the new ideas presented. And I feel that reaction is not helpful. GNU/Linux and BSD systems are practical and widely used, but that does not make them perfect. Our established operating systems tend to carry with them a good deal of legacy concepts and potential weaknesses that come from being around for multiple decades. I am not saying we should throw them away and start over, that wouldn't be at all practical. But I am suggesting we consider if there are ways we might improve our existing systems.
Redox may never be a practical replacement for GNU/Linux distributions, but it might serve as a testing platform for ideas that could be adopted by other operating systems. The uutils project, for example, seeks to recreate the GNU core utilities in Rust to make them more portable and less prone to memory issues. While uutils may never replace the GNU programs, they might offer advantages or design ideas we can all benefit from. Let's not write off projects like Redox or uutils because they are different or trying to accomplish a task that has been done before. Their developers are testing ideas which we might all benefit from one day.
* * * * *
Hardware used in this review
My physical test equipment for this review was a desktop HP Pavilon p6 Series with the following specifications:
- Processor: Dual-core 2.8GHz AMD A4-3420 APU
- Storage: 500GB Hitachi hard drive
- Memory: 6GB of RAM
- Networking: Realtek RTL8111 wired network card
- Display: AMD Radeon HD 6410D video card
|Miscellaneous News (by Jesse Smith)
New features coming to Linux Mint, highlights of Fedora 24, FreeNAS bumps Samba version and Ubuntu 16.04 to support Snappy packages
In their monthly newsletter, the Linux Mint team discussed some of the new improvements coming to the Linux Mint distribution. One of the new key features offers better handling of kernels in the update manager. The update manager will also provide more information about software updates and how they relate to stability and regressions, allowing the user to select an update policy. "The Update Manager was already configurable, but it wasn't clear how to configure it, and why. In particular, the concepts of regressions, stability and security weren't clearly explained and users had to acquire these online. To raise awareness around these concepts and show more information, a new screen welcomes users to their update manager and asks them to select an update policy." Touchpad support has also been improved in the MATE and Cinnamon desktop environments.
* * * * *
The next version of Fedora is expected to launch in June of this year and the Red Hat-sponsored distribution has a number of important changes planned. The Marksei blog has a summary of important changes arriving with Fedora 24. Key features include all packages being built with the new GNU Compiler Collection (version 6), the Fedora Server edition will be 64-bit only and an Astronomy spin will be available. The blog reports systemd will be split into multiple packages and Fedora will ship with version 4.5 of the Linux kernel, with 4.6 available as an optional update. One of the bigger changes for developers will be the availability of Docker images: "Starting with version 24 a new service to build Docker Images will be available. This will enable to produce more than one base image to provide additional layered software (like Cockpit) and enable contributors to modify Dockerfiles from which Docker Images will be built. More can be found here."
* * * * *
Last week there was a lot of hype surrounding the Badlock vulnerability in Samba. Though some of the concern over the vulnerability was unwarranted, open source projects have been quick to update their Samba packages and push out updates. The FreeNAS project, when faced with backporting a complex fix, decided to take this opportunity to upgrade older installations of the Samba file sharing software. Jordan Hubbard commented, "Because of the complexity of the fixes to Samba and the difficulty in back-porting them to Samba 4.1, we also decided to upgrade all TrueNAS/FreeNAS 9.3 users to Samba 4.3.6 - a newer and more capable version of Samba that is already in use by FreeNAS 9.10 - at the same time. FreeNAS 9.10 users will only see a fix for Badlock, not a Samba upgrade as well."
* * * * *
Snappy packages, which were introduced as an experimental technology for Ubuntu last year, will be available to Ubuntu 16.04 users later this month. The new Snappy packages can be installed alongside traditional Deb packages on Ubuntu 16.04, allowing users to install more up to date software on their long term support release. "Snap packages enable developers to bring much newer versions of apps to Ubuntu 16.04 LTS. Newer versions of KDE, GNOME, browser or other desktop environment apps will usually build easily on older LTS releases, but the complexities of packaging and providing updates have prevented us from delivering them in the past. The security mechanisms in snap packages allow us to open up the platform for much faster iteration across all of our flavours as snap applications are isolated from the rest of the system. Users can install a snap without having to worry whether it will have an impact on their other apps or their system. Similarly, developers have a much better handle on the update cycle as they can decide to bundle specific versions of a library with their app. Transactional updates make deployments of snap packages more robust and reliable." Further details on Snappy packages and Ubuntu's Desktop edition can be found in this Insights post. A cheat sheet of Snappy package manager commands can be found on our Package Management page.
* * * * *
These and other news stories can be found on our Headlines page.
|Questions and Answers (by Jesse Smith)
Menus, short-cuts and accessibility
Hoping-for-a-more-accessible-desktop asks: Using my desktop computer, I often want to use the keyboard to cycle the focus (using Tab or Shift+Tab) and navigate menus (using Alt+[underlined letter in each menu item]). In their default configuration, many distros make this difficult. I'm not visually impaired, yet low contrast (or none at all) and one pixel thin rectangles (or none at all) make it hard to distinguish between focused and unfocused elements to see where the focus is. As far as I recall, even a high contrast theme failed to address this particular problem. Alt key short-cuts are sometimes missing, and sometimes not readily apparent.
I guess I can improve focus contrast by adjusting the values for border thickness and colour, but which lines exactly, in which file?
As for the Alt key neglecting problem, I do not know which software layer (i.e. individual application, window manager, desktop environment, distro etc.) is responsible for this, so I don't know which part I'd have to replace. Also, I wouldn't know which alternative is more supportive of menu navigation by Alt key. Any suggestions would be greatly appreciated.
DistroWatch answers: This is one of those questions that I thought I would spend about five minutes researching, find out what toggles the visibility of Alt key short-cuts and spend another five minutes writing out the solution. As it turned out, exploring this problem took a lot longer than I expected and the more I looked at it, the deeper the rabbit hole became.
In the desktop environments I tend to use most (Lumina and KDE), Alt short-cuts, window borders and selected GUI elements are all recognizable and easily accessible. This made me wonder just which systems were using lower contrast elements and not displaying Alt key short-cuts. So I grabbed a computer, installed the major desktop environments (Cinnamon, GNOME, KDE, Lumina, LXDE, MATE and Xfce) on it and tested each environment to see how each one presented its menus and selected elements.
At first it seemed as though menu Alt key short-cuts and highlighting contrast were a function of the desktop environment. Specifically, Qt-based desktops such as KDE and Lumina would show me high contrast GUI elements and display menu Alt key short-cuts. Meanwhile, the GTK-based desktops like Cinnamon and GNOME did not show these short-cuts and featured lower contrast elements. However, my initial hypothesis was proven false when I realized applications in Xfce and LXDE (both GTK-based environments) did display Alt short-cuts and made seeing selected items easy. I modified my working theory to suggest GTK2 and Qt desktops would, by default, draw the Alt short-cuts and display high contrast items while GTK3-based desktops would not.
Closer inspection revealed my premise to be wrong when I started to run GTK3-based software in Qt-based desktop environments. If I ran a GTK3 application in Qt-based desktop environments such as Lumina or KDE, then the application's menu items and Alt short-cuts would be displayed. And if I ran a Qt-based application in a modern GTK3 desktop, its elements would also be displayed in high contrast and its Alt short-cuts would be displayed. In fact, if I ran a GTK3 application in a GTK2 desktop environment, like Xfce or LXDE, then elements and short-cuts were also more accessible.
What this led me to is the idea that Alt keyboard short-cuts and low-contrast GUI elements appear to result from a combination of GTK3-based applications running in GTK3-based desktop environments. Running Qt-based (or GTK2-based) applications in any desktop environment usually (not always, but usually) caused the Alt short-cuts to be displayed and resulted in graphical elements that were easier to see and interact with.
Which raised the question of how to make Alt short-cuts, borders and highlighted elements more visible when working in pure GTK3 environments. One thing I noticed was when working with GTK3 applications, if I used the mouse to click on an application's menu, Alt short-cut keys were not displayed. However, if I held down the Alt key then the short-cuts became visible. This is not ideal as it requires we hold down the Alt key, but it works. I also found suggestions on various forums that said using either of the two following commands would make Alt key short-cuts permanently visible in GTK environments:
dconf write /org/gnome/desktop/interface/automatic-mnemonics false
And, for older versions of the GNOME desktop:
gsettings set org.gnome.desktop.interface automatic-mnemonics false
While some people reported success using the above commands, they did not work for me in my test environments.
I also found that the accessing menus of some modern GTK3 programs using my keyboard did not work as there appeared to be no short-cut key (at least none I could find) to open some of the menus. Some modern applications divide up their menus into separate, isolated entities just represented by icons. Some menus have Alt short-cuts while others, apparently, do not. I found this inconsistency quite frustrating and I was happy to leave such applications for better alternatives. So far as I have been able to find, there is no solution for this type of bad design.
In the end, I found there really is not much consistency in the design and behaviour of Linux desktop applications and there is a variety of behaviour depending on which desktop environment is in use. This makes finding a single solution, whether it is a theme or setting or configuration option, difficult. Some applications, especially those developed for GNOME Shell, appear to be very focused on mouse and touch interfaces, but largely ignore or hide short-cuts when accessed via a keyboard.
My suggestion is to experiment with different desktop environments and applications. For instance, use KDE or LXQt instead of GNOME if keyboard input and Alt short-cuts are important to you. Look into using VLC instead of Totem for playing video files if you like to keep your hands on the keyboard. Rather than trying to alter the behaviour of specific applications or desktops, the best solution is probably to find the tools designed with your preferences in mind.
As for things like contrast and the size of window and element borders, these can usually be adjusted by using different themes. Distributions typically offer multiple themes for each desktop environment and experimenting with the alternative desktop themes will probably fix the remaining issues, such as element contrast and borders.
* * * * *
Past Questions and Answers columns can be found in our Q&A Archive.
Bittorrent is a great way to transfer large files, particularly open source operating system images, from one place to another. Most bittorrent clients recover from dropped connections automatically, check the integrity of files and can re-download corrupted bits of data without starting a download over from scratch. These characteristics make bittorrent well suited for distributing open source operating systems, particularly to regions where Internet connections are slow or unstable.
Many Linux and BSD projects offer bittorrent as a download option, partly for the reasons listed above and partly because bittorrent's peer-to-peer nature takes some of the strain off the project's servers. However, some projects do not offer bittorrent as a download option. There can be several reasons for excluding bittorrent as an option. Some projects do not have enough time or volunteers, some may be restricted by their web host provider's terms of service. Whatever the reason, the lack of a bittorrent option puts more strain on a distribution's bandwidth and may prevent some people from downloading their preferred open source operating system.
With this in mind, DistroWatch plans to give back to the open source community by hosting and seeding bittorrent files. For now, we are hosting a small number of distribution torrents, listed below. The list of torrents offered will be updated each week and we invite readers to e-mail us with suggestions as to which distributions we should be hosting. When you message us, please place the word "Torrent" in the subject line, make sure to include a link to the ISO file you want us to seed. To help us maintain and grow this free service, please consider making a donation.
The table below provides a list of torrents we currently host. If you do not currently have a bittorrent client capable of handling the linked files, we suggest installing either the Transmission or KTorrent bittorrent clients.
Archives of our previously seeded torrents may be found here. All torrents we make available here are also listed on the very useful Linux Tracker website. Thanks to Linux Tracker we are able to share the following torrent statistics.
Torrent Corner statistics:
- Total torrents seeded: 184
- Total data uploaded: 34.5TB
|Released Last Week
Chris Buechler has announced the availability of pfSense 2.3. The new release of this FreeBSD-based firewall operating system includes a number of new changes to its web interface and fixes several bugs from previous releases. "We are happy to announce the release of pfSense® software version 2.3! The most significant changes in this release are a rewrite of the webGUI utilizing Bootstrap, and the underlying system, including the base system and kernel, being converted entirely to FreeBSD pkg. The pkg conversion enables us to update pieces of the system individually going forward, rather than the monolithic updates of the past. The webGUI rewrite brings a new responsive look and feel to pfSense requiring a minimum of resizing or scrolling on a wide range of devices from desktop to mobile phones. For the highlights, check out the Features and Highlights video. Past blog posts have covered some of the changes, such as the performance improvements from tryforward, and the webGUI update." Further information can be found on the project's Features and Changes page.
IPFire 2.19 Core 100
The IPFire project has released the 100th update to the project's 2.19 branch. The new version, IPFire 2.19 Core 100, introduces a 64-bit build along with an updated Linux kernel. "It is a great moment to us and we are very proud to release the 100th Core Update today. This update will bring you IPFire 2.19 which we release for 64-bit on Intel (x86_64) for the first time. This release was delayed by the various security vulnerabilities in OpenSSL and glibc, but is packed with many improvements under the hood and various bug fixes." A number of fixes have been backported to the project's Linux kernel: "As with all major releases, this one comes with an updated Linux kernel to fix bugs and improve hardware compatibility. Linux 3.14.65 with many backported drivers from Linux 4.2 is also hardened stronger against common attacks like stack buffer overflows. Many firmware blobs for wireless cards and other components have been updated just as the hardware database." Additional information can be found in the project's release announcement. Download (SHA1): ipfire-2.19.x86_64-full-core100.iso (159MB, torrent, pkglist)
* * * * *
Development, unannounced and minor bug-fix releases
|Upcoming Releases and Announcements
Summary of expected upcoming releases
Voting for distros on the waiting list?
We received a lot of distribution submissions with multiple new projects appearing in our inbox every month. While we try to evaluate each new distribution and move quality projects from our waiting list to the DistroWatch database in a timely manner, sometimes promising projects fall through the cracks. Other times a project might take time to mature, but then be forgotten and remain stuck on our waiting list.
Sometimes people will e-mails us to bring an up and coming distribution to our attention, other times we catch word of exciting distributions on forums. Unfortunately, there are times when projects slip by and remain in waiting list limbo.
This week we are putting forward the idea of allowing our readers to vote for distributions on our waiting list in order to bring promising projects to our attention. Do you think voting projects from the waiting list into our database would be a good way to get quality projects the attention they deserve? Or would a voting process be more likely to promote projects that have a vocal user base rather than quality features to share?
You can see the results of our previous poll on upstream vs downstream distributions here. All previous poll results can be found in our poll archives.
Voting for distros on the waiting list?
|I support voting for distros on the waiting list: ||492 (38%)|
| I prefer the current vetting process: ||398 (31%)|
| Either approach is fine: ||354 (28%)|
| I have an alternative idea to be shared in the comments: ||34 (3%)|
Locating compatible hardware
One of the more frequent questions we get asked is where a person can purchase computers that are known to work with Linux or BSD. There is a demand for laptops and desktop computers that are completely compatible with open source operating systems.
To aid people in their search for compatible computers and hardware components, we have created a page dedicated to providing links to companies which sell computers that are either compatible with Linux or which sell computers with Linux or BSD pre-installed. This page also links to hardware compatibility databases and resources where people can find hardware certified to work with Linux and BSD.
The organizations on our new Hardware Resources page are not affiliated with DistroWatch and we are not endorsing their products. The Hardware Resources page is intended to provide a starting point for people looking to purchase hardware that is compatible with free and open source operating systems.
The new Hardware Resources page can be located through our sitemap.
* * * * *
Distributions added to waiting list
- Debtailor. Debtailor is a distribution based Debian and Ubuntu which provides live images and runs without any network services enabled by default.
* * * * *
DistroWatch database summary
* * * * *
This concludes this week's issue of DistroWatch Weekly. The next instalment will be published on Monday, 25 April 2016. To contact the authors please send e-mail to:
- Jesse Smith (feedback, questions and suggestions: distribution reviews/submissions, questions and answers, tips and tricks)
- Ladislav Bodnar (feedback, questions, donations, comments)
- Bruce Patterson (podcast)
If you've enjoyed this week's issue of DistroWatch Weekly, please consider sending us a tip.
(Tips this week: 0, value: US$0.00)
|Linux Foundation Training
|• Issue 793 (2018-12-10): openSUSE Tumbleweed, finding non-free packages, Debian migrates to usrmerge, Hyperbola gets FSF approval|
|• Issue 792 (2018-1203): GhostBSD 18.10, when to use swap space, DragonFly BSD's wireless support, Fedora planning to pause development schedule|
|• Issue 791 (2018-11-26): Haiku R1 Beta1, default passwords on live media, Slax and Kodachi update their media, dual booting DragonFly BSD on EFI|
|• Issue 790 (2018-11-19): NetBSD 8.0, Bash tips and short-cuts, Fedora's networking benchmarked with FreeBSD, Ubuntu 18.04 to get ten years of support|
|• Issue 789 (2018-11-12): Fedora 29 Workstation and Silverblue, Haiku recovering from server outage, Fedora turns 15, Debian publishes updated media|
|• Issue 788 (2018-11-05): Clu Linux Live 6.0, examining RAM consumpion, finding support for older CPUs, more Steam support for running Windows games on Linux, update from Solus team|
|• Issue 787 (2018-10-29): Lubuntu 18.10, limiting application access to specific users, Haiku hardware compatibility list, IBM purchasing Red Hat|
|• Issue 786 (2018-10-22): elementary OS 5.0, why init keeps running, DragonFly BSD enables virtual machine memory resizing, KDE neon plans to drop older base|
|• Issue 785 (2018-10-15): Reborn OS 2018.09, Nitrux 1.0.15, swapping hard drives between computers, feren OS tries KDE spin, power savings coming to Linux|
|• Issue 784 (2018-10-08): Hamara 2.1, improving manual pages, UBports gets VoIP app, Fedora testing power saving feature|
|• Issue 783 (2018-10-01): Quirky 8.6, setting up dual booting with Ubuntu and FreeBSD, Lubuntu switching to LXQt, Mint works on performance improvements|
|• Issue 782 (2018-09-24): Bodhi Linux 5.0.0, Elive 3.0.0, Solus publishes ISO refresh, UBports invites feedback, Linux Torvalds plans temporary vacation|
|• Issue 781 (2018-09-17): Linux Mint 3 "Debian Edition", file systems for SSDs, MX makes installing Flatpaks easier, Arch team answers questions, Mageia reaches EOL|
|• Issue 780 (2018-09-10): Netrunner 2018.08 Rolling, Fedora improves language support, how to customize Kali Linux, finding the right video drivers|
|• Issue 779 (2018-09-03): Redcore 1806, keeping ISO downloads safe from tampering, Lubuntu makes Calamares more flexible, Ubuntu improves GNOME performance|
|• Issue 778 (2018-08-27): GuixSD 0.15.0, ReactOS 0.4.9, Steam supports Windows games on Linux, Haiku plans for beta, merging disk partitions|
|• Issue 777 (2018-08-20): YunoHost 188.8.131.52, limiting process resource usage, converting file systems on Fedora, Debian turns 25, Lubuntu migrating to Wayland|
|• Issue 776 (2018-08-13): NomadBSD 1.1, Maximum storage limits on Linux, openSUSE extends life for 42.3, updates to the Librem 5 phone interface|
|• Issue 775 (2018-08-06): Secure-K OS 18.5, Linux is about choice, Korora tests community spin, elementary OS hires developer, ReactOS boots on Btrfs|
|• Issue 774 (2018-07-30): Ubuntu MATE & Ubuntu Budgie 18.04, upgrading software from source, Lubuntu shifts focus, NetBSD changes support policy|
|• Issue 773 (2018-07-23): Peppermint OS 9, types of security used by different projects, Mint reacts to bugs in core packages, Slackware turns 25|
|• Issue 772 (2018-07-16): Hyperbola GNU/Linux-libre 0.2.4, UBports running desktop applications, OpenBSD auto-joins wi-fi networks, boot environments and zedenv|
|• Issue 771 (2018-07-09): Linux Lite 4.0, checking CPUs for bugs, configuring GRUB, Mint upgrade instructions, SUSE acquired by EQT|
|• Issue 770 (2018-07-02): Linux Mint 19, Solus polishes desktop experience, MintBox Mini 2, changes to Fedora's installer|
|• Issue 769 (2018-06-25): BunsenLabs Helium, counting Ubuntu users, UBports upgrading to 16.04, Fedora CoreOS, FreeBSD turns 25|
|• Issue 768 (2018-06-18): Devuan 2.0.0, using pkgsrc to manage software, the NOVA filesystem, OpenBSD handles successful cron output|
|• Issue 767 (2018-06-11): Android-x86 7.1-r1, transferring files over OpenSSH with pipes, LFS with Debian package management, Haiku ports LibreOffice|
|• Issue 766 (2018-06-04): openSUSE 15, overview of file system links, Manjaro updates Pamac, ReactOS builds itself, Bodhi closes forums|
|• Issue 765 (2018-05-28): Pop!_OS 18.04, gathering system information, Haiku unifying ARM builds, Solus resumes control of Budgie|
|• Issue 764 (2018-05-21): DragonFly BSD 5.2.0, Tails works on persistent packages, Ubuntu plans new features, finding services affected by an update|
|• Issue 763 (2018-05-14): Fedora 28, Debian compatibility coming to Chrome OS, malware found in some Snaps, Debian's many flavours|
|• Issue 762 (2018-05-07): TrueOS 18.03, live upgrading Raspbian, Mint plans future releases, HardenedBSD to switch back to OpenSSL|
|• Issue 761 (2018-04-30): Ubuntu 18.04, accessing ZFS snapshots, UBports to run on Librem 5 phones, Slackware makes PulseAudio optional|
|• Issue 760 (2018-04-23): Chakra 2017.10, using systemd to hide files, Netrunner's ARM edition, Debian 10 roadmap, Microsoft develops Linux-based OS|
|• Issue 759 (2018-04-16): Neptune 5.0, building containers with Red Hat, antiX introduces Sid edition, fixing filenames on the command line|
|• Issue 758 (2018-04-09): Sortix 1.0, openSUSE's Transactional Updates, Fedora phasing out Python 2, locating portable packages|
|• Issue 757 (2018-04-02): Gatter Linux 0.8, the UNIX and Linux System Administration Handbook, Red Hat turns 25, super long term support kernels|
|• Issue 756 (2018-03-26): NuTyX 10.0, Neptune supplies Debian users with Plasma 5.12, SolydXK on a Raspberry Pi, SysV init development|
|• Issue 755 (2018-03-19): Learning with ArchMerge and Linux Academy, Librem 5 runs Plasma Mobile, Cinnamon gets performance boost|
|• Issue 754 (2018-03-12): Reviewing Sabayon and Antergos, the growing Linux kernel, BSDs getting CPU bug fixes, Manjaro builds for ARM devices|
|• Issue 753 (2018-03-05): Enso OS 0.2, KDE Plasma 5.12 features, MX Linux prepares new features, interview with MidnightBSD's founder|
|• Issue 752 (2018-02-26): OviOS 2.31, performing off-line upgrades, elementary OS's new installer, UBports gets test devices, Redcore team improves security|
|• Issue 751 (2018-02-19): DietPi 6.1, testing KDE's Plasma Mobile, Nitrux packages AppImage in default install, Solus experiments with Wayland|
|• Issue 750 (2018-02-12): Solus 3, getting Deb packages upstream to Debian, NetBSD security update, elementary OS explores AppCentre changes|
|• Issue 749 (2018-02-05): Freespire 3 and Linspire 7.0, misunderstandings about Wayland, Xorg and Mir, Korora slows release schedule, Red Hat purchases CoreOS|
|• Issue 748 (2018-01-29): siduction 2018.1.0, SolydXK 32-bit editions, building an Ubuntu robot, desktop-friendly Debian options|
|• Issue 747 (2018-01-22): Ubuntu MATE 17.10, recovering open files, creating a new distribution, KDE focusing on Wayland features|
|• Issue 746 (2018-01-15): deepin 15.5, openSUSE's YaST improvements, new Ubuntu 17.10 media, details on Spectre and Meltdown bugs|
|• Issue 745 (2018-01-08): GhostBSD 11.1, Linspire and Freespire return, wide-spread CPU bugs patched, adding AppImage launchers to the application menu|
|• Issue 744 (2018-01-01): MX Linux 17, Ubuntu pulls media over BIOS bug, PureOS gets endorsed by the FSF, openSUSE plays with kernel boot splash screens|
|• Issue 743 (2017-12-18): Daphile 17.09, tools for rescuing files, Fedora Modular Server delayed, Sparky adds ARM support, Slax to better support wireless networking|
|• Issue 742 (2017-12-11): heads 0.3.1, improvements coming to Tails, Void tutorials, Ubuntu phasing out Python 2, manipulating images from the command line|
|• Full list of all issues|
|Random Distribution |
Southern California Internet Linux
SCI.Linux was a Linux distribution based on system administration through Webmin, best-in-class desktop applications, Microsoft Office compatibility, VPN connections to Windows, remote desktop to Windows XP, easy dual-boot with Win2K/XP/NT, multimedia applications for CD/DVD plus authoring utilities, spam blocker, complete set of high performance development tools, high performance video, extensive printer and sound card support, LaTeX, cluster software, and more. This distro was aimed at the student/researcher who wants to replace Windows and still interface to the Windows world. Requires a Pentium MMX or better, 256MB or more of RAM, at least 2.5GB of free disk space.