 DistroWatch Weekly |
| DistroWatch Weekly, Issue 470, 20 August 2012 |
|
Welcome to this year's 34th issue of DistroWatch Weekly! Browsing the Internet while preserving one's privacy and anonymity is becoming increasingly hard in today's online world. Luckily, with Linux and free software there are still some options that allow users to stay incognito in hostile environments. One of the projects providing an easy live CD with extensive privacy protection features is the Gentoo-based Liberté Linux; Jesse Smith takes a first look at the distribution's latest release in this week's feature article. In the news section, Arch Linux developers battle with resistance to change after switching to systemd, Damn Small Linux announces return to active development after four years of dormancy, NetBSD introduces automated system rebuilds and package upgrades, and Debian GNU/Linux celebrates its 19th birthday. Also in this week's issue, a look at the current situation in the trouble Mandriva Linux project and an update on Secure Boot from BSD's perspective. Finally, we introduce Saluki Linux, a Puppy-based distribution featuring the Xfce desktop. Happy reading!
Content:
 Join us at irc.freenode.net #distrowatch
|
| Feature Story (by Jesse Smith) |
Liberté Linux - a secure way to communicate?
 The Internet can be a scary place sometimes. It's full of people of questionable taste, extremists, spies and people who use proprietary operating systems. When faced with such a dangerous mix of humanity it seems reasonable that we might want to keep our communications private. Privacy on the Internet generally involves three things:
- Hiding what we are saying
- Hiding to whom we are talking
- Avoiding application finger prints, such as browser identities and cookies.
With these thoughts in mind there are some Linux distributions out there which attempt to keep what we say and do on-line private, not always an easy task as the Internet was designed with the sharing of information in mind, not hiding it. Still, some projects take on the task, one of them being Liberté Linux. The Liberté distribution was released "with the primary purpose of enabling anyone to communicate safely and covertly in hostile environments. Whether you are a privacy advocate, a dissident, or a sleeper agent, you are equally likely to find Liberté Linux useful as a mission-critical communication aid." Liberté Linux 2012.2 comes in three editions: a compressed binary image, a virtual machine image and a live CD image. I opted to try the live CD which is 208 MB in size.
Some of Liberté's advertised features include a hardened Linux kernel for added security, Internet access performed almost entirely through Tor and the use of encryption. Further, Liberté claims to use randomized MAC addresses and uniform HTTP headers to make requests harder to identify and fingerprint. While I was browsing the Liberté website I noticed I kept getting warning messages that the site was identified with an improper security certificate. Admittedly this was not a great first impression, both from a usability and from a security standpoint, but I still held high hopes for the distribution.
Liberté Linux 2012.2 - website and project summary
(full image size: 121kB, screen resolution 798x602 pixels)
When we first boot off the live CD we're shown a menu which allows us to select between loading Liberté Linux in its regular desktop mode and booting into a safe graphics mode. We can also launch a hardware detection tool which may be useful if we're unsure what sort of equipment we are using. Taking the default choice brings us to a LXDE desktop, though booting may take a few minutes as the entire Liberté disc is loaded into RAM, assuming enough memory is available. While this makes for a slow start, it does mean the distribution is very responsive once it has finished loading. From a performance standpoint it is just like running a locally installed operating system. The graphical interface we're given (LXDE running on top of Openbox) is laid out in the traditional fashion. At the bottom of the display we find the application menu, the task switcher and the system tray. We're set up with three virtual workspaces that are decorated with a background featuring a shadowy government man and the wallpaper instantly brought to mind old episodes of the X-Files.
While playing with Liberté Linux I ran the distribution on physical hardware and in a virtual machine and I found, when running in the virtual environment, Liberté would detect it was not running on real hardware and display a message saying so on the desktop. This lets users know they might not be as in control of their machine as they might think. When I ran Liberté on physical hardware, my HP laptop with a dual-core 2 GHz CPU, 4 GB of RAM and Intel cards for video and wireless, I found things worked smoothly. The distribution picked up local wireless networks, sound was turned down while still being available, the interface was responsive and LXDE stays out of the way. In fact, the light desktop environment is sparse enough that it can run using only 100MB of memory. My screen was set to a reasonable resolution, leaving me with only one glitch: my trackpad mouse was all over the place. Sometimes the mouse moved too much, sometimes not enough and often times any mouse movement would transfer me to another workspace making navigating the interface difficult with the pointer.
Peering through the application menu we find a small collection of useful utilities. There's the Claws e-mail client, the Epiphany web browser, the Pidgin messenger client, the XChat IRC client and the gFTP file transfer app. We also find software for handling documents including AbiWord, Gnumeric, an e-book reader and a PDF document viewer. The Totem movie player is available along with an archive manager, text editor and calculator. There's a virtual keyboard and the GNU Privacy Assistant is available for security key management. There is also a custom application called Cables which is supposed to allow users to transfer secure messages using an e-mail client interface. To help us connect to the Internet we're provided with Network Manager. Attempting to play multimedia files revealed that codecs for popular media formats are provided for us. Flash is not included, but users should be able to see on-line videos using HTML5. In the background version 3.2 of the Linux kernel keeps things running for us. The kernel is a special build which borrows from Gentoo's hardened kernel project. I also noticed no manual pages are installed on the distribution, leaving users to fend for themselves.
When we first connect to a network the Tor software comes into play, connecting us to the anonymizing network nodes and our wireless network card is assigned a random MAC address. It is possible to randomize Ethernet cards too, but it is not done automatically and I found when attempting to do so my connection would be dropped and I would have to manually re-connect using Network Manager. A moment ago I mentioned Liberté comes with the Epiphany web browser and, in fact, there are two menu entries for it. One entry is the "unsafe" version of the browser which connects directly to the local network. This option is provided to make sure we can authenticate against local equipment. However, once we are on-line and we are hooked into the Tor network this "unsafe" browser no longer works and all web browsing must be performed using the regular, Tor-enabled version of Epiphany. Browsing the web over the Tor network trades performance for some level of privacy. Thus using Epiphany tends to be a touch on the slow side, but it works well and I ran into no problems using the browser.
I did, however, encounter a few problems when trying to use other pieces of software in Liberté's arsenal. When attempting to use either Pidgin or XChat I could not get the applications to connect to chat networks. I also found that using Cables for secure communications requires the software be installed on a writeable medium and it will not work from the live CD. Lastly, the distribution does not provide a way to add new software to the distribution, even temporarily as many live CDs do, and this somewhat limits what can be done with it. For example, if I want to take screen shots or scan network ports or acquire different encryption software, then I'm out of luck with Liberté.
Liberté Linux 2012.2 - warnings and restrictions on the live CD
(full image size: 76kB, screen resolution 806x601 pixels)
There are several aspects of Liberté Linux I like. The hardened kernel, for example, the hardware support and having Tor enabled from the start. Randomizing MAC addresses for wireless cards is a nice touch too. All of these characteristics point to a team which is both focused on security and interested in making it accessible to people who don't necessarily have the technical knowledge (or perhaps the time) to lock down their regular distributions. Too often security and privacy are afterthoughts and it's good to see developers taking the time to properly address things like proxies, security keys and messaging systems with privacy marked as a high priority. However, my experience thus far with the live CD edition of Liberté has not been stellar. It's not easy to produce secure software which is also easy to use and, unfortunately, we see that on the CD. Not being able to use the Cables communication software from the live disc I can sort of understand though I do think it's too bad the developers don't allow people to use the software from the live CD and then allow us to transfer persistent files to another medium.
During my trial other messaging systems (Pidgin and XChat) wouldn't work, which effectively limited my communication to what I could do with the web browser. Speaking of the web browser, here Liberté makes a tricky choice. Namely when the user wishes to do something insecure, should the system let them, warn them or prevent the risky move? Liberté prevents the user from using the unsafe browser option (the Epiphany setup which does not utilize Tor) once we are connected to the network. In truly hostile environments this is probably a good way to go, but during my trial (safely performed at home) it was an unwelcome design choice. Another unwelcome choice was the inability to add more software to the live environment. Most Linux live discs allow the user to temporarily load software from the repositories into memory, Liberté does not. As a result the potential functionality of the distro is limited somewhat.
At this point in time Liberté Linux is a fairly young project so I believe it can be forgiven some rough edges. Right now it provides secure web browsing out of the box and good basic functionality, easy security key management and, on writeable media, secure communications. For now it seems to have a few lingering bugs to work out, but I can see this project could easily become a very useful privacy tool, not only for IT professionals, but for the population at large.
|
| Miscellaneous News (by Ladislav Bodnar) |
Arch switches to systemd, Damn Small Linux gets resurrected, NetBSD introduces sysupgrade, Mandriva launches foundation, Debian celebrates 19th birthday
 As Linux evolves and new technologies take over from established ones, some users are starting to wonder whether these changes are really necessary. It is the turn of Arch Linux, a distribution built on the KISS (Keep It Simple, Stupid) principle that is becoming to experience the pain. But as Allan McRae argues in "Are We Removing What Defines Arch Linux?", the modern innovations are here to be embraced, not shunned: "I think it is plainly obvious that systemd will become the primary system initialization method for Arch Linux in the not-too-distant future (not that this has been formally decided, so take that statement as unofficial). Having not used systemd at all, I really can not comment directly on if it is any good or not. But what do we lose by moving to systemd in Arch? I have seen the following criticisms: Users are being forced to use systemd. This argument really does not hold water. How many initialization systems are currently in use on Arch systems? Just the one currently 'forced' on you." Jason Ryan has more on the same topic in "Trolling Arch Linux".
* * * * *
 Damn Small Linux is back! Probably one of the very first Linux distribution projects trying to create a super small, yet usable operating system that could run fast in full graphics on any system, it became dormant once Robert Shingledecker left the project to create Tiny Core Linux. But John Andrews is now back with a new development build of Damn Small Linux, four years after its last stable release. PCAdvisor's Jon Gold writes in "Damn Small Linux getting a big update": "The developer of Damn Small Linux, a distribution designed to work on older and less powerful hardware, has released his first new version of the software in four years. The distro weighs in at a shade over 50 MB, in keeping with its mission to be one of the most lightweight, simple operating systems out there. According to DistroWatch, Damn Small Linux still has a reasonably functional desktop, including basic multimedia support, productivity programs and web functionality. 'Because all the applications are small and light it makes a very good choice for older hardware,' the website says."
* * * * *
 It looks like NetBSD is finally joining the world of automatic system building and upgrading - by introducing sysbuild and sysupgrade into the project's pkgsrc framework. Julio Merino explains on NetBSD blogs: "If you are like me and do not like repeating manual tasks over and over again, you probably have written custom scripts to rebuild NetBSD from source and to upgrade your NetBSD installation to a new build. I have had such scripts for years, but they have always been very rudimentary, inflexible and unreliable. What's more: every NetBSD machine I have today has its own custom versions of these scripts, often with little incompatible tweaks to accommodate every installation. I was now facing the time to rebuild my NetBSD development box (because its VM disk is running out of space), and the thought of having to reconfigure my environment to perform periodic NetBSD builds, and to have to continue using my deficient custom upgrade script gave me the energy to sit down and write decent versions of these two tools. The results of such efforts are sysbuild and sysupgrade, and their goal is to trivialize rebuilds and upgrades."
* * * * *
 The Mandriva Linux distribution might have been saved from an imminent collapse, but its current status still doesn't inspire much confidence. The promised two alpha builds of version 2012 are way behind schedule while Mageia, a team composed primarily of former Mandriva developers and contributors, is seemingly winning the hearts and minds of the former Mandriva community. Still, Simon Phipps, writing for Computerworld UK, believes that Mandriva is on the right track: "What's going to change? Quite a bit. First of all, Mandriva plans to start a new Mandriva Linux Foundation so that the technology has a new, independent home, coupled to but broadly independent from the fate of Mandriva the company. Driven by a community-based workgroup and with open conversations, this is a crucial step to re-establishing the trust squandered by the previous management of the company in their attempts to secure control. Even more significantly, Mandriva is facing up to the reality of the Mageia fork. Recognising that a 'one size fits all' approach isn't going to work, Croset and his team have decided to rework Mandriva's products on the upstream technologies that make the most sense on a case-by-case basis. "
* * * * *
 One Linux distribution that doesn't need to worry about its survival is Debian GNU/Linux. Launched by one Ian Murdock back in 1993 and surrounded, at the time, by much scepticism about its chances to survive as an Internet-only software collaboration project, Debian GNU/Linux has just celebrated its 19th birthday: "Debian, one of the oldest actively maintained GNU/Linux distributions, turns 19 today. Project founder Ian Murdock originally announced the project on 16 August 1993 when he released the first version of the distribution. Looking back at that email, a surprising number of Murdock's initial goals for the project are still reflected in Debian today, despite the fact that the distribution has gone through regular leadership changes since Murdock left the project in 1996. Debian users and developers will be celebrating the distribution's birthday with parties taking place all over the world. As has become a tradition for 'Debian Day', many community members will also bake Debian cakes to bring to the celebrations."
|
| Questions and Answers (by Jesse Smith) |
|
Secure Boot and BSD
A few weeks ago OpenBSD's lead developer, Theo de Raadt, commented on the upcoming launch of secure boot technology. He had some rather strong words for the technology and for those in the Linux community who plan to support it. At the time Mr de Raadt said he had no plans regarding secure boot technology, so it seems fairly safe to assume, for the time being, OpenBSD will not run on machines with secure boot enabled. Fair enough, but this got me thinking. Most of the coverage of secure boot has focused on how it will affect Linux users and, in some cases, how it might hamper Windows users looking to upgrade their hardware (or downgrade their OS). We've heard very little out of the BSD camps.
I attempted to contact some NetBSD community members, however I haven't heard back at the time of writing. A quick search of their mailing list didn't turn up any plans concerning secure boot. This leads me to suspect NetBSD will be following the same wait-and-see path as OpenBSD.
The FreeBSD project, on the other hand, is making plans to address secure boot technology. Work is being done to provide a boot loader which can work with EFI systems. Projects which are based upon FreeBSD, such as GhostBSD and PC-BSD, would automatically benefit from this work. However, supporting EFI itself isn't so much of a problem as dealing with security keys. As Kris Moore, lead developer on the PC-BSD project stated, "The secure keys thing, that is a bigger deal, since potentially it makes us unable to dual-boot with Windows 8. The issue is that if we make changes do our boot-loader, or compile it from source (as we do), then we would have to re-sign it each time to make it bootable. This means you have to have our signature loaded somewhere in your EFI BIOS, which may be a pain to do." In essence, even if FreeBSD (and derived systems) support secure boot it will probably still be up to the individual users to add the appropriate keys to their machines if they wish to make use of the secure boot feature.
|
| Released Last Week |
BackTrack 5 R3
Offensive Security has released BackTrack 5 R3, an updated version of the project's Ubuntu-based distribution with a collection of security and forensics tools: "The time has come to refresh our security tool arsenal - BackTrack 5 R3 has been released. R3 focuses on bug fixes as well as the addition of over 60 new tools – several of which were released in BlackHat and Defcon 2012. A whole new tool category was populated - 'Physical Exploitation', which now includes tools such as the Arduino IDE and libraries, as well as the Kautilya Teensy payload collection. Together with our usual KDE and GNOME, 32/64-bit ISO images, we have released a single VMware Image (GNOME, 32-bit)." Here is the full release announcement.
Webconverger 14
Kai Hendry has announced the release of Webconverger 14, a Debian-based speciality distribution designed for web kiosks: "We have been hard at work and 14.0 marks several major enhancements: new i686 kernel, which should show better performance on multi-core hardware; NVIDIA 302.17 support via Bumblebee and VirtualGL for easing deployment; Mozilla Firefox 14.0.1, using the official distribution; 'noclean' API option for deployments where the default clean slate is not desirable (e.g. Granny's bungalow); 'swarp' API for mouse positioning; critical Flash update 11.2.202.238; better XRandR screen handling; time synchronization doesn't alter the BIOS clock; logging tweaks to increase signal over noise; better lock down." Read the full release announcement which includes related links and credits.
AV Linux 6.0
Glen MacArthur has announced the release of AV Linux 6.0, a Debian-based distribution geared towards media production: "After a very turbulent development period AV Linux 6.0 is finally here. This will be the final release of AV Linux for a variety of reasons however don't stop reading at the word 'final', this is a state-of-the-art release that culminates over 5 versions and 5 years of experience and refinement into the best release to date. Changelog: update to Linux kernel 3.0.36; update to X.Org from 'Squeeze' backports; cleaned up and improved boot with dependency-based booting; allow all users access to X server; rolled Qt stack back to clean 'Squeeze' version to solve breakages from Qt 4.8; new Control Panel; move to Nautilus file manager; added new Hydrogen drum kits; added Nitrogen...." Read the rest of the release announcement for a full changelog and screenshots.
AV Linux 6.0 - a Debian-based specialist distro for audio and video production
(full image size: 542kB, screen resolution 1280x1024 pixels)
BlankOn 8.0
The BlankOn development team has announced the release of BlankOn 8.0, a Debian-based Indonesian distribution featuring the GNOME 3 desktop with a custom desktop shell called "Manokwari". Built with HTML 5 and CSS 3, Manokwari is an evolution from the project's earlier shell called "BlankOn Panel"; it features a standard panel with a number of common applets, as well as a comprehensive menu system for quick access to applications and utilities. Other features of this release include a new DVD edition with extra software (a CD edition is also available), support for six languages used in Indonesia, Stardict dictionary, the Chromium web browser version 21, and an online package repository developed specifically for BlankOn. See the full press release (in Indonesian) for further information.
BlankOn 8.0 - a Debian-based distribution from Indonesia
(full image size: 762kB, screen resolution 1280x1024 pixels)
SolusOS 1.2
Ikey Doherty has announced the release of SolusOS 1.2, a beginner-friendly desktop Linux distribution based on the latest stable release of Debian GNU/Linux: "The SolusOS team is pleased to announce the release of SolusOS 1.2. This is a maintenance release for the 'Eveline' 1.x series. This release brings many fixes and updates to SolusOS 1, including better printer, GPU and Bluetooth support. Brief overview of software versions Firefox 14.0.1, Thunderbird 14.0, LibreOffice 3.6.0, Linux kernel 3.3.6, iptables 1.4.8, ufw 0.31.1, hplip 3.12, GNOME 2.30. Many new applications are available in the software repository. The main reason for an updated ISO image is so that users do not have to download hundreds of megabytes in updates for a new install of 'Eveline'." Here is the full release announcement.
ROSA 2012 RP 1
Konstantin Kochereshkin has announced the release of an updated build of ROSA 2012, a Mandriva-based Linux distribution. Labelled as RP (Release Pack) 1, this is largely a bug-fix release with a handful of package updates. From the release announcement: "Today we are announcing the first update pack for the ROSA 'Marathon' 2012 release (Release Pack 1). The Release Pack 1 includes all LTS updates and bug fixes available at the moment: users can now avoid some graphical cards issues which prevented booting into live mode or into initial installation by using safe mode; Firefox was updated to the latest LTS version 10.0.4 and the default Yandex search issue was fixed; Linux kernel was updated to 3.0.38; KDE updated to 4.8.3...."
Calculate Linux 12.0.2
Alexander Tratsevskiy has announced the availability of a bug-fix release of Calculate Linux 12, version 12.0.2, a Gentoo-based distribution: "Calculate Linux 12.0.2 released. Here's the first update of Calculate Linux 12.0. Main changes and bug fixes: passing the root password has been modified; installation on LVM has been fixed; GRUB 2 settings have been fixed; Clt templates are now overlaid correctly; D-Bus now auto-starts as it should; no more lags when installing packages; Smaller ISO images; we have included KDE 4.9.0, Chromium 21.0.1180.57, LibreOffice 3.6.0 and Calculate Utilities 3.0.1 into the release." See the release announcement which includes a 5-minute video about installing Calculate Linux to a hard disk.
Macpup 529
Johnny Lee has announced the release of Macpup 529, a distribution featuring the Enlightenment 17 desktop and based on Puppy Linux: "Prit and I are proud to announce the release of Macpup 529,our newest Enlightenment 17 Macpup. Macpup 529 is based on 'Precise' Puppy 5.2.60, an official 'Woof' build of puppy Linux that is binary-compatible with Ubuntu 'Precise' packages. It contains all the applications from 'Precise' Puppy with the addition of Firefox 14.0.1. Macpup 529 also includes the Enlightenment E17 window manager. The EFL libraries version 1.2.0 and E17 version 71440 where compiled and installed from source. To keep your CPU cool and your fan quiet use the CPU Frequency Scaling Tool. The first time you run Macpup, the system will be running totally in RAM." Here is the release announcement as published on the distribution's user forum.
OS4 1.0 "OpenDesktop"
Roberto Dohnert has announced the release of OS4 1.0 "OpenDesktop" edition, a Xubuntu-based distribution targeting legacy 32-bit hardware, ultrabooks and netbooks: "Today we are proud to announce the general availability of OS4 OpenDesktop 1.0. OS4 OpenDesktop is a 32-bit offering that runs on all legacy 32-bit hardware as well as the newer ultrabooks and netbooks. With this release we focus on mobility and cloud computing. Along with this release the system comes with Audacious, Totem, and Google Chrome. Some of the web applications that come bundled with the system are: Angry Birds, Pandora, Netflix, Flixter, GMail and offline GMail, Google Drive, eBuddy, Weather Channel, Google Books, Google Music, Google Calendar, New York Times, Hotmail and WebCam toy. All multimedia codecs are supported as is DVD playback." Read the rest of the release announcement for further details.
Snowlinux 3 "Xfce"
Lars Torben Kremer has announced the release of Snowlinux 3 "Xfce" edition, a desktop Linux distribution based on Debian GNU/Linux 6.0: "The team is proud to announce the release of Snowlinux 3 'Crystal' Xfce. Due to drastic changes with GNOME 3 and Unity, Xfce is growing up more and more. Xfce is quite similar to GNOME 2 and offers an alternative for all former GNOME 2 users. This is one of the reasons why Snowlinux Xfce got so many new features and improvements. It should not lack any features and functions which are available in the main edition. We are trying to let Xfce act like GNOME 2 and to offer an alternative for all former GNOME 2 users. New features: DuckDuckGo, Firefox 14.0.1, Thunderbird 14, Xfce 4.8, Linux kernel 3.2...." Here is the full release announcement with a screenshot.
Frugalware Linux 1.7
Frugalware Linux 1.7, the latest version of the general-purpose distribution designed for intermediate Linux users, has been released: "The Frugalware developer team is pleased to announce the immediate availability of Frugalware Linux 1.7, our seventeenth stable release. No new features have been added since 1.7rc2, but 157 changes have been made to fix minor bugs. Here are the most important changes since 1.6: updated packages - Linux kernel 3.4.8, X.Org Server 1.12.3, GNOME 3.4, KDE SC 4.9, LibreOffice 3.5.4, Mozilla Firefox 14.0.1; slocate was removed and replaced by mlocate; Catalyst has dropped support for all ATI Radeon HD hardware before the 5000 series; cpupower has replaced all CPU scaling daemons; all packages that still used SysVInit have been converted to use systemd; GRUB 0.x has been replaced by GRUB 2...." The release announcement.
Frugalware Linux 1.7 - the project's seventeenth stable release
(full image size: 904kB, screen resolution 1280x1024 pixels)
* * * * *
Development, unannounced and minor bug-fix releases
|
| Upcoming Releases and Announcements |
|
Summary of expected upcoming releases
|
| DistroWatch.com News |
Annual package list update
A little later than usual, we have finally refreshed the list of tracked packages as presented on each distribution's page. Based on reader's feedback and development in the free software world throughout the past 12 months, the following new packages have been added to the list:
- BusyBox - a program that combines many common UNIX utilities into a single small executable
- Cacti - a complete network graphing solution
- Calligra (replaces KOffice) - an integrated office suite based on the KDE libraries
- Clementine - a multi-platform music player
- FreeCAD - a general purpose parametric 3D modeller for CAD
- kmod (replaces module-init-tools) - a set of programs for loading, inserting, and removing kernel modules
- KMyMoney - a personal finance manager for KDE
- MATE - a traditional desktop environment forked from GNOME 2
- nginx - an HTTP and reverse proxy server
- PCManFM - an extremely fast and lightweight file manager
- PiTiVi - a free and open-source video editor for Linux
- systemd - a system and service manager for Linux
The following packages have been removed from the list: Apache (the 1.3 series), Epiphany (GNOME's web browser), Sun JRE, Lzip, MailScanner, openvas-client, QCad, SquirrelMail and Xen.
* * * * *
New distributions added to database
* * * * *
New distributions added to waiting list
- INX. INX is a minimalist, console-only Ubuntu-based live CD. The goal is to create a tool to learn more about the command line.
- Trinacria Linux. Trinacria Linux is an Ubuntu-based distribution designed to celebrate and promote the Italian island of Sicily. Trinacria is the ancient name of Sicily and some of the distribution's dialogs use a Sicilian dialect. The project's website is in Italian.
- YunoHost. YunoHost is a fully-automated personal server distribution based on Debian GNU/Linux. By default it provides pre-configured mail, instant messaging and web servers, with a web application portal to access and add services through a web browser.
* * * * *
DistroWatch database summary
* * * * *
This concludes this week's issue of DistroWatch Weekly. The next instalment will be published on Monday, 27 August 2012. To contact the authors please send email to:
- Jesse Smith (feedback, questions and suggestions: distribution reviews, questions and answers, tips and tricks)
- Ladislav Bodnar (feedback, questions, suggestions and corrections: news, donations, distribution submissions, comments)
- Bruce Patterson (feedback and suggestions: podcast edition)
|
|
| Tip Jar |
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) |
|
|
|
 bc1qxes3k2wq3uqzr074tkwwjmwfe63z70gwzfu4lx  lnurl1dp68gurn8ghj7ampd3kx2ar0veekzar0wd5xjtnrdakj7tnhv4kxctttdehhwm30d3h82unvwqhhxarpw3jkc7tzw4ex6cfexyfua2nr  86fA3qPTeQtNb2k1vLwEQaAp3XxkvvvXt69gSG5LGunXXikK9koPWZaRQgfFPBPWhMgXjPjccy9LA9xRFchPWQAnPvxh5Le paypal.me/distrowatchweekly • patreon.com/distrowatch |
|
| Extended Lifecycle Support by TuxCare |
|
|
| Reader Comments • Jump to last comment |
1 • Arch and systemd (by Microlinux on 2012-08-20 10:11:39 GMT from France)
Much has been said on the subject of Systemd. Let me quote Eric Hameleers, one of Slackware's developers.
"[...] systemd is essentially evil. It is invasive, extremely hostile to other environments, threatening to kill non-Linux ecosystems which have hal, udev, dbus, consolekit, polkit, udisks, upower and friends as dependencies. And every iteration of the software written by the Redhat employees who are responsible for hal, udev, consiolekit, polkit and now systemd are incompatible with previous releases, re-implementing their bad ideas with new bad ideas... basically proving that these Redhat employees must be declared unfit to work on the core of a Linux distro. However, the influence of their employer is so big that these products are forced upon the wider UNIX community and at some point it will be "assimilate or die". I hope we (Slackware) will find a way where we do not have to assimilate but still manage to keep the distro working. I have high hopes for KDE which has no Redhat ties and so far, manages to stay clear of this mess, sticking to widely accepted standards."
Cheers from a Slackware user.
2 • SolusOS 1.2 (by Knuckle on 2012-08-20 11:30:02 GMT from United States)
Alot going on at Solus right now,The Alpha's on Solus 2,this Solus 1.2 "Eveline respin" and plans for where Solus is going to go.
The Distro is based on debian stable (can't go wrong there) Has a nice gnome desk top ( with others availble,after all it is debian) but I think the best part of this Distro is the community involvement. If you ever thought to your self "If I were to make a distro I would include,,xxxxx..." Solus is where you need to be.Ikey is on the forum daily,listening to ideas and sharing his thoughts..it is like being in Steve Jobs garage in 1976 (ok perhaps thats a bit of an exaggeration) but you get the idea.
3 • The tragedy of Mandriva (by Marcel on 2012-08-20 11:49:56 GMT from Germany)
Having watched Mr Phipps' interview with MM Croset and Schulz about a month ago, I cannot lend Mandriva SA the benefit of the doubt. There has yet to be any real sign that the management can steer Mandriva in any direction other than down. I hope the name of the new foundation will not reference Mandriva, as it would be odd to have an OpenMandriva foundation if Mandriva itself dies or comes to only exist as a shell of its former self.
4 • Liberte & BlankON (by greg on 2012-08-20 12:26:22 GMT from Slovenia)
I've tried liberte in vbox and Live and i don't remember having didn't have those issues. but that was the previous verison. also didnt' have track pad issue when i tried it on a very old mashcine (i guess it had propper drivers) i will give it a try with new one to see if they exists. otherwise i dont' think the image is ment for stuff to be added. it's ment for activists in hostile environments to login safely (maybe using live image) post what they have to post (anti gov. post or video) and then log out and "run" away. it dors that job quite good. perhaps they should add a few more usefull network tools (i am not an expert here os i am not sure what else might be needed). but that's about it.
----
Blank ON has an interesting Gnome interface and is quite nice. I gave it a quick spin as live vbox media. what does seem strange to me is the choice of applications.i mean since they went DVD they could have added a bit more stuff. especially since a lot of people have limited internet (or slow) access in that part of the world. so for example you have stelarium only for education part.
not sure exactly what the goal is though, i also couldn't find any theme changer. otherwise the interface does make it easy to find what you need in a "traditional desktop" style.
5 • Re: 3, The tragedy of Mandriva (by Apostrophe on 2012-08-20 13:54:53 GMT from France)
It's a shame that nobody was talking about a "tragedy" when a bunch of slick, career-minded bigmouths staged a coup d'distribution at Mandrake and sacked its ingenious founder. To me Mandriva has always been stained by its own origins and by the project's corporate, top-down command structure that followed. CEOs who practised hire & fire policies and who tried to appear clever by opening interviews with a question to the interviewer ("What can you do for Mandriva?") were ultimately responsible for the distribution's demise. Although Mandriva has produced some excellent releases over the years I have no nostalgia for this project. To all intents and purposes Mageia is the new Mandriva. I guess, the main reason why most of Mandriva's developers have moved to Mageia, is that the new distribution is a self-organizing project of volunteers (no more bullying, no more corporate bs) and Mageia's success proves them right.
6 • Liberté Linux - No review of Cables? (by Sitwon on 2012-08-20 14:19:06 GMT from United States)
It seemed to me that the most compelling feature of Liberté Linux was it's Cables communication system (http://dee.su/cables) which works similarly to email (for the end user) but over the secure Tor or I2P networks. I'm a little disappointed that you didn't really touch on it at all, except to give a very brief mention that it exists.
We have been considering pulling that feature into Byzantium Linux (http://project-byzantium.org/) so it would have been interesting get opinions on it from users outside of the InfoSec sphere.
7 • Cables and Arch (by Jesse on 2012-08-20 14:48:07 GMT from Canada)
>> "It seemed to me that the most compelling feature of Liberté Linux was it's Cables communication system (http://dee.su/cables) which works similarly to email (for the end user) but over the secure Tor or I2P networks."
I agree, I think Cables is an excellent idea.
>> "I'm a little disappointed that you didn't really touch on it at all, except to give a very brief mention that it exists."
As I pointed out in the review, the edition of Liberte I was using doesn't allow Cables to run, making it pretty difficult to review. I was also disappointed.
Regarding Arch's adoption of the systemd init system, does anyone else find it curious that the developer advocating systemd also claims he hasn't used it yet?
"Having not used systemd at all, I really can not comment directly on if it is any good or not. But what do we lose by moving to systemd in Arch?"
The idea that someone would admit to not knowing if a technology was any good, but insisting there was nothing to lose by adopting it strikes me as really strange.
8 • Re: 7, Arch (by Apostrophe on 2012-08-20 15:18:34 GMT from France)
> Does anyone else find it curious that the developer advocating systemd also claims he hasn't used it yet?
Hehe. Curious indeed, especially since systemd is a very complex technical subject. It also seems a rather controversial one. I think, anyone talking about, let alone advocating systemd should be at least to some degree familiar with it, its pros and cons, its implementation in other distributions etc. I do hope, the developer (not necessarily systemd itself) receives some flack in the Arch forum ...
9 • OS4 - Netflix? (by kenjite on 2012-08-20 15:34:36 GMT from Germany)
'Some of the web applications that come bundled with the system are: Angry Birds, Pandora, Netflix...'
Anyone care to elaborate on this distro? Is the pre-installed Netflix functional?
10 • OS4 - netflix (by wilsonn on 2012-08-20 16:02:44 GMT from Canada)
OS4 includes a nice "buy now" popup everytime you boot up.
11 • Systemd (by Anonymous Coward on 2012-08-20 16:07:52 GMT from Spain)
> Does anyone else find it curious that the developer advocating systemd also claims he hasn't used it yet?
Nice question. However, I find easy for a developer to make an opinion without having used something, just by reading and investigating the theories behind that something.
I find that systemd fulfills a political need instead of a technical one. It will allow the black (red?) hand of Red Hat to somehow manipulate some non-Linux Operating Systems and to control more tightly the Linux userspace... like the Gnome desktop environment.
By the way, plans to shut udev without systemd down are on the way, something that will effectively force systemd in every relevant GNU/Linux distribution unless udev itself is forked. Mr. Lennart Poettering has announced in a mailing list (I don't know if it was a Gnome or Systemd list) his position: A position which reduces to "Take Systemd or die!!"
12 • @7, @8, @9 (by Josh on 2012-08-20 16:21:56 GMT from United States)
I read the whole of the article from which the quote was pulled, and I didn't get the idea that he was "advocating" systemd at all. To me, it sounded more like he figured it was inevitable that Arch would move to it at some point, and that it kinda fits in with what has traditionally defined Arch: using the latest and "greatest" software.
13 • Errr.. @11 (by Josh on 2012-08-20 16:22:41 GMT from United States)
And by @9, I really meant @11 :)
14 • Arch and systemd (by Microlinux on 2012-08-20 19:55:32 GMT from France)
Another nice comment from Slackware developer Eric Hameleers: "[...] Systemd, the GNOME3 of init systems."
15 • OS4 (by wilsonn on 2012-08-20 20:44:47 GMT from Canada)
Sorry.
OS4 does not have the nag screen in their latest release. The previous release does.
16 • Naive thoughts about the OEM business and EFI. (by Omar on 2012-08-20 21:53:53 GMT from United States)
Never ran a business. I don't have a full grasp on the "economy's of scale" thing I always hear about, that will prevent non EFI computer in the market. But hear me out
The Linux & BSD communities should support Zareason, System 76, or any other non Windows retailer. When I support I'm really support like exclusively. These non windows retailers should be overwhelmed with orders. There wholesalers should be overwhelmed with orders. If this happens the OEM's will be strongly encouraged to set aside some percentage of their computers for non EFI retailers.
Whatever part in the computer build assembly line that puts EFI, stop there, pull a few thousand off to the side, then keep going. Don't these company's have to pull a few off for quality assurance anyway? Physically separating for two different paths should not be a technically hard problem to solve. For the OEM its a no lose proposition. If the non the windows retailers can't sell or slow down. Put whats left back in the assembly line to get EFI. The OEM is going to sell computer. Know I realize there is a money losing time aspect to all of this. But I think thats short term not long term. I know there is some bad logic in here somewhere, so somebody please set me straight.
Like almost every piece of security software, there will be work around for EFI. So all the bad guy has to do is wait, for EFI to become a standard code base, than crack it right? This goes for the keys that all distro come up with also.
17 • Liberte (by greg on 2012-08-20 23:00:56 GMT from Luxembourg)
Just checked again. Liberte has good integration with vbox and unlike other OS here guest aditions seem to work out of the box. anyway, i can connect with IRC to wikileaks but not to freenode however it seems a setting is wrong since it tries to connect to host computer LAN address instead of to freenode. i couldn-t connect with pidgin to gmail account, but it showed strange the account name as myname@mail.com/ why the / in the end and where doe sit get it?
i didnt install it. pehaps these issues are not there on installation or if i would run it live from USB.
btw very responsive OS...
18 • "Take Systemd or ..." (by Reticent Dabbler on 2012-08-21 08:12:01 GMT from United States)
"... go fork ..."? Wasn't udev absorbed into systemd? Would it be clearer to contrast systemd with, say, System V? Or udev to HAL?
And is this just a RH plot, or Gnome's? Is that a bad thing?
19 • Mentioning hardware platform would have help (by PrivacyDusk on 2012-08-21 10:07:03 GMT from United Kingdom)
I would have been useful if you had mentioned what hardware you tested Liberté Linux on, I did not experience any problem with this distribution and actually find it better than similar ones like Tails, mainly because of their cables feature which was not mentioned in the review.
20 • Arch and systemd (by TobiSGD on 2012-08-21 14:42:25 GMT from Germany)
If Arch really switches to systed they should remove the KISS principle from their agenda.
systemd is anything but KISS.
21 • sugestion to Distrowatch (by linuxuser on 2012-08-21 15:37:04 GMT from Greece)
It would be very helpful and interesting if Jesse (or someone else) could make a small review on systemd, so that we understand the pros and cons of the system. What are the features which make systemd complicated and "evil"?
22 • systemd (by Jesse on 2012-08-21 15:46:40 GMT from Canada)
@21:
DistroWatch covered systemd before: http://distrowatch.com/weekly.php?issue=20111107#qa
The term "evil" is a bit of a stretch. The concept behind systemd isn't bad, the problems arise mostly from compiled init scripts (making the init system less accessible) and the lack of compatibility between init systems. There is also some concern that systemd is for cutting-edge Linux only. This means if developers (like the GNOME team) adopt systemd, then GNOME won't work on operating systems that don't (or can't) adopt systemd. Conservative distros like Slackware and projects like FreeBSD aren't likely to import systemd and that is going to cause cross-platform issues.
23 • Zero Install, Nix package manager and portablelinuxapps.org (by K.U. on 2012-08-21 16:58:44 GMT from Finland)
Zeroinstalled software could be used to get additional software in Liberté Linux and other Linux distributions.
Zero Install (http://www.0install.net) uses similar similar dependency resolution method as the academic project Nix package manager. Therefore zeroinstalled software do not cause dependency conflicts - even multiple versions of zeroinstalled software do not conflict and old versions of software friendly coexist with newer versions. Thats's why old versions are saved by default. And think about getting for example GNOME 2 working on any distro, someone should make Zero Install feeds for that. As Zero Install takes security seriously and works in every distro it might be considered suitable even for security oriented distributions like Liberté Linux.
Zero Install is currently available in package repositories of larger Linux distributions.
Nix may be a good choice too. Nix package manager is currently available as binary tarball for Linux, FreeBSD, Mac OSx, deb for Debian and Ubuntu and RPM for Fedora.
Then there exists portablelinuxapps.com to get apps for multiple distros. It looks good too but the portable apps do not work in every distribution due to missing dependencies. One may add those by hand, however.
Here are easy to use tools appimageassistant and appdirassistant to make portable apps:
http://portablelinuxapps.org/development/
Here is Zero-Installs software database:
http://roscidus.com/0mirror/
Nix package manager:
http://nixos.org/nix/
24 • systemd (by notsure on 2012-08-21 17:36:21 GMT from United States)
http://www.linuxquestions.org/questions/slackware-14/slackware-and-systemd-885228/
The Man lays it all out for you.
25 • @17 (by lutz on 2012-08-21 18:29:10 GMT from Germany)
the / in the end of myname@mail.com/ usually points to a ressource in XMPP
i never will use G, but since they use XMPP for messanging it should be the ressource
26 • @24 systemd (by Patrick on 2012-08-21 21:19:24 GMT from United States)
Yep, as expected there's a bunch of "it's bad because it's not the way we've always done it" comments there. It's also a year old and a lot of water has gone under the bridge.
I think Jesse said it really well in @22:
"Conservative distros like Slackware and projects like FreeBSD aren't likely to import systemd and that is going to cause cross-platform issues."
And of course this cross-platform incompatibility is all systemd's fault, and is part Red Hat's evil scheme to "make progress" and try to have smarter and cleaner system management and other such nonsense. Oh, technically it is just fine, but Red Hat is evil, and trying to corner the market by employing all these open source developers that come up with more modern and streamlined ways of doing things that should stay exactly as they have always been for the last 40 years! And they even dare to release it all as open source as if to make it look like others are free to use it! All in an effort to make it look like it's their own fault if they end up being incompatible. How dare they!
Seriously, conservative distros have the right to be conservative. But others have the right to try and make things better, and shouldn't be called evil for it. Nobody forces anyone to use systemd. It is unfair to blame others for trying to make progress. The old SysV init system is a brainless, brittle mess that has blighted Linux systems for way too long. Sure, you can fiddle with it easier. But the whole purpose of computers is to automate stuff, not to babysit them and tell them step by step what to do. So I don't see what's so horrible about switching to something that can figure out that to start serving web pages, you need to have the network up and running, instead of hardcoding such things. Sure, sys admins may not like it. Sys admins tend to like complicated things, because it makes them needed. Systems that do the right thing by themselves make sys admins obsolete.
27 • @26 (by Microlinux on 2012-08-21 21:47:18 GMT from France)
"Nobody forces anyone to use systemd."
And that is exactly where you're wrong. Once systemd is established as a "standard", all the low-level stuff (see comment #1) will have a hard dependency on systemd.
So no, you won't have a choice. Right now I'm using a "conservative distro" (Slackware) because my company installs servers and desktops for professional clients (town halls, schools, public libraries, small companies), and I just like my machines not to become your average Tamagotchi. Remember the fact that Lennart Poettering is the same guy that brought us the holy mess of PulseAudio. I don't want a new init system, because I simply don't want to break a thing that JustWorks(tm).
28 • Secure Boot (by The Rifleman on 2012-08-21 22:18:20 GMT from United States)
I keep seeing comments everywhere "...with Secure Boot enabled...". If it can be turned off and all I want to do is run Linux or a BSD solely, than why is this such a big issue? Sure if you want to dual-boot or do Geeky things, than it's an issue. Why would it be an issue for a single O.S. System if it can be disabled?
29 • systemd and other init scripts (by Jesse on 2012-08-21 23:16:38 GMT from Canada)
>> "And of course this cross-platform incompatibility is all systemd's fault, "
Not exactly, not by itself. I think some people, at least myself, are wary of systemd for a couple of reasons.
1. We already have Upstart which does basically the same thing and is backward compatible with the old init scripts. Why create another init system which is not compatible with Upstart and yet does basically the same thing?
2. systemd by itself is fine, but some developers are pushing for it to be tied to software it should not be tied to. ie GNOME. No piece of software should be exclusively tied to another, that breaks UNIX/Linux design philosophy.
3. Pottering has stated he won't muddy up his code with compatibility, which means even if other developers do step forward and make systemd work with Slackware, the BSDs, etc, their patches probably won't be accepted upstream.
systemd may turn out to be a good thing, but it's being implemented in a rather unfriendly way and I think that's why people aren't as welcoming of it.
30 • @27 (by Adam Williamson on 2012-08-22 01:36:08 GMT from Canada)
""Nobody forces anyone to use systemd."
And that is exactly where you're wrong. Once systemd is established as a "standard", all the low-level stuff (see comment #1) will have a hard dependency on systemd."
No. You're wrong. Patrick is right. Your handwave comes in your second sentence:
"Once systemd is established as a "standard""
Let's examine that. What does 'established as a "standard"' mean? Who establishes 'standards' in the F/OSS world?
Well...er...whether you mean a de facto or de jure standard, in the F/OSS world, what it boils down to is 'lots of projects choose to use it'. It's not like Red Hat has some magic wand we can wave and shout 'abracadabra, make systemd a standard!' All the systemd developers can do is write the code, release it, explain why they think it's a good idea, and exhort distributions to use it. If lots of distributions choose to use systemd, then it becomes a de facto standard, which is really a tautology - a 'de facto standard' is just 'anything that most distributions choose to use'. But they do *choose* to use things. Red Hat cannot force Arch to use systemd, or Slackware, or any other distribution. If distributions are adopting systemd then it's because they think adopting systemd is a good idea. No-one's forcing them to choose systemd. Once lots of distributions adopt it, other distros will be highly predisposed to use it too - that's the 'de facto standard' bit - just because it's more convenient to use the things that most other distros use. But what's wrong with that? How else could things possibly be?
There is an argument to be made that the merging of systemd and udev will 'force' the use of systemd, but hey, if the udev and systemd developers are happy merging, why should anyone else have the right to stop them? If enough people are dissatisfied with the direction, they can fork udev. I think at first it'll still be possible to simply build udev from the systemd+udev codebase and use it without using systemd at all, but I don't know if that's intended to continue to be the case.
To sum up...there's certainly a valid technical argument to be had about whether the systemd design of combining a bunch of low-level functions into a single codebase is the best design. Lennart, Kay and others have some pretty good arguments as to why it is, in my opinion, but the question is hardly settled. However, please keep it as a technical discussion. Nothing is being forced on anyone. It's all F/OSS code. systemd represents one approach. If others believe strongly that systemd is the wrong approach, then it's incumbent upon them to do the development work on their alternative approach, and argue for it. Distributions can then pick the approach they prefer. I just don't have a lot of sympathy for people who are bitching about the constructive work Lennart, Kay and others are doing on systemd, but who refuse to offer any kind of alternative - they just want to order the people actually doing the work to do it the way they want it to be done. Not how it works. At least Ubuntu, with upstart, are actively working on their preferred approach. What's slackware doing besides moaning?
31 • @29 (by Adam Williamson on 2012-08-22 01:48:14 GMT from Canada)
1: upstart and systemd don't really do the same thing. They have points in common but also significant differences. Before writing systemd, Lennart tried to convince the upstart developers of the merits of his ideas and have them incorporated into upstart, but they disagreed. So instead of just moaning about how upstart was doing it wrong, Lennart took the constructive step of doing it the way he thought it should be done. This is the right way to do things: try to work within the bounds of existing projects, but if you can't, don't just complain that they don't do things the way you want, do it yourself. So long as the systemd and upstart developers genuinely disagree with each other on the correct design for an init system, and so long as they continue periodically to evaluate the other approach and see if they've changed their minds, they are both doing exactly the right thing by continuing to work on their different approaches.
2: this is frankly nonsense. The 'UNIX design philosophy' hasn't been applicable to an entire operating system for, oh, a couple of decades at least. It's fine for hardcore geeks doing geeky operations at command lines; it really doesn't apply to general-purpose computing. To take one random example, there are certainly those hardcore geeks among us who produce formatted documents by writing them in markup in emacs and running them through a latex processor, but I'll bet bloody dollars to donuts that far _more_ of us produce formatted documents by opening up Libreoffice and typing the damn things. Which one of these two workflows is following the UNIX design philosophy, and which isn't?
The whole 'each program should do one thing in an entirely modular way and you should be able to chain them together any way you like to produce complex workflows' thing is a very elegant philosophy. It just hasn't really applied in practice for years, and it's silly to try and use it as a weapon against systemd when almost no-one really believes it should apply universally in a computer operating system any more. We just don't _work_ that way any more.
Your concept of 'tied to' is also really a bit too vague. The idea of GNOME being 'tied to' systemd really just means that maybe systemd is going to do some really cool things that GNOME could choose to take advantage of. It's not like it'd be impossible for any other init system to do those cool things too. If it happens, I'm sure that - for e.g. - Canonical will find a way to make upstart provide the same functions. I don't see any reason that wouldn't happen. So what are you really saying? We can never design an init system which has neat advanced capabilities that SysV doesn't have, because everything must remain SysV compatible for ever? So we must artificially restrict the capabilities of our init system to a design someone hacked together in the 1970s or whenever, just because it got popular?
3: I don't really know anything about that one, but it'd be nice to have a source for that 'Poettering has stated' bit.
32 • @27, @30 (by Adam Williamson on 2012-08-22 01:52:35 GMT from Canada)
Ah, more clarity on the systemd/udev thing, from the official announcement:
"After udev is merged into the systemd tree you can still build it for usage outside of systemd systems, and we will support these builds officially. In fact, we will be supporting this for a long time since it is a necessity to make initrds (which lack systemd) work properly."
So: udev has been made a part of the systemd codebase, but it is still effectively independent of systemd. You have to checkout systemd git if you want the udev code, but you can still build and ship udev without needing to build or ship systemd. And upstream is apparently committed to supporting this state of affairs 'for a long time'. So it seems that no, the udev/systemd 'merge' does not really force anyone to use systemd - just because they're in the same git repository doesn't mean they're actually inextricably interdependent, udev still builds and works without systemd.
33 • systemd (by RollMeAway on 2012-08-22 05:26:36 GMT from United States)
I have tried on several occasions to get an understanding of systemd.
Each attempt failed. Each question answered, proposed several unanswered questions. Many ... WHY?
Lack of coherent documentation and USER useful tools are the main problems
Each distro that has adopted systemd has a different view and cryptic set of limited directions. All distros (including fedora) have had show stopping problems switching to systemd. Yet, more distros are switching. Must be oh! I can't be left behind. I must switch too.
The glaring question is: WHAT PROBLEM IS IT, THAT SYSTEMD IS FIXING?
My systems worked fine before systemd came along. I could change and manage well. Now when I change something, it breaks, and I spend HOURS trying to decipher systemd. If this is progress, leave me out!
As systemd ages it is absorbing more and more of the utilities and programs everyone now use and understand. No doubt, if left unchecked, the day will come when Poettering and troops will incorporate the kernel into systemd.
I fantasize systemd absorbing gnome3 and both going over the hill and out of sight. Call it LennartOS and leave linux and BSD, and UNIX alone.
FORK IT!
34 • @33 (by Adam Williamson on 2012-08-22 06:32:35 GMT from Canada)
The 'lack of coherent documentation' thing is one criticism of systemd I *really* don't get - it has fantastic documentation, as good as any F/OSS code I can think of. Every part of it has a comprehensive man page:
http://www.freedesktop.org/software/systemd/man/
There's a FAQ:
http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions
A Tips and Tricks page:
http://www.freedesktop.org/wiki/Software/systemd/TipsAndTricks
and Lennart is currently writing a series of blog posts on systemd for system administrators:
http://0pointer.de/blog/projects/systemd-for-admins-1.html (and go from there)
On user useful tools - systemd works very differently to sysv, so it can be tricky to figure out how to manage it at first, but I think it's a case of adjustment, not of the tools actually being worse. systemctl is the main go-to tool for managing systemd, it can do most everything you really need to do as a user or admin. Read the systemctl man page and you'll find it has a lot of useful functions. I can't honestly think of anything you could do as a user/admin with sysv that you can't do with systemd, once you learn how, and you can do a lot of stuff with systemd that wasn't ever easy or even possible with sysv...try 'systemctl --failed', for instance, a one-stop look at any service that has failed. I mean, it's not like sysv has awesome user tools, is it? You get 'service', which is hardly the greatest invention in the history of code...
"Each distro that has adopted systemd has a different view and cryptic set of limited directions"
I'm honestly not sure what you mean by that. I'm not really an expert on SUSE or even Mandriva any more, but as far as I'm aware, they're pretty much in line with how upstream sees systemd and how it's used in Fedora. Could you clarify?
"The glaring question is: WHAT PROBLEM IS IT, THAT SYSTEMD IS FIXING?"
It's not precisely 'fixing a problem', that's not the best way to conceive of it. Though of course to an extent it's just semantics - you can call things 'problems' or 'missing features', really, as you like. The idea of systemd isn't 'sysvinit is terrible and has all sorts of problems that need fixing', it's more 'sysvinit does what it does fine but we could re-design system initialization in a way that is better' - not 'less broken' or 'less problematic' but just _better_. I wrote a post in a Phoronix thread recently which tried to highlight some of the things systemd does which sysv simply doesn't and _never could_, because it's a limited design, so I'll just point you to that:
http://phoronix.com/forums/showthread.php?72921-Arch-Linux-Is-Switching-To-Systemd&p=281248#post281248
it's really this simple: sysv does the basic job of running processes on startup okay. It's fine. It's not _broken_. It's not _wrong_. But it's a fundamentally limited design. You can't really take it and refine it any further than it has been refined already. If you take a viewpoint not of 'what bugs can we fix in sysv' but 'what would a really good initialization system look like?', it seems like the _inevitable_ conclusion is that you need a more sophisticated design than sysv. As far as I'm aware no-one has really proposed any significant refinement to sysv since the LSB grafted on rudimentary dependency handling via comments, years (or it might be a decade, now...) ago, and implementations like MDV's pinit and upstart's and systemd's sysv compatibility modes allowed parallel initialization with sysv's design. That's really as far as you can take it. I haven't seen any convincing proposal that would allow the improvements upstart and systemd make to the init process to be done via sysv. But _multiple_ people have come up with re-designs of system initialization with considerably improved capabilities over sysv. systemd and upstart are just the two most active and successful.
So...we have a world where multiple smart engineers from multiple backgrounds and companies have considered the issue of system startup, and have been unable to make significant improvements within the sysv framework, but _have_ been able to come up with more sophisticated designs which allow for substantial improvements. To me, the logical conclusion from this is 'the sysv design does the basic job, but more sophisticated designs can provide better functionality'. I _guess_ you can also look at this world and say 'look, I think the functionality sysv provides is all we really need and the improvements that the upstart and systemd re-designs provide aren't really significant enough to be worth the trouble' - but I think in order to do so you _at least_ need to take the trouble to properly understand the improvements upstart and systemd allow, and provide a convincing argument as to why we don't really need them. What I find really annoying, though, is when people look at this world and say 'ahhhh, the new designs don't do anything better than the old design, they're just change for the sake of change or they're some kind of political conspiracy for Red Hat or Canonical to TAKE OVER THE WORLD'. The evidence for that view just _doesn't seem to be there_, to me. It all points in the other direction.
I recognize that for most every day use of your system you don't really _need_ the features systemd and upstart provide. Like I said, sysv does the basic job okay, no-one disputes that. Sure it's kind of a pain to have to learn a new system. I know. But please, at least do the developers the courtesy of understanding that they're _not_ just fooling around for fun, and they're _not_ involved in some kind of conspiracy which doesn't even make any damn sense. They sat down and took a really good look at the whole concept of the init system. Lennart calls it 'process 0', which is an interesting perspective: think about the whole OS, and think, what should process 0 be, what should it do, and what should it not be? Don't just assume the existing borders must be correct, actually try and think from first principles what they ought to be. They came to the honest conclusion that there are substantial, practical benefits to using a design more sophisticated than sysv's. That kind of transition is inevitably going to come with bugs and a bit of pain and inconvenience. If you honestly think the new designs are bad ones, or even that the improvements aren't really needed and sysv is good enough for anyone, then by all means, go ahead and argue that position. I just think it'd be nice to default to assuming _good_ intentions on the part of people who are at least making an effort to write better systems, not _evil_ intentions, and it'd also be nice to at least make a genuine effort to understand their new ideas and the thoughts behind them rather than just saying 'I never really thought about the limitations of the old system and I'm used to it, so this new system is just wrong and bad'.
35 • KISS (by Reticent on 2012-08-22 07:20:15 GMT from United States)
I was taught this expands to Keep It Short & Simple. No need to be demeaning.
36 • @35 KISS (by greg on 2012-08-22 07:27:50 GMT from Slovenia)
You were tought wrong (sort of - read mor ein link): "KISS is an acronym for the design principle articulated by Kelly Johnson, Keep it simple, Stupid!."
http://en.wikipedia.org/wiki/KISS_principle
37 • KISS (by Reticent on 2012-08-22 07:32:46 GMT from United States)
No need to be demeaning; and Short Counts. I have seen examples of Simple works which were, while Simple, too large to comprehend.
Think of this as a refinement.
38 • Systemd again. (by Anonymous Coward on 2012-08-22 10:02:43 GMT from Spain)
Adam Williamson wrote:
--------------------------------------------------
If distributions are adopting systemd then it's because they think adopting systemd is a good idea. No-one's forcing them to choose systemd.
--------------------------------------------------
It depends on what you consider "forcing" to mean. Plans are being made for Gnome to place more and more functionality on Systemd's shoulders, thus systemd will eventually be a "forced" Gnome dependency. I don't say this is bad per se, and it's not exactly systemd's fault, but I find tying the desktop userspace to a particular boot system is weird at the very least.
Patrick wrote:
-------------------------------------------------
Sure, sys admins may not like it. Sys admins tend to like complicated things, because it makes them needed.
-------------------------------------------------
Yes, they want to use complex things so their work is hard and unfulfilling, and they have headaches because of their job.
Oh, no, I don't think so. I'd rather keep my systems easier to handle and tweak. That is why I like BSD-init, even with its disadvantages.
Adam Williamson quoted:
-------------------------------------------------
"After udev is merged into the systemd tree you can still build it for usage outside of systemd systems, and we will support these builds officially. In fact, we will be supporting this for a long time since it is a necessity to make initrds (which lack systemd) work properly."
-------------------------------------------------
In fact, Mr. Lennart has claimed his desire to drop support for udev outside systemd when possible. Look, his rationale for keepind standalone udev is not compatibility, but initrd sanity!
39 • OS4 and NETFLIX (by beanybrian on 2012-08-22 14:44:36 GMT from United States)
OS4 Has Chromium as it's browser and that has the NETFLIX app pre-installed. It is merely a "shortcut" app. Once you go to stream a movie the operating system requirements kick in and well you know the rest.
40 • @27 (by Patrick on 2012-08-22 14:50:49 GMT from United States)
"""Remember the fact that Lennart Poettering is the same guy that brought us the holy mess of PulseAudio.""
Oh, now there we see the real reason for your dislike, you're a genuine Poettering hater.
I've said it before and will say it again: PulseAudio was the best thing that ever happened to Linux audio. I don't want to think about the struggle it always used to be to allow multiple audio programs to run, let alone play audio simultaneously, before PulseAudio came and finally brought sanity to audio on Linux. Why did PulseAudio get adopted by pretty much all distros on the planet? Because everybody loves the guy who made it? As you're well aware, that's hardly the case. No, it was because it solved a real problem and made Linux a better system.
Maybe Lennart Poettering is a jerk, maybe he is a nice guy. I don't know, I haven't met him and don't know him. What I do know is this: he is a guy who is willing to look at the status quo, see what needs to be improved and get to work and do something about it. And guess what, it looks like his solutions solve some real problems, seeing how eager distros are to incorporate his stuff. That earns him a lot of respect from me. And I guess it earns him a lot of grief from those who prefer the status quo.
41 • @34 (by Patrick on 2012-08-22 15:30:52 GMT from United States)
Thanks for the thorough explanation Adam, but I'm afraid you might as well be talking to the walls.
I love the Linux and open source development community, but in my opinion, there's a significant part of the user community that's just plain rotten. Here they get all this wonderful software, for free no less, made by developers who really know their stuff and think very hard about all the issues involved. They become experts at what they do, work countless hours on stuff they give away to their users, and what do they get? Derision, even all out hatred, whining and complaints, being told their code is junk by inane and clueless users that don't even have the slightest idea of all the issues involved in making their systems work.
These users take for granted that their computers can play sound from multiple programs at once without them having to lift a finger, but hate the PulseAudio daemon that does it for them. They love what their computer can do but hate the software that does it for using their RAM. They love how fast their system starts but hate the "newfangled" init system that makes it possible. They complain about the "bloatware" developers produce, but laud the 40-year-old init system that spawns 100's of shells during boot and despise the tight and efficient new daemon that can do it much more efficiently. They complain when some service dies but don't want the system that can restart it for them. Heck, they hate a guy for writing code to try and make things better and sound like they'd rather have him not do anything at all!
It's a great thing that companies like Red Hat and others employ open source developers. There sure wouldn't be many doing it if they were just doing it for the love of their users.
Long live developers. Long live the doers. Screw the whiners and haters.
42 • @ 40 (by Blue Knight on 2012-08-22 16:07:28 GMT from France)
> PulseAudio was the best thing that ever happened to Linux audio.
My God, no! PulseAudio is crap, as other things in Linux unfortunately... But I don't want talking about them here and now. And I have no time now...
43 • @41,30 (by TobiSGD on 2012-08-22 16:18:06 GMT from Germany)
"These users take for granted that their computers can play sound from multiple programs at once without them having to lift a finger, but hate the PulseAudio daemon that does it for them."
Huh? My systems are able to do that without PulseAudio.
"They complain about the "bloatware" developers produce, but laud the 40-year-old init system that spawns 100's of shells during boot and despise the tight and efficient new daemon that can do it much more efficiently."
I don't care how many shells are spawned during the booting process and I don't care about boot times. I also don't care about the "efficient new daemon". I care about my systems and how they are running, not which software you want to run on yours. If you are fine with systemd that is not my problem. I can't see any advantage in running systemd instead of BSD-like booting for me (or SystemV or Upstart). They can coexist without a problem, but sadly that isn't what those Red Hat developers want. Read through their blogs and the mailing lists, they want everyone to run the one and only, systemd. If you don't want to run their latest and greatest you are a hindrance for progress and balkanize the Linux ecosystem.
I don't want to run systemd.
Screw me therefore? If that is what you want then do it. Calling me a hater because I don't need that stuff and are happy that it will not be integrated as long as possible in my favorite distro? Who is the real hater here?
"Long live developers. Long live the doers."
Of course, a long life for them. But why have I to follow the doers if I don't benefit from their work? Don't get me wrong, I appreciate Red Hat's effort on kernel development, but I neither need PulseAudio nor systemd and although I personally think that Poettering is a jerk I promote his ideas, if they actually make sense to me (like the os-release file).
Adam Williamson is asking in @30: "What's slackware doing besides moaning?"
Sorry, but could you please elaborate? Why should Slackware do anything about init systems? They have a working one, why should they change? And even if they wanted to do something like forking udev, how should they do it? They lack the funding for something like that. Easy to say for a Red Hat developer: Well, if you don't like it then fork it. Not easy for the smaller distributions, so sooner or later they have to change to systemd. Wait, didn't you say that there is no force?
44 • Linux advocates? (by Antony. on 2012-08-22 16:43:35 GMT from United Kingdom)
Yes Patrick, it is a sad fact of human nature.
And when you see someone proclaim: 'I won't use distro x because it does not respect my freedoms...' Honestly, it makes me sick!
------------
Post 42: Blue Knight. what are you even doing here?
------------
Linux is supposed to attract sensible and free-thinking people but some people come across as fanatics, bigots, inflexible and incredibly immature.
45 • @42 Pulse Audio (by DavidEF on 2012-08-22 16:57:28 GMT from United States)
I had to laugh inside when I read your comment, because it is so obviously true, and a lot of people know it. Anyone who really thinks that "PulseAudio was the best thing that ever happened to Linux audio." is truly delusional.
46 • Change for the sake of CHANGE! (by RollMeAway on 2012-08-22 17:01:36 GMT from United States)
The general concept that a software project is dead if it is not constantly releasing changes is the heart of many problems.
Recent example is thunderbird. Mozilla said they would not be adding any new features and would go into maintenance mode. All the blogger proclaim the end of thunderbird. NOT!
KDE3 and gnome2 are classic examples. Both matured to the point the users were content. The developers had nothing to change, so decided it time to wipe the slate and start over.
Proper thing to have done was start a NEW project, different name, and leave the existing ones alone, in maintenance mode.
The hammer my great grandfather used still works well.
I don't need a NEW one!
47 • @44 Antony (by DavidEF on 2012-08-22 17:26:13 GMT from United States)
You said:
"Linux is supposed to attract sensible and free-thinking people but some people come across as fanatics, bigots, inflexible and incredibly immature."
In my experience, it is mostly those who have been around the longest who are "...fanatics, bigots, inflexible and incredibly immature" The rest of us just want our computers to work. I know Adam Williamson is technically correct in saying that systemd will only become a standard if the distros choose to use it. But the distros are not built on democracy. The decision makers don't always do what is best for the end users. So his reassurances are not doing much to reassure me.
Pulse Audio is, IMHO, a painfully wonderful example. It became the defacto standard, not because it was best for users, but because the biggest distros chose to 'force' it on their users. Now, it is at least mildly functional for me without too many headaches (but still not great). For years, it gave me more grief than usability. A large portion of users had the same experience. We are not haters or whiners just because we want our computers to do something useful for us without breaking.
48 • @43 (by Patrick on 2012-08-22 17:30:51 GMT from United States)
"""If you are fine with systemd that is not my problem. I can't see any advantage in running systemd instead of BSD-like booting for me (or SystemV or Upstart). They can coexist without a problem, but sadly that isn't what those Red Hat developers want. Read through their blogs and the mailing lists, they want everyone to run the one and only, systemd. If you don't want to run their latest and greatest you are a hindrance for progress and balkanize the Linux ecosystem. """
...
"""And even if they wanted to do something like forking udev, how should they do it? They lack the funding for something like that. Easy to say for a Red Hat developer: Well, if you don't like it then fork it. Not easy for the smaller distributions, so sooner or later they have to change to systemd. Wait, didn't you say that there is no force?"""
How do you reconcile these two statements? What you're saying is: "I resent Red Hat for making these changes, because due to the lack of developers in my favorite distro, they have no choice but to follow along". How is this Red Hat's fault? Why should Red Hat even care? Why should they not progress their own product, because it might upset the users of someone else's product, because this other product can't take care of itself? Aren't you really saying that you wish you could force Red Hat to not develop and use systemd, just so your own preferred distro wouldn't have to take care of giving its own users what they want? Red Hat isn't forcing anyone to do anything. It's the developer pool of your preferred distro, or lack thereof, that's the problem.
It's all open source, for crying out loud. If enough people want something, it thrives. If not, it dies. If the old SysV init system is superior, it will not be displaced. If systemd has advantages, it will take over. If sound works great without PulseAudio, it isn't needed and will die. If sound doesn't work, and PulseAudio solves a real problem, it will get widely adopted (and it did). If you want something different than the majority, you can have it, but you will be on the fringe and have to take care of it yourself. You have that freedom with open source. But you don't have the freedom to tell someone else what to do and what not to do. Developers develop what they want, distros adopt technologies as they see fit, users choose distros that suit their needs. Arch seems to have seen a benefit in adopting systemd, Slackware has not, so its there for who don't want it. Users will choose accordingly. There is no reason for Slackware users to be upset that Lennart Poettering saw a need to develop systemd, that Red Hat promotes it, that udev developers feel like merging with it is a good idea, or that Arch is adopting it. Slackware is already on the fringe, and it is happy to be there. Other distros adopting systemd will make little difference in that.
49 • @45, 47 (by Patrick on 2012-08-22 17:43:15 GMT from United States)
"""Anyone who really thinks that "PulseAudio was the best thing that ever happened to Linux audio." is truly delusional."""
"""It became the defacto standard, not because it was best for users, but because the biggest distros chose to 'force' it on their users."""
Sure. 90% of the distro developers thought: wouldn't it be great to screw over our users by adding this completely unnecessary piece of software, just to bug them! Mass lunacy swept over the Linux desktop landscape and they all just did this!
"We have realized you know better than us developers, O Almightly User. You are all-knowing and wise, O Almightly User. We developers have no idea what we're doing, O Almighty User, and we have sinned. Please forgive us."
Talk about delusional.
50 • @49 (by Barnabyh on 2012-08-22 18:04:54 GMT from United Kingdom)
That's a bit extreme, they surely did not think let's "screw over our users", and nobody suggested they did.
My own interpretation is rather that in the fast moving Linuxverse we have a high percentage of younger developers who are high on always the latest and greatest, with the predominant view now often being 'if it ain't broke lets break it', or rather 'it ain't broke but we'll fix it anyway'.
Alsa was good and I'm still using it. I'm afraid I'm more and more looking to BSD as alternative, not that it mattered to anyone. But I don't want to find in a few years that Linux means a system you cannot run without systemd and half of Gnome as dependencies present.
51 • New "features" for the dumb users? (by RollMeAway on 2012-08-22 18:08:07 GMT from United States)
KDE4 now provides "semantic desktop" (akonadi, nepomuk, etc. who thinks up these names?)
gnome3 uses Zeitgeist, tracker, etc.
These "features" datalog the users every keystroke, every file accessed, email written and received. All web pages visited, etc.
What dumb user wants this?
Clearly governments and businesses will benefit greatly.
Why would anyone developing software for their own use want such "features"?
Just concede, the Almighty, KnowsEverything, Developers Know best?
I think not.
52 • @48 (by TobiSGD on 2012-08-22 18:19:36 GMT from Germany)
"What you're saying is: "I resent Red Hat for making these changes, because due to the lack of developers in my favorite distro, they have no choice but to follow along". How is this Red Hat's fault? Why should Red Hat even care? Why should they not progress their own product, because it might upset the users of someone else's product, because this other product can't take care of itself? Aren't you really saying that you wish you could force Red Hat to not develop and use systemd, just so your own preferred distro wouldn't have to take care of giving its own users what they want? Red Hat isn't forcing anyone to do anything. It's the developer pool of your preferred distro, or lack thereof, that's the problem."
No, that is not what I am saying. If Red Hat thinks that systemd is good for their distro then they should develop and use it. But they don't want to be the only ones using systemd. They want that all distros adapt it.
Isn't open source about choice? Isn't it something like: "I think that BSD init would be better for my distro, so I simply use it." or "I think that for my open source application FreeBSD with Gnome would be the best base, so I use it."
At least it was that way. Now comes Red Hat with Poettering and says: "We want everyone to use our software. We don't care about those small distros that die in that process." They are actively destroying the choice. And you argue in favor for them, that any distro that can't afford to work on an udev fork should either bow to the force or die.
OK, the udev developers think that it is better to merge with systemd. Not really tragically now, but since Poettering declared the goal to make it impossible to build udev outside systemd there will be even more force to change in the future. Maybe Slackware has to change to systemd some time, but they will not doing it freely, they will do it because they have to, being forced by open source developers acting against open source philosophy.
" But you don't have the freedom to tell someone else what to do and what not to do."
But that is exactly what I described above: Poettering and Red Hat are not telling you what to do, they use their actions to tell others what to use and what not. Poettering's comment about an Ubuntu developer working on systemd packages: "The last bastion is crumbling!" (from systemd's Google+ site). That doesn't sound like peaceful developing, it does sound like an actively fought war.
53 • @52 (by Patrick on 2012-08-22 19:28:35 GMT from United States)
"""If Red Hat thinks that systemd is good for their distro then they should develop and use it. But they don't want to be the only ones using systemd. They want that all distros adapt it. """
They may "want" all they want, how exactly are they going to force anyone? If it is no good, it will not make it. If it is good, solves real problems, makes life better for developers, etc then it will get widely adopted. Time will tell. Technical merit is what will decide, but the tin-hat crowd always seems to think there is some evil "force" at work, influencing everyone to mindlessly adopt something that has no reason to exist.
"""Now comes Red Hat with Poettering and says: "We want everyone to use our software. We don't care about those small distros that die in that process." They are actively destroying the choice. And you argue in favor for them, that any distro that can't afford to work on an udev fork should either bow to the force or die."""
Again, do either Red Hat or Poettering have some magical power to make what they want happen? Are they blackmailing? Hiring assassins to kill opposing forces? What unethical thing are they actually doing? How about, God forbid, writing good, useful code for the community? Is that unethical now? Is being proud of your work and wanting people to use it unethical? I can tell you for a fact that if the code wasn't good, no one would be paying attention.
And how are they "actively destroying choice"? There used to be SysV, BSD, ... Now there's also Upstart and systemd. Looks to me like there's more choice than before. Why are you against more choice? SysV used to be the de facto standard. Now the standard is threatened by something else that would like to be the de facto standard. The only difference is that you liked the one and don't like the other. It has nothing to do with choice.
"""OK, the udev developers think that it is better to merge with systemd. Not really tragically now, but since Poettering declared the goal to make it impossible to build udev outside systemd there will be even more force to change in the future."""
Care to provide a link?
54 • @51 (by Patrick on 2012-08-22 19:49:25 GMT from United States)
"""These "features" datalog the users every keystroke, every file accessed, email written and received. All web pages visited, etc.
What dumb user wants this?
Clearly governments and businesses will benefit greatly."""
I guess KDE4 is not for you then, since you seem to intensely distrust the intentions of the developers. As if any business or government would be interested. And it is open source by the way, so you could check, but hey, why would you alleviate your irrational fears.
But anyway, I guess you could use Gnome instead. Oh I forgot, the Gnome developers are evil too. I temporarily forgot why, but I've heard they are. Hating them has been very popular lately. And a lot of them are at Red Hat, so that's bad.
Unity? No, Mark Shuttleworth is definitely out to make money and not to be trusted. That he invested millions of his own money in Linux is definitely a sign he's trying to take control and up to no good. He'll probably take Ubuntu proprietary, the GPL be damned.
I'd say that udev needs to go too for sure, since they track every single device you plug in to your computer, likely for evil ends. And especially now they are showing their true colors by being in league with Poettering, that spawn of the devil.
And let's not talk about the Linux kernel... it really touches everything you do on your computer, and that Torvalds guy is a self-admitted jerk. He's definitely out for world domination and seems to be getting close to that goal, and once he's there, he'll spring his evil scheme, mwohahahaha... That is if Shuttleworth doesn't beat him to it. Or Poettering. Or any other of the host of evil characters that make up the Linux development landscape. How does anyone dare to use this stuff?
55 • @50 (by Patrick on 2012-08-22 20:01:40 GMT from United States)
"""That's a bit extreme, they surely did not think let's "screw over our users", and nobody suggested they did."""
If users don't accept that developers evaluated a technology and had good solid reasons to adopt it, then what other explanation would there be?
"""we have a high percentage of younger developers who are high on always the latest and greatest, with the predominant view now often being 'if it ain't broke lets break it', or rather 'it ain't broke but we'll fix it anyway'"""
Define "broke". Does that include "very hard to maintain", as in case of Gnome 2? As a user you'd likely say "no" but as a developer you'd say "yes".
56 • @51 Patrick (by DavidEF on 2012-08-22 20:15:14 GMT from United States)
You know, openly attacking the intelligence of others and drawing extreme conclusions to "make a point" are very juvenile and not needed. If your argument has merit, it doesn't need to be propped up by insults and extreme sarcasm. Tell us what makes your stuff good, don't attack us for saying it isn't good.
You're really proving what I said in post #47 (in reply to Antony, post #44)
""In my experience, it is mostly those who have been around the longest who are "...fanatics, bigots, inflexible and incredibly immature" The rest of us just want our computers to work.""
57 • @53 (by TobiSGD on 2012-08-22 20:23:59 GMT from Germany)
"They may "want" all they want, how exactly are they going to force anyone?"
...
"Again, do either Red Hat or Poettering have some magical power to make what they want happen? Are they blackmailing? Hiring assassins to kill opposing forces? What unethical thing are they actually doing? How about, God forbid, writing good, useful code for the community? Is that unethical now? Is being proud of your work and wanting people to use it unethical? I can tell you for a fact that if the code wasn't good, no one would be paying attention.
And how are they "actively destroying choice"? There used to be SysV, BSD, ... Now there's also Upstart and systemd. Looks to me like there's more choice than before. Why are you against more choice? SysV used to be the de facto standard. Now the standard is threatened by something else that would like to be the de facto standard. The only difference is that you liked the one and don't like the other. It has nothing to do with choice."
Seems to me that you have only read the parts of my previous post that you wanted to see. As I stated before, what is the use of a BSD, SystemV or Upstart init system if you don't have the resources to maintain a fork of the needed software for that? Dropping support for udev on non-systemd distros is like taking away from those smaller distros the choice of the init system.
"Care to provide a link?"
Of course, from the mailing list: http://lists.freedesktop.org/archives/systemd-devel/2012-August/006066.html
Lennart Poettering: "(Yes, udev on non-systemd systems is in our eyes a dead end, in case you haven't noticed it yet. I am looking forward to the day when we can drop that support entirely.)"
58 • Gnome 2 broke? make a new Gnome 2! (by DavidEF on 2012-08-22 20:30:40 GMT from United States)
Patrick,
If Gnome 2 was hard for developers to maintain, then that is ample reason to replace it. But, the replacement could have still looked and acted a lot more like Gnome 2, or at least been easily configurable, which is what most people's complaints really boiled down to, as I recall.
And yeah, we're not saying the developers actively pursued screwing the users, just that they didn't actively pursue NOT screwing the users. Like I said before, most distros are not a democracy. Fine if that's what ya want, but you take the good with the bad. If you ask people what they want, and give it to them, you lose some order and personal control, but you often gain happier users. The other way around, you keep control and fulfil your vision as the decision maker, but some people are bound to be unhappy with it.
59 • @57 (by Patrick on 2012-08-22 21:40:15 GMT from United States)
"""Lennart Poettering: "(Yes, udev on non-systemd systems is in our eyes a dead end, in case you haven't noticed it yet. I am looking forward to the day when we can drop that support entirely.)""""
Seems I'm not the only one doing selective reading:
Lennart Poettering: "Well, we intent to continue to make it possible to run udevd outside of
systemd. But that's about it. We will not polish that, or add new
features to that or anything."
Anyway, from this I gather that your beef may be more with the integration of udev into systemd than with the existence of systemd. I do agree that it would have been better for future support of other init systems if udev had not been merged with systemd.
60 • @DavidEF (by Patrick on 2012-08-22 21:48:25 GMT from United States)
I admit I was being sarcastic, but I fail to see whom I insulted. Sorry if it came over like that, I did not intend to insult anyone.
"""Like I said before, most distros are not a democracy. Fine if that's what ya want, but you take the good with the bad. If you ask people what they want, and give it to them, you lose some order and personal control, but you often gain happier users. The other way around, you keep control and fulfil your vision as the decision maker, but some people are bound to be unhappy with it."""
If you ask people what they want, you get many different answers. I am perfectly happy with what the Gnome 3 developers did. Obviously you would have liked to see something similar to Gnome 2. Both of us are their users, so if they had asked both of us what we wanted, what should they have done? Either way, one of us would have been unhappy.
61 • @38 (by Adam Williamson on 2012-08-22 21:53:05 GMT from Canada)
"It depends on what you consider "forcing" to mean. Plans are being made for Gnome to place more and more functionality on Systemd's shoulders, thus systemd will eventually be a "forced" Gnome dependency. I don't say this is bad per se, and it's not exactly systemd's fault, but I find tying the desktop userspace to a particular boot system is weird at the very least."
Well, I kinda addressed that earlier. I don't think it's so weird, if you think it through.
It comes down to a point from my @34: the only 'standardized' init system we have at present is sysv, and sysv is a fundamentally limited design. systemd and upstart use new and different designs rather than just extended sysv, not because it's fun, but because they absolutely need to do so: in order to really improve init, you need to go beyond the sysv design.
So let's take that a step further. With a new, different, more sophisticated init system design than sysv, we can get some really cool improvements to the init process. Fine. Isn't it kind of expected that some of those improvements come in the form of 'things that applications higher up the stack need to use the new init system design for'? We've already established that we can't just keep using the sysv layout and conventions but keep making the init daemon smarter; systemd, upstart and several less successful implementors _all_ came to that conclusion. It doesn't seem particularly odd to me that, to get all the benefits of a better init system design, applications need to start taking advantage of the features native to the new design. If GNOME could take advantage of all the new stuff systemd allows just by using systemd's sysv compatibility support, we wouldn't need the systemd native format in the first place!
In this scenario GNOME wouldn't really be dependent on systemd per se. It'd be dependent on some of the advanced features of systemd that can't be taken advantage of via the sysv compatibility mode. At first systemd might be the only init system that implements these, but there's nothing to say it has to stay that way. It's not like systemd's capabilities are secret sauce: it's F/OSS! How can systemd possibly stop any other init daemon duplicating its capabilities? If lots of projects decide they like systemd's design and start working to it, then systemd's design becomes the new de facto standard init system design. That seems kinda natural to me. It doesn't mean systemd is entrenched; it just makes systemd's _design_ the standard. Anyone can implement an alternative daemon which works with the systemd layout, if they like. People did so with the sysv layout.
Right now we don't have a standard for a next-generation init system. We have a few competing different designs. sysv didn't start out as a standard, either - just one design among others. It became a standard through consensus over time. What's happening now is really just the sausage factory part of the process of coming up with a new, more sophisticated standard design. If no-one except the upstart authors and Lennart really thought there were any compelling benefits to a new init system design, no-one would be bothering to take advantage of the features of systemd's native design. If projects are, then it means we _can_ benefit from a new design, and we're going to have to pick one _somehow_.
You could argue of course that 'we' ought to have had a committee come up with some new agreed-upon design, rather than several groups just up and doing their own thing. Maybe that would have been better, yeah, but things just don't always happen that way; you can't always get the geeks to agree. system init is hardly unique in this case, it's not like we don't have fifteen different implementations of all sorts of other things. The capabilities of systemd are not secret magic that only systemd can implement, if higher-level projects decide they like the systemd design and start working to that, I don't see why other init daemons can't implement compatibility with that design - and just the same for any other next-gen init system. If higher-level projects decide they like the upstart design instead, systemd might grow compatibility with that. And so on. All the code is out there, there's no secrets or lock-in really possible, just healthy competition.
62 • RE:41 (by Anonymous Coward on 2012-08-22 21:54:44 GMT from Spain)
It seems to me you are taking it, with the help of others, to an emotional level.
Concerns do not happen without a reason. I don't think systemd is getting retractors just because it is different, or because Lennart is making little effort to get loved. Concerns arise because users are unsure of what systemd represents for the future of their systems and the system model they are used to. And some are concerned about portability implications too.
63 • @43 (by Adam Williamson on 2012-08-22 21:55:43 GMT from Canada)
Yeah, to be fair I was a bit harsh with that one. As I wrote in my later post, 'I genuinely believe we don't need to improve on the sysv design' is a reasonable standpoint on the issue. But I do wish Patrick would argue it more from the merits and less by entirely dismissing even the possibility that there could be a better design. It would be nice if he could, say, look at the things some apps are already doing with the systemd/upstart native designs and say why he doesn't think they're necessary, or how they could be done with sysv instead.
The whole force question is really turning rapidly into a semantic bog. I mean, yeah, when a certain way of doing something that's critical to the system's function gains a certain level of support it tends to become a de facto standard that you have to work extra hard if you really want not to use it. You can characterize that as 'force', if you like. I'm just not sure it's really worth trying to avoid that happening, or even possible.
64 • @47 (by Adam Williamson on 2012-08-22 22:00:33 GMT from Canada)
So...why do you think distros adopted PulseAudio, if not because they thought it was the best option for their users? What is their motivation if it's not that?
65 • @52 (by Adam Williamson on 2012-08-22 22:05:37 GMT from Canada)
I wish you'd provide attributions for all the words you put in Lennart's mouth, because I really don't think his position is that 'my way or the highway'. I'm kind of reluctant to argue with your strawman.
66 • @50 (by Adam Williamson on 2012-08-22 22:06:05 GMT from Canada)
PulseAudio is a layer on top of ALSA. It doesn't replace ALSA. You're still using ALSA on any modern distro.
"But I don't want to find in a few years that Linux means a system you cannot run without systemd and half of Gnome as dependencies present."
Even if this vague 'GNOME depends on systemd' scenario comes to pass, you're reading it exactly the wrong way around: GNOME depending on systemd wouldn't mean you can't have systemd without GNOME, it'd mean you can't have GNOME without systemd.
67 • @43 (by Patrick on 2012-08-22 22:22:21 GMT from United States)
"""But I do wish Patrick would argue it more from the merits and less by entirely dismissing even the possibility that there could be a better design. It would be nice if he could, say, look at the things some apps are already doing with the systemd/upstart native designs and say why he doesn't think they're necessary, or how they could be done with sysv instead."""
Me? I think you have names mixed up here. I'm well convinced that SysV could be improved upon. :)
68 • @67 (by Adam Williamson on 2012-08-22 23:16:43 GMT from Canada)
I was talking about the Patrick who runs slackware, not you...Patrick Volkerding.
69 • breakage for breakage's sake (by Anonymous Coward on 2012-08-22 23:25:05 GMT from United States)
It says it all when even the most fervent advocates for systemd have to admit, however, grudgingly, that it doesn't actually solve any, well, you know... problem.
One wonders if these same folks would be willing to make a modification to their car engine that didn't improve performance, nor efficiency, nor any other objectively measurable operating characteristic, but which did carry with it an increased risk of mechanical breakdown and costly repair.
One imagines that systemd advocates would answer "Where can I get this awesome mod?"
I suppose it's obvious what my answer is. Debian FTW.
70 • @69 (by Adam Williamson on 2012-08-22 23:42:34 GMT from Canada)
You seem to have entirely missed the point of the distinction between 'fixing problems' and 'making improvements'.
If you mod your car's engine from 100HP to 200HP have you 'fixed a problem'? Not really, was a 100HP engine in your car really a problem? The car worked. You've just made it _better_. (Er, assuming you like going fast and don't care about fuel efficiency).
The whole point of what we're saying is that systemd isn't about 'fixing problems' but about 'making improvements'. The 'what problems does systemd fix?' argument is flawed because it assumes the only possible reason for writing new software is to fix problems in the software it replaces. That's _not_ the only possible reason. A perfectly good alternative reason for writing new software is because it does things _better_ than the old software it replaces. systemd isn't about fixing problems, but about making improvements. I linked to a post where I cited a bunch of those improvements. Perhaps you could read it.
71 • Delusional??? (by Greg Tillerberg on 2012-08-23 05:11:18 GMT from United States)
Patrick says:
"We have realized you know better than us developers, O Almightly User. You are all-knowing and wise, O Almightly User. We developers have no idea what we're doing, O Almighty User, and we have sinned. Please forgive us."
Talk about delusional.
Not at all.. what IS real is that many so called developers are usually young, green, and exhibit the "I want to be a hero" syndrome.. thus create unnecessary solutions in need of a problem to fix. This situation does NOT lead to a good evolution and can be very bad in the end for everyone.
72 • Systemd Is Making Improvements??? (by Greg Tillerberg on 2012-08-23 05:43:28 GMT from United States)
Adam Williamson says:
The whole point of what we're saying is that systemd isn't about 'fixing problems' but about 'making improvements'
You are just kidding.. right? Taking basic, simple, well understood, and very important system functions and combining them into an tangled web of complex over-done and over-rated functionality that then takes reading a book sized manual to use it.. with associated config files scattered everywhere.. is making an improvement? No sir, this is going backwards, ALOT. Improvement? Not even a little.
73 • systemd parallelism (by zykoda on 2012-08-23 13:40:34 GMT from United Kingdom)
That parallelism is a major driving force towards systemd seems fickle. That there are other reasons for its inception remain. For instance achieving 90-95 parallelism on a 32 processor (core) system only gives double the speed. There is little further to be gained how ever many processors participate: (Amdahl's Law).
74 • #31(Adam) (by jack on 2012-08-23 13:50:06 GMT from Canada)
The 'UNIX design philosophy' hasn't been applicable to an entire operating system for, oh, a couple of decades at least.
This can be contrasted with Linus Torvalds view (from "Just for Fun".published 2001. p.54)
What is special about Unix is the set of fundamental ideals that it strives for.It is a clean and beautiful operating system.It avoids special cases.Unix has the notion of processes-- a process is anything that does anything
75 • @71 (by Patrick on 2012-08-23 14:10:27 GMT from United States)
"""Not at all.. what IS real is that many so called developers are usually young, green, and exhibit the "I want to be a hero" syndrome.. thus create unnecessary solutions in need of a problem to fix. This situation does NOT lead to a good evolution and can be very bad in the end for everyone."""
You're right. Young developers that think more of themselves than they should. Guys like Linus Torvalds. There already was BSD, Hurd was under development, Minix existed. There really was no need for some young whippersnapper to start his own thing.
76 • @60 Gnome 3 (by DavidEF on 2012-08-23 14:32:22 GMT from United States)
Patrick,
You're right, there is no sure-fire way to please all the users all the time. But, consulting the users before making major interface changes still makes sense to me, if users are important at all. If I was making a product mainly for my own use, secondarily sharing with others, I would do it the way I wanted, and the others could use it or not. But, if I was making the product mainly for others, and myself was just one of many "others" using it, I would want to know what the majority thought would be the most useful. That's my only point. Both ways are right, just a difference of focus. The more people you consult before making major changes to how THEY USE the product, the better your chances of "keeping it between the ditches" as far as your users are concerned.
Having said all that, and my other posts as well, I think I may need to clarify my personal position on all this. I don't really have a problem with Gnome 3. I think it's better than Gnome 2 in a long list of ways. I personally use Unity, and like it a little better than Gnome 3. But, I'm in the minority it seems. And, I guess, you are too. Unless all the outcry against Unity and Gnome 3 are just a case of "vocal minority".
77 • @64 Pulse Audio (by DavidEF on 2012-08-23 14:48:24 GMT from United States)
I think Pulse Audio was adopted because it was the first real solution with the potential to fix all the problems the distros were facing with audio. And the distro maintainers probably thought the users would be ecstatic. But, lots of people had lots of very real, very serious issues with Pulse Audio (and I'll add ALSA too, since it's already been mentioned).
After thinking long and hard about it, I've come to the conclusion that Pulse Audio is not "junk" in every sense. It was just not ready. It was alpha grade, being taken up by a lot of distros as final grade. I'd say now it is a lot better, maybe even just before RC grade. But, the shortest answer any user could give in those early days was simply "junk", because usability and configurability were simply not there, or at least very hard to come by.
I don't know about systemd, but I'm afraid it might be deja vu all over again, and I'm not ready for that. A little more patience and caution on the part of distro maintainers would often be appreciated.
78 • @75 Starting your own thing (by DavidEF on 2012-08-23 14:59:53 GMT from United States)
Patrick,
Linus Torvalds was starting his own thing for his own purpose. I don't think anyone here has a problem with that. When a developers' "own thing" affects anywhere from thousands to millions of established users, it becomes a concern for the users. I think that makes perfect sense. Remember too, most users aren't compiling our own anymore, like it used to be. We take what we're given. We're gonna be unhappy if it messes up our workflow significantly, because we have no recourse. Once we've got it, we're stuck with it.
79 • @DavidEF (by Patrick on 2012-08-23 17:34:18 GMT from United States)
"""I've come to the conclusion that Pulse Audio is not "junk" in every sense. It was just not ready."""
I agree that PulseAudio had issues when it was first incorporated into distros, and wasn't really ready yet for prime time. One could say that distros should have waiting longer, but on the other hand, if it hadn't been thrown to the lions at it was, it probably would have progressed much slower and would not have reached the maturity it has now. As it was, I can understand why distros were so eager to have it, since its functionality was desperately needed. Still, it gave PulseAudio a bad name, but I don't think it's fair to blame it for a bad decision on the part of many distro developers.
Another thing that gives PulseAudio a bad name is that many distros install with bad default ALSA volume settings. I've seen many installs that have the ALSA volume at zero by default, and since PulseAudio doesn't touch the hardware, changing its volume makes squat difference. PulseAudio is happily doing its thing, but its output is effectively muted by ALSA. Then when people get rid of PulseAudio, the volume slider is tied to ALSA's volume instead, and sound suddenly works. The result is that PulseAudio gets blamed for making sound not work, while the blame should be squarely on the shoulders of the distro developer. I've fixed this problem several times by using alsa-mixer to set the ALSA volumes correctly, and when that's done audio works just fine with PulseAudio.
"""Linus Torvalds was starting his own thing for his own purpose. I don't think anyone here has a problem with that. When a developers' "own thing" affects anywhere from thousands to millions of established users, it becomes a concern for the users."""
Nobody here has any problem with that. But I am sure many people with vested interests did have, and still have problems with it. Many established players would have dearly wished that he's never done his "own thing".
I'm sure that if systemd becomes established, 20 years down the road, we will feel just the same about it as we do today about the Linux kernel, and the general opinion will be to wonder why anyone ever had a problem with it. Everything that's established now was new at one point, with people questioning why it was even needed.
80 • Fashion trends (by Bemused Dabbler on 2012-08-23 18:47:33 GMT from United States)
If a distro says it's "bleeding-edge", compulsive fiddle-with geeks may flock to it, because it appeals to their sense of fashion. Helps explain early adoption of alpha-grade software. A typical Linux trade-off. OSS needed work, someone forks to ALSA. ALSA needs work, someone forks to PulseAudio. Each more complex, and thus more appealing; simplicity suffers in the short term as the less competent overestimate their wit.
But eventually some real genius conceives an elegant solution, and Keep-It-Short+Simple is reborn.
81 • @79 agree (by DavidEF on 2012-08-23 19:46:51 GMT from United States)
Patrick,
""I'm sure that if systemd becomes established, 20 years down the road, we will feel just the same about it as we do today about the Linux kernel, and the general opinion will be to wonder why anyone ever had a problem with it. Everything that's established now was new at one point, with people questioning why it was even needed.""
You may be right about the future of Pulse Audio and systemd, and I fully agree with this last statement of yours. But in the interim, the users are right to complain about as-yet incomplete and buggy software being pushed on us, no matter how "awesome" it is destined to become. If I've not made it clear yet, that is what everything I've said boils down to. Also, I do blame the distro vendors, not any developer, for pushing Pulse Audio on us in an unusable condition.
82 • "Forcing" distros to do anything (by Pearson on 2012-08-23 20:28:40 GMT from United States)
I've read a lot hear about distsros being "forced" to adopt a technology, or how "choice" is being removed. Those are strong words, but also have grains of truth in them.
Red Hat has place itself, or has been placed, into a position of great influence. The greater the influence, the more weight the decisions carry. I think I read a stat that they are primary contributors to the kernel source and perhaps other portions of Linux.
So, if Red Hat decides to adopt a new technology, their decision will be seen as having a lot of weight, perhaps even "the future of Linux" ("As Maine goes, so goes the nation"). While Red Hat likely isn't "forcing" anyone to adopt systemd, they certainly will -- intentionally or not -- influence a great many distros to follow their lead.
83 • @72 (by Adam Williamson on 2012-08-23 21:57:24 GMT from Canada)
I'm not going to argue with useless, vague generalizations. What's the point? If you're not going to go to the trouble of understanding how systemd is designed and why it's designed that way, then there's just no point.
84 • systemd (by Caitlyn Martin on 2012-08-23 21:58:31 GMT from United States)
systemd has been in the last four versions of Fedora, starting as a "technology preview" in Fedora 14 and as the default in Fedora 15, 16 and 17. It's also been picked up by other distros since it was introduced. It's well tested by now and it really does work well. Comparisons to PulseAudio when it was first introduced might have been apropos two years ago. It certainly isn't the case now.
From #72: "Taking basic, simple, well understood, and very important system functions and combining them into an tangled web of complex over-done and over-rated functionality that then takes reading a book sized manual to use it.. with associated config files scattered everywhere.. is making an improvement?"
There is nothing simple about the old init system with scripts for each service, K and S files for each run level, etc... It was and is positively Byzantine. It's "well understood" only because a lot of us have worked with it for a very long time. When you get down to understanding systemd it is not more complex, not over-done, and the additional functionality has a great deal of value. You also now have a single command line tool that lets you do most of the administration tasks related to system initialization in systemctl. Managing and administering a system with systemd is much easier than doing the same with the old init scripts once you know how. I really suggest that before people jump to conclusions that they take the time to read the explanation of systemd in the Fedora wiki at: http://fedoraproject.org/wiki/Systemd
Also, regarding the size of the manual and documentation, I'd point out that an equally detailed explanation of how system initialization works under systems using SysVinit isn't any shorter. Read the documentation on it that came with Red Hat Enterprise Linux 4 as a good example. The fact is that you don't need to read every detail about how it works under the hood to begin working effectively with systemd. There is a nice, short, to the point guide that is more than adequate.
I find it really sad that well respected and talented developers like Eric Hameleers and Andreas Viklund are fear mongering at this point. The resistance to change in the Linux community, even among technically sharp and capable people, is absolutely mind boggling to me.
Most of the objections I read aren't technical at all. They really boil down to "the old system worked" and objections to having to learn something new. Guess what? To succeed in IT you always have to be learning something new. It's part of the job description. For ordinary, non-technical users the change is pretty well transparent and won't really effect much of anything they do on a regular basis.
85 • "..book sized manual.." (by Jordan on 2012-08-23 22:41:58 GMT from United States)
Haven't needed one. Are we talking about linux distros? Sheesh not even Slackware needs a manual. Guidelines are cool, especially for the shell, but no books unless we want to build one ourselves or argue in here. :oD
86 • Quote from reference (by Bemused on 2012-08-24 00:55:13 GMT from United States)
"implements an elaborate transactional dependency-based service control logic"
Perhaps someday some number theorist will come up with something not "elaborate", even though we're dealing with hardware and software foibles, which is indeed like herding cats.
Meanwhile, well said, Caitlyn! We get more than enough FUD from outside.
Number of Comments: 86
Display mode: DWW Only • Comments Only • Both DWW and Comments
| | |
| TUXEDO |
TUXEDO Computers - Linux Hardware in a tailor made suite
Choose from a wide range of laptops and PCs in various sizes and shapes at TUXEDOComputers.com. Every machine comes pre-installed and ready-to-run with Linux. Full 24 months of warranty and lifetime support included!
Learn more about our full service package and all benefits from buying at TUXEDO.
|
| Archives |
| • Issue 1117 (2025-04-14): Shebang 25.0, EndeavourOS 2025.03.19, running applications from other distros on the desktop, Debian gets APT upgrade, Mint introduces OEM options for LMDE, postmarketOS packages GNOME 48 and COSMIC, Redox testing USB support |
| • Issue 1116 (2025-04-07): The Sense HAT, Android and mobile operating systems, FreeBSD improves on laptops, openSUSE publishes many new updates, Fedora appoints new Project Leader, UBports testing VoLTE |
| • Issue 1115 (2025-03-31): GrapheneOS 2025, the rise of portable package formats, MidnightBSD and openSUSE experiment with new package management features, Plank dock reborn, key infrastructure projects lose funding, postmarketOS to focus on reliability |
| • Issue 1114 (2025-03-24): Bazzite 41, checking which processes are writing to disk, Rocky unveils new Hardened branch, GNOME 48 released, generating images for the Raspberry Pi |
| • Issue 1113 (2025-03-17): MocaccinoOS 1.8.1, how to contribute to open source, Murena extends on-line installer, Garuda tests COSMIC edition, Ubuntu to replace coreutils with Rust alternatives, Chimera Linux drops RISC-V builds |
| • Issue 1112 (2025-03-10): Solus 4.7, distros which work with Secure Boot, UBports publishes bug fix, postmarketOS considers a new name, Debian running on Android |
| • Issue 1111 (2025-03-03): Orbitiny 0.01, the effect of Ubuntu Core Desktop, Gentoo offers disk images, elementary OS invites feature ideas, FreeBSD starts PinePhone Pro port, Mint warns of upcoming Firefox issue |
| • Issue 1110 (2025-02-24): iodeOS 6.0, learning to program, Arch retiring old repositories, openSUSE makes progress on reproducible builds, Fedora is getting more serious about open hardware, Tails changes its install instructions to offer better privacy, Murena's de-Googled tablet goes on sale |
| • Issue 1109 (2025-02-17): Rhino Linux 2025.1, MX Linux 23.5 with Xfce 4.20, replacing X.Org tools with Wayland tools, GhostBSD moving its base to FreeBSD -RELEASE, Redox stabilizes its ABI, UBports testing 24.04, Asahi changing its leadership, OBS in dispute with Fedora |
| • Issue 1108 (2025-02-10): Serpent OS 0.24.6, Aurora, sharing swap between distros, Peppermint tries Void base, GTK removinglegacy technologies, Red Hat plans more AI tools for Fedora, TrueNAS merges its editions |
| • Issue 1107 (2025-02-03): siduction 2024.1.0, timing tasks, Lomiri ported to postmarketOS, Alpine joins Open Collective, a new desktop for Linux called Orbitiny |
| • Issue 1106 (2025-01-27): Adelie Linux 1.0 Beta 6, Pop!_OS 24.04 Alpha 5, detecting whether a process is inside a virtual machine, drawing graphics to NetBSD terminal, Nix ported to FreeBSD, GhostBSD hosting desktop conference |
| • Issue 1105 (2025-01-20): CentOS 10 Stream, old Flatpak bundles in software centres, Haiku ports Iceweasel, Oracle shows off debugging tools, rsync vulnerability patched |
| • Issue 1104 (2025-01-13): DAT Linux 2.0, Silly things to do with a minimal computer, Budgie prepares Wayland only releases, SteamOS coming to third-party devices, Murena upgrades its base |
| • Issue 1103 (2025-01-06): elementary OS 8.0, filtering ads with Pi-hole, Debian testing its installer, Pop!_OS faces delays, Ubuntu Studio upgrades not working, Absolute discontinued |
| • Issue 1102 (2024-12-23): Best distros of 2024, changing a process name, Fedora to expand Btrfs support and releases Asahi Remix 41, openSUSE patches out security sandbox and donations from Bottles while ending support for Leap 15.5 |
| • Issue 1101 (2024-12-16): GhostBSD 24.10.1, sending attachments from the command line, openSUSE shows off GPU assignment tool, UBports publishes security update, Murena launches its first tablet, Xfce 4.20 released |
| • Issue 1100 (2024-12-09): Oreon 9.3, differences in speed, IPFire's new appliance, Fedora Asahi Remix gets new video drivers, openSUSE Leap Micro updated, Redox OS running Redox OS |
| • Issue 1099 (2024-12-02): AnduinOS 1.0.1, measuring RAM usage, SUSE continues rebranding efforts, UBports prepares for next major version, Murena offering non-NFC phone |
| • Issue 1098 (2024-11-25): Linux Lite 7.2, backing up specific folders, Murena and Fairphone partner in fair trade deal, Arch installer gets new text interface, Ubuntu security tool patched |
| • Issue 1097 (2024-11-18): Chimera Linux vs Chimera OS, choosing between AlmaLinux and Debian, Fedora elevates KDE spin to an edition, Fedora previews new installer, KDE testing its own distro, Qubes-style isolation coming to FreeBSD |
| • Issue 1096 (2024-11-11): Bazzite 40, Playtron OS Alpha 1, Tucana Linux 3.1, detecting Screen sessions, Redox imports COSMIC software centre, FreeBSD booting on the PinePhone Pro, LXQt supports Wayland window managers |
| • Issue 1095 (2024-11-04): Fedora 41 Kinoite, transferring applications between computers, openSUSE Tumbleweed receives multiple upgrades, Ubuntu testing compiler optimizations, Mint partners with Framework |
| • Issue 1094 (2024-10-28): DebLight OS 1, backing up crontab, AlmaLinux introduces Litten branch, openSUSE unveils refreshed look, Ubuntu turns 20
| | • Issue 1093 (2024-10-21): Kubuntu 24.10, atomic vs immutable distributions, Debian upgrading Perl packages, UBports adding VoLTE support, Android to gain native GNU/Linux application support |
| • Issue 1092 (2024-10-14): FunOS 24.04.1, a home directory inside a file, work starts of openSUSE Leap 16.0, improvements in Haiku, KDE neon upgrades its base |
| • Issue 1091 (2024-10-07): Redox OS 0.9.0, Unified package management vs universal package formats, Redox begins RISC-V port, Mint polishes interface, Qubes certifies new laptop |
| • Issue 1090 (2024-09-30): Rhino Linux 2024.2, commercial distros with alternative desktops, Valve seeks to improve Wayland performance, HardenedBSD parterns with Protectli, Tails merges with Tor Project, Quantum Leap partners with the FreeBSD Foundation |
| • Issue 1089 (2024-09-23): Expirion 6.0, openKylin 2.0, managing configuration files, the future of Linux development, fixing bugs in Haiku, Slackware packages dracut |
| • Issue 1088 (2024-09-16): PorteuX 1.6, migrating from Windows 10 to which Linux distro, making NetBSD immutable, AlmaLinux offers hardware certification, Mint updates old APT tools |
| • Issue 1087 (2024-09-09): COSMIC desktop, running cron jobs at variable times, UBports highlights new apps, HardenedBSD offers work around for FreeBSD change, Debian considers how to cull old packages, systemd ported to musl |
| • Issue 1086 (2024-09-02): Vanilla OS 2, command line tips for simple tasks, FreeBSD receives investment from STF, openSUSE Tumbleweed update can break network connections, Debian refreshes media |
| • Issue 1085 (2024-08-26): Nobara 40, OpenMandriva 24.07 "ROME", distros which include source code, FreeBSD publishes quarterly report, Microsoft updates breaks Linux in dual-boot environments |
| • Issue 1084 (2024-08-19): Liya 2.0, dual boot with encryption, Haiku introduces performance improvements, Gentoo dropping IA-64, Redcore merges major upgrade |
| • Issue 1083 (2024-08-12): TrueNAS 24.04.2 "SCALE", Linux distros for smartphones, Redox OS introduces web server, PipeWire exposes battery drain on Linux, Canonical updates kernel version policy |
| • Issue 1082 (2024-08-05): Linux Mint 22, taking snapshots of UFS on FreeBSD, openSUSE updates Tumbleweed and Aeon, Debian creates Tiny QA Tasks, Manjaro testing immutable images |
| • Issue 1081 (2024-07-29): SysLinuxOS 12.4, OpenBSD gain hardware acceleration, Slackware changes kernel naming, Mint publishes upgrade instructions |
| • Issue 1080 (2024-07-22): Running GNU/Linux on Android with Andronix, protecting network services, Solus dropping AppArmor and Snap, openSUSE Aeon Desktop gaining full disk encryption, SUSE asks openSUSE to change its branding |
| • Issue 1079 (2024-07-15): Ubuntu Core 24, hiding files on Linux, Fedora dropping X11 packages on Workstation, Red Hat phasing out GRUB, new OpenSSH vulnerability, FreeBSD speeds up release cycle, UBports testing new first-run wizard |
| • Issue 1078 (2024-07-08): Changing init software, server machines running desktop environments, OpenSSH vulnerability patched, Peppermint launches new edition, HardenedBSD updates ports |
| • Issue 1077 (2024-07-01): The Unity and Lomiri interfaces, different distros for different tasks, Ubuntu plans to run Wayland on NVIDIA cards, openSUSE updates Leap Micro, Debian releases refreshed media, UBports gaining contact synchronisation, FreeDOS celebrates its 30th anniversary |
| • Issue 1076 (2024-06-24): openSUSE 15.6, what makes Linux unique, SUSE Liberty Linux to support CentOS Linux 7, SLE receives 19 years of support, openSUSE testing Leap Micro edition |
| • Issue 1075 (2024-06-17): Redox OS, X11 and Wayland on the BSDs, AlmaLinux releases Pi build, Canonical announces RISC-V laptop with Ubuntu, key changes in systemd |
| • Issue 1074 (2024-06-10): Endless OS 6.0.0, distros with init diversity, Mint to filter unverified Flatpaks, Debian adds systemd-boot options, Redox adopts COSMIC desktop, OpenSSH gains new security features |
| • Issue 1073 (2024-06-03): LXQt 2.0.0, an overview of Linux desktop environments, Canonical partners with Milk-V, openSUSE introduces new features in Aeon Desktop, Fedora mirrors see rise in traffic, Wayland adds OpenBSD support |
| • Issue 1072 (2024-05-27): Manjaro 24.0, comparing init software, OpenBSD ports Plasma 6, Arch community debates mirror requirements, ThinOS to upgrade its FreeBSD core |
| • Issue 1071 (2024-05-20): Archcraft 2024.04.06, common command line mistakes, ReactOS imports WINE improvements, Haiku makes adjusting themes easier, NetBSD takes a stand against code generated by chatbots |
| • Issue 1070 (2024-05-13): Damn Small Linux 2024, hiding kernel messages during boot, Red Hat offers AI edition, new web browser for UBports, Fedora Asahi Remix 40 released, Qubes extends support for version 4.1 |
| • Issue 1069 (2024-05-06): Ubuntu 24.04, installing packages in alternative locations, systemd creates sudo alternative, Mint encourages XApps collaboration, FreeBSD publishes quarterly update |
| • Issue 1068 (2024-04-29): Fedora 40, transforming one distro into another, Debian elects new Project Leader, Red Hat extends support cycle, Emmabuntus adds accessibility features, Canonical's new security features |
| • Issue 1067 (2024-04-22): LocalSend for transferring files, detecting supported CPU architecure levels, new visual design for APT, Fedora and openSUSE working on reproducible builds, LXQt released, AlmaLinux re-adds hardware support |
| • Issue 1066 (2024-04-15): Fun projects to do with the Raspberry Pi and PinePhone, installing new software on fixed-release distributions, improving GNOME Terminal performance, Mint testing new repository mirrors, Gentoo becomes a Software In the Public Interest project |
| • Full list of all issues |
| Star Labs |
Star Labs - Laptops built for Linux.
View our range including the highly anticipated StarFighter. Available with coreboot open-source firmware and a choice of Ubuntu, elementary, Manjaro and more. Visit Star Labs for information, to buy and get support.
|
| Random Distribution | 
MIRACLE LINUX
MIRACLE LINUX is a Japanese Linux distribution based on Red Hat Enterprise Linux. The distribution is free to use, with a 10-year support, but users can opt for a paid support provided by a company called Cybertrust, Inc. MIRACLE LINUX started as a high performance back-end server for business workgroups in the enterprise, with several specialist editions, such as MIRACLE LINUX for PostgreSQL, MIRACLE LINUX with Oracle and MIRACLE LINUX Server OS. It was also part of the Asianux consortium, now discontinued, together with some high-profile Linux distribution projects developed in China and Korea.
Status: Active
|
| TUXEDO |
TUXEDO Computers - Linux Hardware in a tailor made suite
Choose from a wide range of laptops and PCs in various sizes and shapes at TUXEDOComputers.com. Every machine comes pre-installed and ready-to-run with Linux. Full 24 months of warranty and lifetime support included!
Learn more about our full service package and all benefits from buying at TUXEDO.
|
| Star Labs |
Star Labs - Laptops built for Linux.
View our range including the highly anticipated StarFighter. Available with coreboot open-source firmware and a choice of Ubuntu, elementary, Manjaro and more. Visit Star Labs for information, to buy and get support.
|
|
• 
• 
• 
• 
• 
• 
• 
