Mint with a Dash of Cinnamon

Since switching to using Linux as my primary desktop, I’m always curious as to what options are available to me besides my default go-to distro of Ubuntu.
While Ubuntu 12.04 (the LTS version) is one of the best desktop operating systems I’ve ever used, I’ve grown less enchanted with each subsequent release since then. Part of it comes from some of the choices made by the Ubuntu team (such as the tight integration with Amazon) and I can work around most of those, but I’ve had numerous stability issues with Unity that didn’t really exist in the older releases.
When Debian wheezy came out, I decided to give it a shot as a desktop operating system. I’ve used Debian as a server O/S for over a decade, but the main thing that makes it great for servers, the cautious nature of changes and inherent stability, kind of suck for the desktop. I’ve discussed this with Eric, who is both a Debian user and a Debian committer, and his reply is to ask if you really need to have umpteen updates to firefox, etc. I can see his point, but if I’m using, say, Gnome, having access to the latest release can have a huge impact on the user experience.
-
- Login or register to post comments
Printer-friendly version
- 1966 reads
PDF version
More in Tux Machines
- Highlights
- Front Page
- Latest Headlines
- Archive
- Recent comments
- All-Time Popular Stories
- Hot Topics
- New Members
Events: Video Conferences, Code.gov, and LibreOffice
| GitLab Web IDE
|
Record Terminal Activity For Ubuntu 16.04 LTS Server
At times system administrators and developers need to use many, complex and lengthy commands in order to perform a critical task. Most of the users will copy those commands and output generated by those respective commands in a text file for review or future reference. Of course, “history” feature of the shell will help you in getting the list of commands used in the past but it won’t help in getting the output generated for those commands.
| Linux Kernel Maintainer Statistics
As part of preparing my last two talks at LCA on the kernel community, “Burning Down the Castle” and “Maintainers Don’t Scale”, I have looked into how the Kernel’s maintainer structure can be measured. One very interesting approach is looking at the pull request flows, for example done in the LWN article “How 4.4’s patches got to the mainline”. Note that in the linux kernel process, pull requests are only used to submit development from entire subsystems, not individual contributions. What I’m trying to work out here isn’t so much the overall patch flow, but focusing on how maintainers work, and how that’s different in different subsystems.
|
Recent comments
3 hours 55 min ago
3 hours 55 min ago
3 hours 57 min ago
7 hours 3 min ago
7 hours 15 min ago
14 hours 7 min ago
1 day 16 hours ago
1 day 17 hours ago
1 day 22 hours ago
2 days 23 hours ago