 DistroWatch Weekly |
| 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 1121 (2025-05-12): Bluefin 41, custom file manager actions, openSUSE joins End of 10 while dropping Deepin desktop, Fedora offers tips for building atomic distros, Ubuntu considers replacing sudo with sudo-rs |
| • Issue 1120 (2025-05-05): CachyOS 250330, what it means when a distro breaks, Kali updates repository key, Trinity receives an update, UBports tests directory encryption, Gentoo faces losing key infrastructure |
| • Issue 1119 (2025-04-28): Ubuntu MATE 25.04, what is missing from Linux, CachyOS ships OCCT, Debian enters soft freeze, Fedora discusses removing X11 session from GNOME, Murena plans business services, NetBSD on a Wii |
| • Issue 1118 (2025-04-21): Fedora 42, strange characters in Vim, Nitrux introduces new package tools, Fedora extends reproducibility efforts, PINE64 updates multiple devices running Debian |
| • 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 |
| • 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 | 
Gnoppix Linux
Gnoppix is a Debian and Kali Linux-based distribution which can be run from a DVD, USB thumb drive or from a local drive. It can resume previous sessions while running in a live mode. The distribution attempts to clean up after itself, removing all traces of its use from the computer or used media. Prior to version 22, Gnoppix was a Knoppix-based distribution and live medium featuring the GNOME desktop.
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.
|
|
• 
• 
• 
• 
• 
• 
• 
