NSA: Please Turn off the Lights When You Leave. Nothing to See Here.

Linux Advocate Dietrich Schmitz shows how the general public can take action to truly protect their privacy using GnuPG with Evolution email. Read the details.

Mailvelope for Chrome: PGP Encrypted Email Made Easy

Linux Advocate Dietrich Schmitz officially endorses what he deems is a truly secure, easy to use PGP email encryption program. Read the details.

Step off Microsoft's License Treadmill to FOSS Linux

Linux Advocate Dietrich Schmitz reminds CIOs that XP Desktops destined for MS end of life support can be reprovisioned with FOSS Linux to run like brand new. Read how.

Bitcoin is NOT Money -- it's a Commodity

Linux Advocate shares news that the U.S. Treasury will treat Bitcoin as a Commodity 'Investment'. Read the details.

Google Drive Gets a Failing Grade on Privacy Protection

Linux Advocate Dietrich Schmitz puts out a public service privacy warning. Google Drive gets a failing grade on protecting your privacy.

Email: A Fundamentally Broken System

Email needs an overhaul. Privacy must be integrated.

Opinion

Cookie Cutter Distros Don't Cut It

Opinion

The 'Linux Inside' Stigma - It's real and it's a problem.

U.S. Patent and Trademark Office Turn a Deaf Ear

Linux Advocate Dietrich Schmitz reminds readers of a long ago failed petition by Mathematician Prof. Donald Knuth for stopping issuance of Software Patents.

Showing posts with label Systemd. Show all posts
Showing posts with label Systemd. Show all posts

Friday, August 22, 2014

Cry Babies Cry. Programmers Code.

A schism of sorts is forming in the Debian developer community as one developer has gone on record to formally criticize Debian's decision to adopt systemd in an Open Letter to the Linux World.

Here's what I have to say to Mr. Christopher Barry and others who may agree with his viewpoint.  Accept it.  Systemd is a done deal.  It's here for good reasons whether you realize it or not.  But I hope you eventually grasp why it was written, as it does solve many inherent 'known' problems with aged sysvinit.

And, as expected, a chorus of cry babies has been awoken, like sleeping dogs, taking aim (again) at systemd.


Those who complain in this instance, I am afraid, have a simple agenda.  


They are lazy.

As such and with much creativity they will persist lodging complaints so as to avoid doing some difficult, but not insurmountable, work.  Yes, there are many pain points in addressing merging systemd PID 1 code that are due to its 'middleware' central/critical role, which result in dependency changes and in some cases some major code rewrites that must be done to conform with this new technology standard.

Ah, standard.  There's the rub.  There are legions of arrogant, swaggering Open Source code jockeys who like to strut their stuff by spinning off their 'me too' Distro with their own branding overnight.  Have you taken a count of how many Linux Distributions there are now?


Standardization strengthens the power of Linux.  Distro sprawl does not.

The planned integration of systemd is now officially deployed to Debian Jessie Beta 1. This means that all the 'foot dragger' derivatives must follow suit with doing what is needed to align with this major system design change.





So, while we see some dig in their heels by organizing a boycott, others choose to simply whine, as the din gets louder and louder.  Soon, though, the cry babies will run out of tears, pick up their toys, and go home whilst the real-world Programmers continue to keep their heads down, doing the grunt work with little fanfare and nary a complaint.

Cry Babies cry.  Programmers code.  -- Dietrich

Thursday, April 24, 2014

Two stories critical of systemd taken offline

by Dietrich Schmitz


There are two stories I wrote last year in progression as I waded through a sea of technical information regarding systemd.

The two taken in totality paint a picture that would represent I am against systemd.

In a follow-on story, I continue my technical evaluation of the merits of systemd including cgroups.

My conclusion then and today is that systemd is, on net, a technology advancement which I accept and use today in Fedora 20.

A site has recently been using one of those stories as reference material in a campaign to boycott systemd.  I do not wish to be associated with any such campaign.

Accordingly, I have taken off-line those two stories which are now inconsistent with my viewpoint.  

People can change their minds about things, and often do, as I have done.

All hail Lennart Poettering.  -- Dietrich




Saturday, February 15, 2014

Debian, Ubuntu Cave In: Standardize on Systemd

by Dietrich Schmitz


It's almost too painful to watch.  Really.  

Whenever Debian gets around to getting off their collective hands and coming to grips with reality, it's as though a new Pope were being selected and we are all waiting with great anticipation for the 'smoke signal' indicating a decision has been made.

Good grief.  This is what constitutes progress for Linux.  It's really border-line funny how Debian committees work through the pros and cons of adopting Upstart vs. systemd.

Do these Folks realize they are running the risk of becoming irrelevant in their inaction while the earth continues to turn on its axis?  Seriously, systemd is a foregone conclusion and while it took time for me to digest the technical issues during the past year, I do see its importance.

The thing is, this does represent not only a technical advancement, but also galvanizes the Distro community into a level of conformance which begets standardization.

Oh there's the standardization word again.  I said it.

Let me pose a hypothetical question for you developers out there:

What would happen if you dropped all of your current development efforts on your Distro X and enlisted to work on one mainstream Top 5 Distro, such as Fedora?

Think about that question for a moment.  What would you be giving up and what would you be gaining?

The initial knee-jerk reaction might be to say "I'd be losing my right to choice".  But would you?

Is the act of being independent and creating variation 'because I can' and "it's my right" of higher importance than say putting forth the effort to build a superior singular Distro?  Imagine if you would, hundreds, thousands of developers going to work on one Distro.  Leveraging the intellectual resources and manpower would be amazing.

But wait, all of that 'variation'?  It would fall to the wayside and we as developers could all focus on working with one software API, one file hierarchy structure.  The effect would be the same as if overnight we all chose Android and focused on application development in that ecosystem.

Honestly, I wonder where Linux will wind up and hope that if consolidation occurs as I predict, more effort will be redirected to a single Distro which can be forged, annealed, hardened to become as popular as Windows.

The success of Windows is as much about a monopoly as it is about one standard, one api, which was embraced and flourished.  Microsoft Windows legacy 8 is aged and I believe we have reached a turning point where Corporate Enterprise knows it must do something to unshackle itself from a marriage to an ever-restrictive proprietary solution.

Mark Shuttleworth acts like a defeated Man in his Losing Graciously concession to adopting systemd.  It's silly.  Look at the big picture.

One Distro, one API, with thousands of developers behind it, is a powerful thing.

-- Dietrich 

Enhanced by Zemanta

Tuesday, November 5, 2013

Does it really matter?


by Daniel Sandman

I have lately contemplated over Linux and it's market share on desktop. We have seen a little upswing the last year and depending who you ask it is somewhere between 1.6-3 percent of all desktop computers. It's a small percentage but what people tend to forget is that it is a HUGE number. There are around 2 billion desktop computers running in the world today. The estimation is hard to do but it's the general number I tend to see on this. So that means it would be roughly 30-60 million desktop computers running with Linux in today's world. Not a small number. Even if you only took a third of that number it would still be 10 million computers which are actively being used. That is a lot of people.

I mean how many people do we need to have an active ecosystem? I have no clue, but would guess a couple of thousand is enough. That means a couple of thousands technical users. Those who can develop and maintain. It's a non-issue for desktop Linux currently. It's always nice to have a couple of more developers but a general feel is that we are good. So I have no fear to be honest. As long as we grow I am good. It doesn't need to jump several percentages to make me happy. Just a steady slow grow is enough and that is how it looks today. For me it's more important the openness is preserved than a market majority.

Sure I am happy to see Valve and gang joining the club. I mean it is good to have the choice. It also improves the support for drivers and hardware which could be better on Linux. I am not complaining though. My hardware on my machines has worked more or less flawlessly since 2008 or so.

So does it really matter?

Yes, I think so. The state of Linux today are big changes. We are watching Linux being commercialized at a rate never seen before. Android and ChromeOS have been good for Linux but Google are no RedHat. Sure RedHat do have some proprietary solutions but mainly aimed at enterprise. With Google we get core functionality like the distribution of software closed off. That is an essential difference from what we are used to. We are seeing Canonical taking steps toward a similar business model and others are surely thinking of it too. Heck even Apple have a similar solution with some parts open but others not. Is this the future of open source? Is the future a mix of open and close?

Maybe. I hope it is not but money talk and Linux is dependant on businesses donating developers to make code. In a perfect world this would not be needed but the world today is anything but perfect. Just because we need some commercialization does not mean I am happy about Google and Canonical. I wish they could have taken a more similar approach to RedHat and SUSE which base their revenue on support. If so it would have meant they might have not felt the need to use CLA and closed source on core functionality. So my main concern today lay in the commercialization of Linux and what that might bring us tomorrow. Not so much in the actual percentage of market share.

It could be fine but it could also mean that openness proves to be a failure. I hope on the former. We have to stay vigilant and especially on software with core functionality that is not open and demand opening them up. The danger lay in dependence on commercial software with core functionality. We as a community can not allow such things to happen. If we do it would mean the end of openness and the end of Linux as we know it.

So to me supporting Systemd, Wayland and Bodega are important for the future of Linux.


Enhanced by Zemanta

Wednesday, October 30, 2013

The Debian Init System Deba{te|cle}

by Dietrich Schmitz


Debian Linux has had a long-standing reputation of being staid and pragmatic in their decision-making.  Even their software release management policy is on the long side when compared with other Distros.  A typical 2-year software cycle just doesn't cut it in today's Internet World operating at the 'speed of light'.

So, it would appear, the time has come for Debian's maintainers to make a decision as to which init system to adopt going forward.


While Debian 7 Squeeze includes systemd as an installable option, the default init system is sysvinit.


The debate currently being conducted at Debian is whether they should move to Upstart (used by Canonical Ltd.'s Ubuntu Linux), or, to systemd instead, going forward and as such a position statement has just been drafted on the Debian wiki site.



Sysvinit Disadvantages


The Debian Team has had many years of good results using sysvinit, but recognize it's limits are now beginning to show strain.  And with a feature freeze for Debian 8 nearing, they must determine which init system will become the new default replacement for the aged sysvinit.  


Here is their list of disadvantages for using sysvinit going forward:



  • Sysvinit lacks service supervision. While /etc/inittab provides this capability, management of /etc/inittab is quite restrictive. Upstart eliminates the need for complicated PID file handling for all services. There are bolt-ons that allow you to do service supervision on top of sysvinit, such as runit, but it's clear that these are bolt-ons.
  • Sysvinit does not track dependencies between services. Insserv/startpar provides this on top of sysvinit, but this is again very much a bolt-on, and only handles dependencies at boot/shutdown time (i.e., during runlevel changes) and can't handle any complicated service interdependencies at runtime. Upstart expresses this information in the native service configuration format, clearly and concisely.
  • Sysvinit requires complex shell scripts for each service. While some of the complexity has been abstracted out into common helpers (lsb-functions; start-stop-daemon), having to represent each service's start/stop handling as a program is a severe handicap. Upstart jobs are simple, declarative, easy to maintain, and easy to modify locally as needed. They also eliminate the longstanding nuisance of update-rc.d reactivating services behind the administrator's back on upgrade.
  • Sysvinit is linear. It stopped being a good fit for boot management on Debian the moment Debian adopted udev. There are many race conditions that persist in Debian today when booting with sysvinit, and although these may be fixable, the complexity for fixing them with sysvinit is very high. We're better off switching to an init system that's designed to work together with the event-based kernel and udev.

Upstart vs. SystemD

Clearly, Debian developers recognize that the time has come to make a change.  

In the opinion of the author(s) of the position statement, it would seem to place both init systems on equal footing insofar as features are concerned: 

"In terms of overall feature uplift of the init system itself, there is really rather little to distinguish upstart from systemd. Both would represent a huge step forward for Debian over sysvinit. If Debian did not adopt upstart, systemd would certainly be my second choice."
Looking further for some substantive information in the position statement, the author(s) go on to make some subjective comparisons:


But despite the init systems being comparable at the feature level, there are reasons that I think upstart is a better fit for Debian than systemd.
  • SystemD is Linux-specific. Upstream has been very clear that they are not interested in accepting porting patches to enable systemd to be used with kernels other than the Linux kernel. If Debian wishes to continue to support non-Linux ports, this significantly reduces the benefit that maintainers would gain from having a simpler init format to support.
  • SystemD is hasty. Debian is late to the party when it comes to adopting a better init system, but systemd is evolving rapidly and does not have a long track record of backwards-compatibility that it can point to. While systemd is unlikely to break any interfaces that upstream has promised to maintain, I think there is a risk that newer dependencies will be driven by the version requirements in Fedora and RHEL, leaving Debian to fend for itself with respect to sorting out rocky transitions on upgrade - not unlike the problematic udev transitions of the past. Upstart is committed to maintaining compatibility across stable releases of Debian, just as it currently does between Ubuntu LTS releases. While upstart seeks to leverage newer kernel features where this makes sense, we are committed to having sane upgrade paths and not depend on such kernel features prematurely.
  • SystemD is "greedy". Most of the recent arguments about why it's dangerous to adopt upstart instead of systemd center around features that are being built into systemd in a manner that can't be separated out (e.g., cgroup management in PID 1). There is an advantage to the implementor to put these features in-process in init, because it ensures early availability with no concerns about startup ordering at boot, but it commits downstreams to a monolithic design with respect to parts of the system architecture which are not settled questions in the wider ecosystem. Debian should take a principled position regarding its future architecture, and not find itself at the mercy of other parties who wish to dictate design to us.
So, it is apparent the author(s) are in favor of Upstart but would 'consider' systemd, yet, go on to reinforce with additional reasons why Upstart should be considered over systemd.

As though that were not enough, Google Plus user and Intel employee/Gnome community member +Sriram Ramkrishna  threw his opinion into the mix characterizing the whole subject as having morphed from its original purpose.  Ramkrishna writes:


"...the whole debian systemd discussion has turned into a referendum on GNOME being the default DE for Debian with those who want to switch advocating switching to XFCE as I would imagine that it works closest to what GNOME 2. Why they didn't pick Mate, I don't understand if they want the GNOME 2 experience.

The discussion seems to miss the fact that they would miss out on Wayland and moving to a new display server? They can of course do what they want as that is their prerogative. But it seems that long simmering resentment against GNOME and the change in UI has risen to the fore with the small dependency that GNOME has on systemd. They are using that as an excuse to drive a change in DE.
There are a lot of good reason to use systemd, all that has been rehashed. But the biggest nonsense I've read (as an IT guy) is the fact that we should have a choice in init systems. What the fuck? Essentially people just want to make every part of the OS to be hot swappable. Who would want to support such a system? Who will QA all these combinations? It's madness!..."
However valid the reasons set forth in the Upstart vs. systemd position statement may be, the level of emotion rises whenever a discussion is had concerning moving to +Lennart Poettering's  systemd.  Personally, I believe in the long-term systemd will become the best option receiving full support from the Linux Foundation's kernel.org developers insofar as plans to merge udev and systemd into the kernel are concerned.

The concern is that Debian's pragmatism may work against them and cause a backlog queue of software development issues.  So, acting in a timely fashion in today's world is vital to remaining competitive for any Linux Distribution.  

Hopefully, the Debian Team have recognized this and will respond by making adjustments to how their organizational structure and decision making process works to result in overall efficiency improvements.


As for the Debian init system issue, my money is on Debian going with Upstart, since that was the system chosen by Canonical Ltd. for Ubuntu and Mark Shuttleworth has no intention in making a change any time soon.  This would put both Distros and their derivatives in alignment with each other going forward and efficiencies would obtain.


Here's hoping Debian reaches a decision which best serves their future needs.


-- Dietrich

Enhanced by Zemanta

Monday, October 21, 2013

Elitist Mark Shuttleworth Exhibits Temper Tantrum

by Dietrich Schmitz


So, this past Thursday, October 17, 2013, Canonical Ltd. released Ubuntu 13.10 Saucy Salamander.

A post from Canonical's "Self-Appointed Benevolent Dictator for Life", Mark Shuttleworthappeared the next day.

Honestly, I think what Canonical Ltd. have done insofar as supporting Wayland from its inception up to the point of general release, only to then spring an announcement for Mir, was blatantly transparent and a power grab to seize strategic control of ongoing Display technology driver development. (Image credit: http://oralhealthmatters.blogspot.com)

The end result is that this decision has substantially left Unity on its own island with a 'one of a kind' display driver technology which, as it turns out, nobody is interested in adopting.  The crowd of Distros are all making plans to eventually move to Wayland, at the right time of course, but staying with tried and true X.org for the time being.

Good Decisions, Bad Decisions


So, how exactly does a company make decisions of this kind?  At the very least, one wonders to what extent this is a company driven by any kind of Democratic consensus building.  It would seem, whilst Canonical Ltd. fill the heads of their Developers with the notion that they are 'community' and that their opinions matter,  actions speak louder than words, showing what has been largely regarded as questionable decision making and most likely coming directly from the top.

Smart Scopes, Not so Smart


Take Smart Scopes, for example.  Why would anyone want to forego using an Internet browser to do their web-centric tasks, instead, on the Desktop?  And, why would anyone want to have their privacy details shared with a Canonical Ltd. server to boot?  How does this make sense?  And how is that even the 'smart' thing to do?  Fortunately, Canonical Ltd. saw fit to allow the end user toggle Lens and Smart Scopes features off entirely with a global setting switch.  But this so-called 'feature enhancement' is there now, like it or not.

Arrogance, Elitism, We Know Best


It's one more 'in your face' example of the Canonical Ltd. 'elitist' 'we know what is good for you' mentality which is being fed to the end-user via a 'force feed' funnel method.

Arrogance is such that it can lead those in power to become reckless and lose sight of common sense practical ways of doing things.

It's Our Way or the Highway  


Starting with Unity in Ubuntu 11.04 came the 'parting of the ways' with upstream involvement on shared community decision making (regarding ongoing Gnome development).  Through a series of software revision cycles, Unity evolved further with Canonical taking key pieces of Wayland's infrastructure so as to ensure full control of their own branded Mir Display technology.   At present, Xmir/Mir is only an option with 13.10, but the next version and thereafter will lend full support to Mir display technology and quite possibly no 'fall-back' option for end users.

No, Mr. Shuttleworth is not a happy camper.  It is quite evident in his temper-tantrum post and he goes so far as to label in broad strokes anyone who challenges him as part of the 'Open Source Tea Party'.  Now, in my estimation, that is simply bad form and really underscores his lack of maturity.

No, he's not content to stop there.  He even takes shots at the fine work done by Lennart Poettering and Kay Sievers, on Systemd.

Here's an excerpt of what Mr. Shuttleworth wrote:

"Mir is really important work. When lots of competitors attack a project on purely political grounds, you have to wonder what THEIR agenda is. At least we know now who belongs to the Open Source Tea Party And to put all the hue and cry into context: Mir is relevant for approximately 1% of all developers, just those who think about shell development. Every app developer will consume Mir through their toolkit. By contrast, those same outraged individuals have NIH’d just about every important piece of the stack they can get their hands on… most notably SystemD, which is hugely invasive and hardly justified. What closely to see how competitors to Canonical torture the English language in their efforts to justify how those toolkits should support Windows but not Mir. But we’ll get it done, and it will be amazing."

Unlike Ubuntu, which still employs Upstart, many Distros have already adopted Systemd without hesitation.  There are hold-outs, but the vast majority appear to be in favor of it.

So, why is Mr. Shuttleworth firing volleys across the bows of so many?  It's an interesting question.

Might it be that Mir is encountering difficulties and the continued splintering of derivatives grows as opposition mounts against it use?

On-ramp to Wayland


What Mir has done is essentially drive a wedge into the community and a parting of the ways is occurring as Developers are forced to make a choice as to when to stop supporting X.org and with what technology.  I reached +Aaron Seigo (image right) to have his view on the state of the art in Display Server technology.  Here's what he had to say:

"The KDE community has had a long-term roadmap for Wayland adoption that we've been executing over the last two years. We routinely reexamine such roadmaps to ensure they remain sensible. The broad community and industry support for Wayland, our confidence in the proven team behind it and the high quality releases we've seen thus far have convinced us to stay the course on Wayland. Foundation technologies such as Qt have had high quality Wayland support for several releases and key components for the Plasma Workspace such as the KWin window manager have seen initial work completed. We expect Plasma on Wayland to be ready for production support during the Plasma 2 lifecycle, the next major release which we are currently working on. Having a consistent experience across as much of the technology stack as possible is valuable to our users and partners, and so we are very happy to join the likes of Intel, Red Hat, Jolla, Tizen, GNOME and many others large and small on the road to Wayland."

Conclusions


That's a solid endorsement for Wayland and despite what the future holds for Xmir/Mir, the message is clear: there will be an 'on ramp' for Developers to take in replacement of X.org.

It's not a good sign nor becoming of an Executive Officer to be making such inflammatory statements about those with whom he must cooperate to ensure the success of Linux for many years to come.  Whether or not he intends to 'mend his fence' remains to be seen but it would not only be in his best interests to extend apologies for his inappropriate remarks but also the right thing to do.

-- Dietrich
Enhanced by Zemanta

Sunday, May 19, 2013

Mageia 3 Arrives: All Grown Up and Ready to Go Dancing

by Dietrich Schmitz

After a several project milestone delays, Mageia 3 was finally released today and featuring a new logo (two, shown right and left) with special thanks going out to its designer, Nicholas Duval.

"We still can’t believe how much fun it is to make Mageia together, and we’ve been doing it for two and a half years.
For people who can’t wait,get it here; release notes are here. To upgrade from Mageia 2, see here.", writes +Trish Fraser in the Mageia blog announcement.

On a sad note, she writes:

"Before we get to the rest of the information: we dedicate this release to the memory of Eugeni Dodonov, our friend, our colleague and a great inspiration to those he left behind. We miss his brilliance, his courtesy and his dedication."


What's New?


Mageia 3 includes a raft of updated Applications and Packages as well as these new features:

  • Updates to RPM (4.11) and urpmi, which has been given a good Mageia turnout and cleanup
  • Kernel 3.8
  • systemd 195
  • GRUB is the default bootloader; GRUB2 is available to test.
  • Revamped package groupings for installation and rpmdrake
  • KDE 4.10.2
  • GNOME 3.6.
  • Xfce 4.10
  • Libreoffice 4.0.3

Special Thanks

Trish adds not leastly special thanks reminding readers that Mageia would not be possible without the help of those in the community who selflessly gave of their time in fulfillment of the project, including the valued sponsors Gandi and Ielo:

"Our heartfelt thanks go to all the people who donated their time to make this release possible, and all the people who donated money allowing us to buy the servers that we use to build the distribution."

-- Dietrich





Enhanced by Zemanta

Friday, May 10, 2013

cgroups: A BIG WIN for Systemd

by Dietrich Schmitz

Oh dear.  What have I done?  :/


I am afraid I have stirred up a hornets nest.  With several related articles under my belt regarding systemd, I continue to pursue this subject matter because of its great importance.

As an advocate, it is important to be critical.  It is also important to turn things over and see things in as objective thinking as is possible, looking for the merit. (Image credit: Red Hat)

Today, I focus on some of the merit that has many so enthusiastic about systemd.

In particular, cgroups, a new technology in the Linux Kernel has been integrated into systemd.

What Matters to System Administrators and Users?


The truth is, most users won't even see or give a hoot about cgroups or systemd, nor will they care anything about their Distro other than how they use it for every day things.  And that is to be expected.

But to the Linux System Administrator who must keep servers numbering in the hundreds or more stable and running without interruption, the devil is in the details and necessarily they must know and understand systemd to accomplish routine configuration changes and to respond to situations that require attention such as when a daemon service becomes unresponsive and must be bounced (stop/start).  These kinds of things are what System Administrators do and the process of learning new technology is a necessary ingredient to staying on the cutting edge and maintaining proficiency.

So, I've spent considerable time poking at systemd, yes?  This time I look at why, just why, maybe there is merit in employing systemd.  Now, many of you are ready to take issue with me, but please remember my role here.  Advocacy is 'for' and 'against' so I've been most often against certain things.  Putting aside how systemd was designed (merging udev) and what that did to the larger Distro community, cgroups does indeed offer something quite good.


The Return of the Zombies


You see it often.  A 'Zombie' child process or an unresponsive daemon service requires your attention.  It is a source of continual maintenance when a service goes silent or one of its child processes does and the whole daemon service shuts down randomly with no explanation.  System Administrators say: "It just happens now and then, that's why we run Nagios to stay on top of it."

That's fine and tools like Big Brother and Nagios are what is needed in this context.  But does systemd offer a finer degree of control given that it has croups embedded?

The answer is yes.

cgroups and Why They are Important

To the extent that Red Hat has a vested interest in the furtherance of systemd and plan to deploy such technology in their next iteration of Red Hat Enterprise Linux 7, much, if not all, of the work being done thus far on systemd has been undertaken by one of their employees +Lennart Poettering.  To his credit, Lennart has been around the corner, so to speak, and has a track record for writing many complicated projects, including PulseAudio.   

So, where can one find more about cgroups?  It just so happens that Red Hat have been doing their own homework, per usual, and have many on-line resource materials that help educate the System Administrator, including some good information about cgroups here.

In the course of discussion in the comment section of my website, one article, stirred the hearts of many to come forward and respond.  One individual has done a good job of giving good constructive replies and demonstrates a better understanding of systemd than perhaps any other respondent I have read.  In my story: Systemd: An Accident Waiting to Happen, Peter Dolding writes:












Shell scripts don't trace processes. This is the problem scripts and items like it work as long as everything is well behaved.

As soon as you get malfuncting service. Solaris zones or linux cgroups around it keeping track of every process it starts. Becomes a good send. 
The problem for over 30 years the same thing:
1) init starts a service process.
2) The service process starts some other sub process it needs.
3) The service process gets terminated to restart
4) The sub process stays running.
5) service started falls over in a heap because sub process is still alive. 
That 1 to 5 (rundown) to your normal init systems includes (Ubuntu's) upstart. 
Solaris and systemd due to usage of zones and cgroups (respectively): 
1) init starts a service process wrapped.
2) The service process starts some other sub process it needs.
3) The service process gets terminated to restart
4) The sub process stays running.
5) Init system checks if anything is left in the cgroup or zone that should have been terminated.
6) service restarted stable.
This is why the old system is broken Dietrich.
Is systemd the right fix needs to be the question--not putting your head in sand and pretending problem does not exist. 
Dietrich the other big thing you have missed is that udev is going into the Linux kernel. As a kernel feature. BSD and other operating systems really have to catch up. 
There are major performance issues running udev userspace. There is also security issues runnign udev userspace. There will be no need for systemd to look after udev long term. Because udev will not exist.
Instead kernel udev will be used.
It's the same kicking and screaming over moving video card memory management into kernel space.
This is nicely put.  I have yet to see anyone explain it better and in such concise terms.  Well done Peter Dolding.


Conclusion


If more people will step back from the issue and wrap their minds around the above, I think it will help them to grasp what is happening to Linux in the long term.  Does breaking compatibility with things related to BSD matter?  I am not sure on that.  Debian chose to make systemd an opt-in choice for their just released Debian 7 Wheezy project, specifically because it does break GNU/kFreeBSD.

I want to believe their is merit in systemd and so, in this round, I am looking at the glass 'half-full' as opposed to being 'half-empty'.  

I pledge to l continue, in investigatory fashion, to examine all things which effect Linux, turning them over to see them from different perspectives.  That is necessary to being a good advocate.

With that, I hope this post has done some good.  What are your thoughts?

-- Dietrich




Enhanced by Zemanta

Wednesday, May 8, 2013

Systemd: Got Choice?

by Dietrich Schmitz

I've been thinking over the whole systemd issue and have written several stories about it.

It seems to me that somehow a major tenet of Linux has been overlooked:



CHOICE

When exactly did choice go out the window?

I want to know why systemd is not an 'opt-in' configurable option?

Did I miss something?  No, I am afraid I didn't.

No, the whole situation has really been simmering in my mind and as I did more research on systemd, the only conclusion I can reach is that systemd is being foist upon us without a shred of consideration being given to 'choice'.

There is no recognition of or respect given to choice when a Distro simply removes sysvinit or any of the other fine initialization schemes in favor of systemd.

This represents a violation of a major tenet of Linux that I cherish and don't appreciate having simply taken away from me.  Choice is mine.  I can let someone else make a decision for me, or, I can seize control and decide for myself what is best for me.  Someone else has decided that systemd is best for everyone.  Well, guess what?  It isn't.  And you don't have to accept it.  There are still Distros which don't use systemd and some that actually do give you the option to use it.

As far as I am concerned, this is a grievous error and every user should protect their given right to choose what is best for their situation.

Making systemd an opt-in configurable choice should have been given top priority.

If you don't protect your right to choice, who else will?

Today, as a matter of principle, I am taking action on this issue and resolve to do something about it.  Taking choice away is wrong and elitist at best.

I will fill you in later in a follow up story.

-- Dietrich
Enhanced by Zemanta