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.
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.
Linux Advocate Dietrich Schmitz reminds readers of a long ago failed petition by Mathematician Prof. Donald Knuth for stopping issuance of Software Patents.
More than ever, we need to give thanks as part of our American yearly custom of celebrating Thanksgiving on the fourth Thursday of November.
It's not about the harvest. Nor is it about the President 'pardoning' a Turkey or religious proclamations made by Church priesthood in any secular sense.
No, we should not lose sight of what initially formed as the 'Pilgrim' holiday during the early 1600's in New England. Pilgrim and Puritan immigrants from England brought their traditions to New England in the form of Days of Fasting and Days of Thanksgiving celebration.
It might make more sense to have such celebration following when the 'real' harvest bounty occurs, but history being what it is, the date chosen for Thanksgiving changed over time, most recently to the fourth Thursday of November from the last with a resolution made by President Roosevelt in 1941.
In terms of what we should be thankful for in the Linux Community, I feel the strongest consideration should go to the Gnu Public License from which a great bounty or code base sprang forth. This bounty remains the stock of open source software that keeps giving of itself over and over, thanks to one Richard Stallman. We should never forget that without such a novel licensing framework in place, the success of a Linux kernel and its 'moving parts' in the open source 'factory' would not have been possible.
So, remember as you celebrate this holiday that giving back to the FOSS community is essential, or, we would still be under the rigid control of monopolistic proprietary software vendors the likes of Microsoft and Apple.
Thanksgiving wishes go out for a continued thriving Linux FOSS harvest! -- Dietrich
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 DebianJessie 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.
Finally, an agreement has been reached with Canonical to support Lubuntu for Long-Term Service (LTS) in the next release cycle (14.04).
There is much work to be done and Lubuntu is looking for your help. Pitch in whenever and wherever you can to make Lubuntu 14.04 LTS a success! (Image credit: Wikipedia.org)
Here's a video explaining the process for moving to LTS:
Best Wishes to the Lubuntu Developer Team for a successful outcome!
I've been living with Netrunner 13.06 Enigma for about a week now and am still quite happy with it.
Yet, I am not satisfied to just use any Distro with its 'out of the box' setting for long before the urge sets in to make changes.
Mostly, for my purposes, I want the ram footprint of the GUI to be as small as it can possibly be. (Image credit: smithsonianmag.com)
Where KDE is concerned, while it does weigh in in the 400MB+ range at start-up the Acer Aspire One D260 in default configuration is quite acceptable speed-wise. I half-expected that would not be the case and was happy to know the system was carrying the weight of a full KDE Plasma Workspace implementation nicely.
So, the lust to tweak set in and here's what I did.
Unneeded Services
I disabled the following services
Akonadi (set StartServer=false in ~/.config/akonadi/akonadiserverrc)
cups and cups-browserd (sudo update-rc.d -f cups remove && update-rc.d -f cups-browserd remove)
krunner
Added the below contents to file ~/.kde/share/autostart/krunner.desktop
klipper (sudo apt-get purge klipper)
nepomuk (off by default; set autostart=false in ~/.kde/share/config/nepomukserverrc)
3D Effects
System Settings, Workspace Appearance, Desktop Effect, uncheck 'Enable Desktop Effects at Startup' and on the Advanced tab, switched from OpenGL to xrender.
Other Services
In system settings, Advanced, Service Manager, I unchecked and stopped:
DNS-SD
Drive Ejector (my Netbook has no CD drive)
Free Space Notifier (I've never run out of disk space)
Nepomuk Search Module
Remote URL Change Notifier
Wacom Tablet (don't have one)
Write Daemon
System Settings, Desktop Appearance, Widget Style, Configure, Animations, I unchecked 'Enable Animations'.
Preload
Preload uses caching algorithms to intelligently preload software based on your user habits. I installed with:
sudo apt-get install preload
zram
I've been using zram for several days. I will tell you that this change alone will make a big change in the speed of any PC -- it doesn't matter how much ram it has. In fact, it's going to be present in the Kernel 3.11 as zswap, but currently, it exists if you are using a Linux kernel 3.2 or greater as zram. Users of Netrunner get a 3.8 kernel with the 'bonus' of an enhanced LZO compression library.
The command to install:
sudo apt-get install zram-config.
There isn't anything else you need to configure for zram -- it is now mapped and loaded as a kernel module (zram.ko) to two block swap devices with the name /dev/zram[n] where n is the core of your PC. In my case with the Atom N450, it's /dev/zram0 and /dev/zram1.
If you would like to see your zram swap activity, I would suggest installing ncurses-based 'glances' (sudo apt-get install glances).
So, that's it. Now things are absolutely 'honkin' fast.
P.S. those using Fedora will find zram installables here.
Using a Netbook has both advantages and disadvantages. Mine, an Acer Aspire One D260 (Intel Atom N450) came with 1GB DDR2 ram. I added another 1GB to bring it up to 2GB ram total. (Image credit: wallpaperswa.com)
Overall, using the Netbook has been a great value proposition. Because Linux does so well with limited ram, some Distros better than others, I've managed to get along just fine.
Very recently, I made a switch from Fedora 19 to Netrunner 13.06 Enigma and have been doing various tweaks of the Desktop to configure it to my liking.
Very little in fact, needed to be changed from the start, which speaks well for KDE and Blue Systems. Blue Systems, in particular, have done a superb job in putting together Enigma.
By chance today, I came upon a feature which landed in the Linux kernel 3.2, called zRAM.
If your PC has 2GB ram or less, then zRAM is for you. In Linux kernel 3.8, a new LZO compression library update is present that in testing shows roughly double speed improvements for compression/decompression.
zRAM uses LZO to create compressed swap space in RAM.
Beyond the install step, there's no special configuration required -- zRAM loads on boot and sets itself up in RAM with a higher priority than your default swap partition. The result is that zRAM is engaged first, if full, then your SDD/HDD partition will do the more I/O-intensive swapping which, of course, is vastly slower.
I've been using zRAM all day and must say it was well worth the trouble of installing. The speed improvement is pronounced. And it just so happens Enigma, released this past Friday (July 5) uses a 3.8 kernel. So the newest LZO compression library is installed also.
Using Chrome typically is memory-instensive and if I open 6 or more tabs, I notice swapping begins to slow things down. I usually am careful about closing unneeded tabs just as soon as I am done with them to avoid hitting that memory maxed-out wall where swapping starts to kick in.
Now, I have not hit the 'wall' once since installing zRAM and everything snaps to screen as though this machine was equipped with 4GB of ram. I kid you not.
So, if you have a machine with 2GB ram or less, I strongly recommend you give zRAM a try, and especially if you are using Linux kernel 3.8 or greater.
A few months ago, we saw the newest Pixel Chromebook arrive on the scene with superior display and other performance characteristics -- arguably as good as Apple's Retina MacBook line.
Now another adjustment to Chrome was announced in May for the official development of Google Chrome Packaged Apps. This page explains packaged apps in further detail and includes a video.
If you watch the video which tries to explain what Packaged Apps are, Google talk euphemistically in terms which won't say we're writing local Apps, but if you read between the lines, that's really what they are doing. Pay close attention Folks, these won't be half-baked Javscript Apps. No, they'll be running with Native Client (NaCl) C/C++ compiled executables which are the fastest compiled code one can have driving any application. Here's a brief text explaining what to expect when running a packaged app:
How they behave
Packaged app pages always load locally. This allows apps to be less dependent on the network. Once a user installs an app, they have full control over the app's lifecycle. Apps open and close quickly, and the system can shut apps down at any time to improve performance. Users can fully uninstall apps.
Without any effort on your part, your apps will launch offline. But you will need to put some effort into making sure user data is stored locally while offline and then synced back up to your data server once online (see Offline First).
You see, the Apps will be free-standing and so will run outside of the browser, but still use their fork of WebKit, called Blink, which is at the heart of Chrome. Blink won't be recognizable after they've finished refactoring and tearing out the parts they don't want--it has been reported they already have removed over 8.8 millions lines of code.
And that's another thing they did which is beginning to make more sense. They now can modify the WebKit code to their heart's content to satisfy both browser and packaged apps as they see fit without upstream hassles.
So, that leaves us where?
It leaves us with the proposition that Google know there is still a need for good local Desktop software, a la the days of Microsoft Windows past, only they aren't saying it. Microsoft still have a market for Windows-based legacy x86 software which have always had the performance characteristics and the gold standard applications which so many still rely upon today and Google know they can't capture this traditional buyer's market without local Apps. Local Apps still rule.
Initially, it seems they released a photography-driven app which comes pre-installed on the Pixel Chromebook.
And rest assured, there will be others to follow. Applications fuel sales. It's that simple.
With the recent disclosure of the NSA PRISM surveillance program, that leaves a major stigma attached to doing anything in the Cloud, which can potentially hinder sales of their Cloud-based Chromebook. How long that stigma stays around remains to be seen, but, Google isn't placing all of their eggs in one basket.
Realistically, Google can go in any direction after whatever market they choose--and they usually do. They have the know-how, cash, and have shown themselves to be quite capable at software development--innovative in fact, much to Microsoft's disliking and worry.
Can Google pull off writing a decent Office clone packaged App? If they did, that might really send sales through the roof. All they have to do is make up their minds to do it and it will happen, which should be one of the major concerns at One Microsoft Way.
So, watch the video above and see if you agree with my thinking.
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
There hasn't been a time that I can recall over the past year that when I check the Distrowatch ranking that Mageia wasn't in the top 5.
It goes to show that this Distro has legs and has the essential attributes of a thorough-bred commercial Distribution.
That's because in spite of its community status, Mageia is a fork of commercial Distro Mandriva Linux.
Yet, while successful Mageia 2 was released in May 2012 and has a lot to offer, it seems that the Mageia community have been having their fair share of unforeseen project delays in keeping to milestones in their Mageia 3 release schedule.
Anticipating that the release was nearing, I decided to try their beta1 and beta2 releases. Unfortunately, in each attempt to install, the X server crashed and I stopped there, thinking that perhaps waiting for a release candidate was in order. It's to be expected in the beta phase for sure, so I paid no attention to it and moved on.
According to an announcement made on the Mageia Blog, the 'final release' date (May 3rd) is once again going to be postponed to May 18, 2013, for the third time.
Looking at their Systemd Features page indicates many unfulfilled items related to migration. This being an accepted feature has, no doubt, been a major contributor to at least some of the project delays. In the same Mageia blog post, volunteers are also encouraged to participate and contribute to the project work at hand.
I say, 'haste makes waste' and the Mageia Team will, in due course, work through these issues with care. So please. Be patient.
The premise has always been that open source development should thrive and be guided by consensus and openness.
Consensus in the sense that a community who share in the development of a given application or Linux Distro energizes participation and guides teamwork when all recognize they have a role in moving toward a desired group goal in a cooperative effort.
The idea that computer software source code can be shared and reused and improved, provided that such changes to code are given back is central to the open source Gnu Public License v2.
No effort to move forward under the GPLv2 License is more symbolic than the collective work embodied by the Linux Kernel.
Many projects have been produced using the GPL as the basis for development for various 'moving parts' of the Linux Distribution (Distro), including system middle-ware components, utilities, and graphical Desktop Environments all working together in concert, meshing seamlessly to render the Distro experience.
To a large extent each software project has its own community with various responsibilities that combine to achieve the project's goals. Communities around a project vary in size and as the organization dictates the size will grow according to the demands and initiatives undertaken by its members.
When consensus is taken and the feedback results in new design decisions and new feature enhancements, new branches of code are created to facilitate new major software revisions. Committers who officially contribute code to a project typically store their changes in a central repository using Internet software revision control systems such as Git, or Subversion. Revision control software will carefully track 'deliverables' and maintain versioning of a project through its software life cycle.
But when consensus is made but not incorporated into a decision making process, there is no longer a continuity between goals and objectives that everyone can accept.
The decisions made by a few people in power and only those people is being referred to here in this context as Elitism.
Risks of Operating in an Elitist Environment
By default, Elitism is exclusionary and ignores shared responsibility in the decision making process for a given project or organization. Elitism promotes social stratification and division and gives those few decision makers a sense of privileged special status.
The risks inherent in working for an organization or for a project which is controlled by Elitism is that morale will suffer as team members discover their input on decisions doesn't matter.
Often Defeatist Elitism takes control of an otherwise open decision making process where the individual charged with making the final choice will with impunity put down or discourage collaboration and either verbally or in writing show dissatisfaction toward individuals bringing their own ideas to a group discussion.
In addition to harming morale, members in a group effort will be less inclined to take initiative and do independent learning, and many will become exasperated at seeing their work or ideas not being given credit and simply resign from active participation.
This can hurt the reputation of the organization or project and result in a loss of competing market share. The level of risk for having made a bad strategic decision and continuing to support its advancement increases in likelihood, despite however bad the choice was or the probability of failure is, under an elitist's tight control.
Signs of Elitism
Watching the progress of Canonical, it is becoming increasingly evident that the culture of Ubuntu software development is severely hampered by the elitist behavior of Mark Shuttleworth:
Making a choice to move to Unity and choke off support for rearward compatibility with Gnome 2.3x feature sets is magnified by the proliferation of third-party utilities to tweak the GUI and fill major feature regressions.
Radical changes to remove a traditional, intuitive Menu Structure (Gnome 2.3x Applications Places System Menu) in favor of 'searching' for an application is a strong warning sign that common sense traditional methods have taken a back seat to whimsical ideas and a 'we know best' what users need on their Desktop.
Devoting major development efforts in Unity to allow searches of Amazon from the Desktop (vs. a browser) is another warning sign that in the shadow of one Man's elitist control, the direction and reputation of Ubuntu have taken a U-turn away from acceptable use in violation of users' privacy rights. In spite of cries discouraging its implementation, the Amazon Lens went into Ubuntu 12.10 but has since included a system toggle to disable it by default.
Despite being an up-hill battle with little chance of gaining significant market share, Canonical now has plans to build a smartphone running Ubuntu with Unity, only called Ubuntu Touch.
Conclusion
So, the danger of an open source project's goals being precluded and derailed by Elitism are a big concern. One might say even, the risk that Ubuntu is leaning towards becoming proprietary is not out of the realm of possibility.
Ubuntu Linux--It's one big flashing road side billboard Folks--Elitism at work.
