How To Move Multiple File Types Simultaneously From Commandline

The other day I was wondering how can I move (not copy) multiple file types from directory to another. I already knew how to find and copy certain type of files from one directory to another. But, I don’t know how to move multiple file types simultaneously. If you’re ever in a situation like this, I know a easy way to do it from commandline in Unix-like systems.

Move Multiple File Types Simultaneously

Picture this scenario.You have multiple type of files, for example .pdf, .doc, .mp3, .mp4, .txt etc., on a directory named ‘dir1’. Let us take a look at the dir1 contents:

$ ls dir1
file.txt image.jpg mydoc.doc personal.pdf song.mp3 video.mp4

You want to move some of the file types (not all of them) to different location. For  example, let us say you want to move doc, pdf and txt files only to another directory named ‘dir2’ in one go.

To copy .doc, .pdf and .txt files from dir1 to dir2 simultaneously, the command would be:

$ mv dir1/*.{doc,pdf,txt} dir2/

It’s easy, isn’t it?

Now, let us check the contents of dir2:

$ ls dir2/
file.txt mydoc.doc personal.pdf

See? Only the file types .doc, .pdf and .txt from dir1 have been moved to dir2.

mv command

You can add as many file types as you want to inside curly braces in the above command to move them across different directories. The above command just works fine for me on Bash.

Another way to move multiple file types is go to the source directory i.e dir1 in our case:

$ cd ~/dir1

And, move file types of your choice to the destination (E.g dir2) as shown below.

$ mv *.doc *.txt *.pdf /home/sk/dir2/

To move all files having a particular extension, for example .doc only, run:

$ mv dir1/*.doc dir2/

For more details, refer man pages.

$ man mv

Moving a few number of same or different file types is easy! You could do this with couple mouse clicks in GUI mode or use a one-liner command in CLI mode. However, If you have thousands of different file types in a directory and wanted to move multiple file types to different directory in one go, it would be a cumbersome task. To me, the above method did the job easily! If you know any other one-liner commands to move multiple file types at a time, please share it in the comment section below. I will check and update the guide accordingly.

And, that’s all for now. Hope this was useful. More good stuffs to come. Stay tuned!

Cheers!

Source

NTFS Read/Write Filesystem Addon for Linux

Nice to see my submission right here 🙂 Really fast Eugenia !

I have downloaded and tested captive-ntfs on a notebook (Sony Vaio) here running Fedora Core 1. These are so far my impressions:

– installation of the RPM worked perfectly (it also scans the hdd for ntfs drives and creates entries in /etc/fstab plus the

directories in /mnt )

– first mount is slower than the Linux native NTFS driver from kernel

– read/write seems to work okay at the beginning….BUT i recognized a problem with big files. For example i tried to watch a movie sitting on one of my ntfs partitions…after 10 minutes or so mplayer stops. When i try to continue the playback mplayer loads and then just quits with “file ended”…really curious.

– i also once had a CPU raise to 100% for a few moments after mplayer stops working.

Maybe this is a bug or maybe it´s just because i used the RPM package which is not approved for Fedora (RedHat 9 was tested).

Any others share the same experience here ?

Source

Key Resources for Effective, Professional Open Source Management

The Linux Foundation offers an abundance of resources to help you achieve success with open source.

At organizations everywhere, managing the use of open source software well requires the participation of business executives, the legal team, software architecture, software development and maintenance staff and product managers. One of the most significant challenges is integrating all of these functions with their very different points of view into a coherent and efficient set of practices.

More than ever, it makes sense to investigate the many free and inexpensive resources for open source management that are available, and observe the practices of professional open source offices that have been launched within companies ranging from Microsoft to Oath to Red Hat.

Fundamentals

The Linux Foundation’s Fundamentals of Professional Open Source Management (LFC210) course is a good place to start. The course is explicitly designed to help individuals in disparate organizational roles understand the best practices for success.

The course is organized around the key phases of developing a professional open source management program:

  • Open Source Software and Open Source Management Basics
  • Open Source Management Strategy
  • Open Source Policy
  • Open Source Processes
  • Open Source Management Program Implementation

Best Practices

The Linux Foundation also offers a free ebook on open source management: Enterprise Open Source: A Practical Introduction. The 45-page ebook can teach you how to accelerate your company’s open source efforts, based on the experience of hundreds of companies spanning more than two decades of professional enterprise open source management. The ebook covers:

  • Why use open source
  • Various open source business models
  • How to develop your own open source strategy
  • Important open source workflow practices
  • Tools and integration

Official open source programs play an increasingly significant role in how DevOps and open source best practices are adopted by organizations, according to a survey conducted by The New Stack and The Linux Foundation (via the TODO Group). More than half of respondents to the survey (53 percent) across many industries said their organization has an open source software program or has plans to establish one.

“More than anything, open source programs are responsible for fostering open source culture,” the survey’s authors have reported. “By creating an open source culture, companies with open source programs see the benefits we’ve previously reported, including increased speed and agility in the development cycle, better license compliance and more awareness of which open source projects a company’s products depend on.”

Free Guides

How can your organization professionally create and manage a successful open source program, with proper policies and a strong organizational structure? The Linux Foundation offers a complete guide to the process, available here for free. The guide covers an array of topics for open source offices including: roles and responsibilities, corporate structures, elements of an open source management program, how to choose and hire an open source program manager, and more.

The free guide also features contributions from open source leaders. “The open source program office is an essential part of any modern company with a reasonably ambitious plan to influence various sectors of software ecosystems,” notes John Mark Walker, Founder of the Open Source Entrepreneur Network (OSEN) in the guide. “If a company wants to increase its influence, clarify its open source messaging, maximize the clout of its projects, or increase the efficiency of its product development, a multifaceted approach to open source programs is essential.”

Interested in even more on professional open source management? Don’t miss The Linux Foundation’s other free guides, which delve into tools for open source management, how to measure the success of an open source program, and much more.

Source

How to Setup DRBD to Replicate Storage on Two CentOS 7 Servers

The DRBD (stands for Distributed Replicated Block Device) is a distributed, flexible and versatile replicated storage solution for Linux. It mirrors the content of block devices such as hard disks, partitions, logical volumes etc. between servers. It involves a copy of data on two storage devices, such that if one fails, the data on the other can be used.

You can think of it somewhat like a network RAID 1 configuration with the disks mirrored across servers. However, it operates in a very different way from RAID and even network RAID.

Originally, DRBD was mainly used in high availability (HA) computer clusters, however, starting with version 9, it can be used to deploy cloud storage solutions.

In this article, we will show how to install DRBD in CentOS and briefly demonstrate how to use it to replicate storage (partition) on two servers. This is the perfect article to get your started with using DRBD in Linux.

Testing Environment

For the purpose of this article, we are using two nodes cluster for this setup.

  • Node1: 192.168.56.101 – tecmint.tecmint.lan
  • Node2: 192.168.10.102 – server1.tecmint.lan

Step 1: Installing DRBD Packages

DRBD is implemented as a Linux kernel module. It precisely constitutes a driver for a virtual block device, so it’s established right near the bottom of a system’s I/O stack.

DRBD can be installed from the ELRepo or EPEL repositories. Let’s start by importing the ELRepo package signing key, and enable the repository as shown on both nodes.

# rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org
# rpm -Uvh http://www.elrepo.org/elrepo-release-7.0-3.el7.elrepo.noarch.rpm

Then we can install the DRBD kernel module and utilities on both nodes by running:

# yum install -y kmod-drbd84 drbd84-utils

If you have SELinux enabled, you need to modify the policies to exempt DRBD processes from SELinux control.

# semanage permissive -a drbd_t

In addition, if your system has a firewall enabled (firewalld), you need to add the DRBD port 7789 in the firewall to allow synchronization of data between the two nodes.

Run these commands on the first node:

# firewall-cmd --permanent --add-rich-rule='rule family="ipv4"  source address="192.168.56.102" port port="7789" protocol="tcp" accept'
# firewall-cmd --reload

Then run these commands on second node:

# firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.56.101" port port="7789" protocol="tcp" accept'
# firewall-cmd --reload

Step 2: Preparing Lower-level Storage

Now that we have DRBD installed on the two cluster nodes, we must prepare a roughly identically sized storage area on both nodes. This can be a hard drive partition (or a full physical hard drive), a software RAID device, an LVM Logical Volume or a any other block device type found on your system.

For the purpose of this article, we will create a dummy block device of size 2GB using the dd command.

 
# dd if=/dev/zero of=/dev/sdb1 bs=2024k count=1024

We will assume that this is an unused partition (/dev/sdb1) on a second block device (/dev/sdb) attached to both nodes.

Step 3: Configuring DRBD

DRBD’s main configuration file is located at /etc/drbd.conf and additional config files can be found in the /etc/drbd.d directory.

To replicate storage, we need to add the necessary configurations in the /etc/drbd.d/global_common.conf file which contains the global and common sections of the DRBD configuration and we can define resources in .resfiles.

Let’s make a backup of the original file on both nodes, then then open a new file for editing (use a text editor of your liking).

# mv /etc/drbd.d/global_common.conf /etc/drbd.d/global_common.conf.orig
# vim /etc/drbd.d/global_common.conf 

Add the following lines in in both files:

global {
 usage-count  yes;
}
common {
 net {
  protocol C;
 }
}

Save the file, and then close the editor.

Let’s briefly shade more light on the line protocol C. DRBD supports three distinct replication modes (thus three degrees of replication synchronicity) which are:

  • protocol A: Asynchronous replication protocol; it’s most often used in long distance replication scenarios.
  • protocol B: Semi-synchronous replication protocol aka Memory synchronous protocol.
  • protocol C: commonly used for nodes in short distanced networks; it’s by far, the most commonly used replication protocol in DRBD setups.

Important: The choice of replication protocol influences two factors of your deployment: protection and latency. And throughput, by contrast, is largely independent of the replication protocol selected.

Step 4: Adding a Resource

resource is the collective term that refers to all aspects of a particular replicated data set. We will define our resource in a file called /etc/drbd.d/test.res.

Add the following content to the file, on both nodes (remember to replace the variables in the content with the actual values for your environment).

Take note of the hostnames, we need to specify the network hostname which can be obtained by running the command uname -n.

resource test {
        on tecmint.tecmint.lan {
 		device /dev/drbd0;
       		disk /dev/sdb1;
        		meta-disk internal;	
                	address 192.168.56.101:7789;
        }
        on server1.tecmint.lan  {
		device /dev/drbd0;
        		disk /dev/sdb1;
        		meta-disk internal;
                	address 192.168.56.102:7789;
        }
}
}

where:

  • on hostname: the on section states which host the enclosed configuration statements apply to.
  • test: is the name of the new resource.
  • device /dev/drbd0: specifies the new virtual block device managed by DRBD.
  • disk /dev/sdb1: is the block device partition which is the backing device for the DRBD device.
  • meta-disk: Defines where DRBD stores its metadata. Using Internal means that DRBD stores its meta data on the same physical lower-level device as the actual production data.
  • address: specifies the IP address and port number of the respective node.

Also note that if the options have equal values on both hosts, you can specify them directly in the resource section.

For example the above configuration can be restructured to:

resource test {
	device /dev/drbd0;
	disk /dev/sdb1;
        	meta-disk internal;	
        	on tecmint.tecmint.lan {
 		address 192.168.56.101:7789;
        	}
        	on server1.tecmint.lan  {
		address 192.168.56.102:7789;
        		}
}

Step 4: Initializing and Enabling Resource

To interact with DRBD, we will use the following administration tools which communicate with the kernel module in order to configure and administer DRBD resources:

  • drbdadm: a high-level administration tool of the DRBD.
  • drbdsetup: a lower-level administration tool for to attach DRBD devices with their backing block devices, to set up DRBD device pairs to mirror their backing block devices, and to inspect the configuration of running DRBD devices.
  • Drbdmeta:is the meta data management tool.

After adding all the initial resource configurations, we must bring up the resource on both nodes.

# drbdadm create-md test
Initialize Meta Data Storage

Initialize Meta Data Storage

Next, we should enable the resource, which will attach the resource with its backing device, then it sets replication parameters, and connects the resource to its peer:

# drbdadm up test

Now if you run the lsblk command, you will notice that the DRBD device/volume drbd0 is associated with the backing device /dev/sdb1:

# lsblk
List Block Devices

List Block Devices

To disable the resource, run:

# drbdadm down test

To check the resource status, run the following command (note that the Inconsistent/Inconsistent disk state is expected at this point):

# drbdadm status test
OR
# drbdsetup status test --verbose --statistics 	#for  a more detailed status 
Check Resource Status on Nodes

Check Resource Status on Nodes

Step 5: Set Primary Resource/Source of Initial Device Synchronization

At this stage, DRBD is now ready for operation. We now need to tell it which node should be used as the source of the initial device synchronization.

Run the following command on only one node to start the initial full synchronization:

# drbdadm primary --force test
# drbdadm status test
Set Primary Node for Initial Device

Set Primary Node for Initial Device

Once the synchronization is complete, the status of both disks should be UpToDate.

Step 6: Testing DRBD Setup

Finally, we need to test if the DRBD device will work well for replicated data storage. Remember, we used an empty disk volume, therefore we must create a filesystem on the device, and mount it, to test if we can use it for replicated data storage.

We can create a filesystem on the device with the following command, on the node where we started the initial full synchronization (which has the resource with primary role):

# mkfs -t ext4 /dev/drbd0 
Make Filesystem on Drbd Volume

Make Filesystem on Drbd Volume

Then mount it as shown (you can give the mount point an appropriate name):

# mkdir -p /mnt/DRDB_PRI/
# mount /dev/drbd0 /mnt/DRDB_PRI/

Now copy or create some files in the above mount point and do a long listing using ls command:

# cd /mnt/DRDB_PRI/
# ls -l 
List Contents of Drbd Primary Volume

List Contents of Drbd Primary Volume

Next, unmount the the device (ensure that the mount is not open, change directory after unmounting it to prevent any errors) and change the role of the node from primary to secondary:

# umount /mnt/DRDB_PRI/
# cd
# drbdadm secondary test

On the other node (which has the resource with a secondary role), make it primary, then mount the device on it and perform a long listing of the mount point. If the setup is working fine, all the files stored in the volume should be there:

# drbdadm primary test
# mkdir -p /mnt/DRDB_SEC/
# mount /dev/drbd0 /mnt/DRDB_SEC/
# cd /mnt/DRDB_SEC/
# ls  -l 
Test DRBD Setup Working on Secondary Node

Test DRBD Setup Working on Secondary Node

For more information, see the man pages of the user space administration tools:

# man drbdadm
# man drbdsetup
# man drbdmeta

ReferenceThe DRBD User’s Guide.

Summary

DRBD is extremely flexible and versatile, which makes it a storage replication solution suitable for adding HA to just about any application. In this article, we have shown how to install DRBD in CentOS 7 and briefly demonstrated how to use it to replicate storage.

Source

What metrics matter: A guide for open source projects

“Without data, you’re just a person with an opinion.”

Those are the words of W. Edwards Deming, the champion of statistical process control, who was credited as one of the inspirations for what became known as the Japanese post-war economic miracle of 1950 to 1960. Ironically, Japanese manufacturers like Toyota were far more receptive to Deming’s ideas than General Motors and Ford were.

Community management is certainly an art. It’s about mentoring. It’s about having difficult conversations with people who are hurting the community. It’s about negotiation and compromise. It’s about interacting with other communities. It’s about making connections. In the words of Red Hat’s Diane Mueller, it’s about “nurturing conversations.”

However, it’s also about metrics and data.

Some have much in common with software development projects more broadly. Others are more specific to the management of the community itself. I think of deciding what to measure and how as adhering to five principles.

1. Recognize that behaviors aren’t independent of the measurements you choose to highlight.

In 2008, Daniel Ariely published Predictably Irrational, one of a number of books written around that time that introduced behavioral psychology and behavioral economics to the general public. One memorable quote from that book is the following: “Human beings adjust behavior based on the metrics they’re held against. Anything you measure will impel a person to optimize his score on that metric. What you measure is what you’ll get. Period.”

This shouldn’t be surprising. It’s a finding that’s been repeatedly confirmed by research. It should also be familiar to just about anyone with business experience. It’s certainly not news to anyone in sales management, for example. Base sales reps’ (or their managers’) bonuses solely on revenue, and they’ll try to discount whatever it takes to maximize revenue, even if it puts margin in the toilet. Conversely, want the sales force to push a new product line—which will probably take extra effort—but skip the spiffs? Probably not happening.

And lest you think I’m unfairly picking on sales, this behavior is pervasive, all the way up to the CEO, as Ariely describes in a 2010 Harvard Business Review article: “CEOs care about stock value because that’s how we measure them. If we want to change what they care about, we should change what we measure.”

Developers and other community members are not immune.

2. You need to choose relevant metrics.

There’s a lot of folk wisdom floating around about what’s relevant and important that’s not necessarily true. My colleague Dave Neary offers an example from baseball: “In the late ’90s, the key measurements that were used to measure batter skill were RBI (runs batted in) and batting average (how often a player got on base with a hit, divided by the number of at-bats). The Oakland A’s were the first major league team to recruit based on a different measurement of player performance: on-base percentage. This measures how often they get to first base, regardless of how it happens.”

Indeed, the whole revolution of sabermetrics in baseball and elsewhere, which was popularized in Michael Lewis’ Moneyball, often gets talked about in terms of introducing data in a field that historically was more about gut feel and personal experience. But it was also about taking a game that had actually always been fairly numbers-obsessed and coming up with new metrics based on mostly existing data to better measure player value. (The data revolution going on in sports today is more about collecting much more data through video and other means than was previously available.)

3. Quantity may not lead to quality.

As a corollary, collecting lots of tangential but easy-to-capture data isn’t better than just selecting a few measurements you’ve determined are genuinely useful. In a world where online behavior can be tracked with great granularity and displayed in colorful dashboards, it’s tempting to be distracted by sheer data volume, even when it doesn’t deliver any great insight into community health and trajectory.

This may seem like an obvious point: Why measure something that isn’t relevant? In practice, metrics often get chosen because they’re easy to measure, not because they’re particularly useful. They tend to be more about inputs than outputs: The number of developers. The number of forum posts. The number of commits. Collectively, measures like this often get called vanity metrics. They’re ubiquitous, but most people involved with community management don’t think much of them.

Number of downloads may be the worst of the bunch. It’s true that, at some level, they’re an indication of interest in a project. That’s something. But it’s sufficiently distant from actively using the project, much less engaging with the project deeply, that it’s hard to view downloads as a very useful number.

Is there any harm in these vanity metrics? Yes, to the degree that you start thinking that they’re something to base action on. Probably more seriously, stakeholders like company management or industry observers can come to see them as meaningful indicators of project health.

4. Understand what measurements really mean and how they relate to each other.

Neary makes this point to caution against myopia. “In one project I worked on,” he says, ”some people were concerned about a recent spike in the number of bug reports coming in because it seemed like the project must have serious quality issues to resolve. However, when we looked at the numbers, it turned out that many of the bugs were coming in because a large company had recently started using the project. The increase in bug reports was actually a proxy for a big influx of new users, which was a good thing.”

In practice, you often have to measure through proxies. This isn’t an inherent problem, but the further you get between what you want to measure and what you’re actually measuring, the harder it is to connect the dots. It’s fine to track progress in closing bugs, writing code, and adding new features. However, those don’t necessarily correlate with how happy users are or whether the project is doing a good job of working towards its long-term objectives, whatever those may be.

5. Different measurements serve different purposes.

Some measurements may be non-obvious but useful for tracking the success of a project and community relative to internal goals. Others may be better suited for a press release or other external consumption. For example, as a community manager, you may really care about the number of meetups, mentoring sessions, and virtual briefings your community has held over the past three months. But it’s the number of contributions and contributors that are more likely to grab the headlines. You probably care about those too. But maybe not as much, depending upon your current priorities.

Still, other measurements may relate to the goals of any sponsoring organizations. The measurements most relevant for projects tied to commercial products are likely to be different from pure community efforts.

Because communities differ and goals differ, it’s not possible to simply compile a metrics checklist, but here are some ideas to think about:

Consider qualitative metrics in addition to quantitative ones. Conducting surveys and other studies can be time-consuming, especially if they’re rigorous enough to yield better-than-anecdotal data. It also requires rigor to construct studies so that they can be used to track changes over time. In other words, it’s a lot easier to measure quantitative contributor activity than it is to suss out if the community members are happier about their participation today than they were a year ago. However, given the importance of culture to the health of a community, measuring it in a systematic way can be a worthwhile exercise.

Breadth of community, including how many are unaffiliated with commercial entities, is important for many projects. The greater the breadth, the greater the potential leverage of the open source development process. It can also be instructive to see how companies and individuals are contributing. Projects can be explicitly designed to better accommodate casual contributors.

Are new contributors able to have an impact, or are they ignored? How long does it take for code contributions to get committed? How long does it take for a reported bug to be fixed or otherwise responded to? If they asked a question in a forum, did anyone answer them? In other words, are you letting contributors contribute?

Advancement within the project is also an important metric. Mikeal Rogers of the Node.js community explains: “The shift that we made was to create a support system and an education system to take a user and turn them into a contributor, first at a very low level, and educate them to bring them into the committer pool and eventually into the maintainer pool. The end result of this is that we have a wide range of skill sets. Rather than trying to attract phenomenal developers, we’re creating new phenomenal developers.”

Whatever metrics you choose, don’t forget why you made them metrics in the first place. I find a helpful question to ask is: “What am I going to do with this number?” If the answer is to just put it in a report or in a press release, that’s not a great answer. Metrics should be measurements that tell you either that you’re on the right path or that you need to take specific actions to course-correct.

For this reason, Stormy Peters, who handles community leads at Red Hat, argues for keeping it simple. She writes, “It’s much better to have one or two key metrics than to worry about all the possible metrics. You can capture all the possible metrics, but as a project, you should focus on moving one. It’s also better to have a simple metric that correlates directly to something in the real world than a metric that is a complicated formula or ration between multiple things. As project members make decisions, you want them to be able to intuitively feel whether or not it will affect the project’s key metric in the right direction.”

Source

The developer of Smith and Winston made an interesting blog post about supporting multiple platforms

I recently talked about the Steam release of Smith and Winston but I didn’t realise until late last night, that the developer actually made a very interesting blog post about supporting multiple platforms.

Interesting enough, that it warranted an extra post to talk a little about it. Why? Well, a bit of a situation started when game porter Ethan Lee made a certain Twitter post, which is a bit of a joke aimed at developers who see Linux as “Too niche” while practically falling over themselves to get their games on every other new platform that appears. This Twitter post was shared around (a lot) and some developers (like this) ended up mentioning how Linux doesn’t sell a lot of games and it continued spreading like wildfire.

There’s been a lot of counter-arguments for Linux too, like this and this and this and this and a nice one thrown our way too. Oh and we even spoke to Tommy Refenes who said the next SMB should come to Linux too, so that was awesome. Additionally, Ethan Lee also wrote up a post about packaging Linux games, worth a read if you’re new to packaging for Linux.

Where was I again? Right, the blog post from the developer of Smith and Winston about how they support Windows, Mac and Linux. They go over details about how they do so, from using SDL2 which they say “takes 90% of the pain away from platform support” to the cross-platform rendering library bgfx. It’s just a really interesting insight into how developing across multiple platforms doesn’t have to be overly difficult.

I especially liked these parts:

I’ve been writing games and engines for 30+ years so none of this is new, I have a lot of experience. But you only get the experience by doing it and not making excuses.

By forcing the game through different compilers (Visual C++, Clang and GCC) you find different code bugs (leave the warnings on max). By forcing the runtime to use different memory allocators, threading libraries and rendering technologies you find different runtime bugs. This makes your code way more stable on every platform. Even if you never deploy your code to a non windows platform just running it on Linux or macOS will expose crashes instantly that rarely appear on Windows. So delivering a quality product on the dominant platform is easier if your support the minor platforms as well.

They also clearly mention, that they might not even make their money back on the Linux port of Smith and Winston. However, they’re clear that the other reasons (code quality, easier porting to other platforms and so on) do help make up for it. This is a similar point the people from Stardock also made on Reddit.

See the post here in full. If you wish to check out their game, Smith and Winston, it’s available on itch.io and Steam in Early Access.

Source

The Future of Linux – OSnews

Linux news is getting more and more exciting, and somehow, managing to get less and less interesting. Why? Because the speed of development is getting so rapid that it’s hard to get excited for each upcoming release, keep your system completely up to date, and even remember what the current version of your favorite distributions are. This breakneck pace of development means good and bad things, but I have a few ideas about how I expect it to turn out.

The opinions in this piece are those of the author and not necessarily those of osnews.com

There are literally hundreds, if not thousands of distributions out there. In fact, with Knoppix, almost anyone can make his own. Each season, it seems we watch some distributions fold and others form. It’s getting harder and harder to tell them apart. Think you’re an expert? Answer these questions quickly:

5) Name three source-based distros.

According to a recent post on Distrowatch.com, “It is time to face the facts: the number of Linux distributions is growing at an alarming rate. On average, around 3 – 4 new distributions are submitted to this site every week, a fact that makes maintaining the individual pages and monitoring new releases increasingly time consuming. The DistroWatch database now lists a total of 205 Linux distributions (of which 24 have been officially discontinued) with 75 more on the waiting list. It is no longer easy to keep up.” Distributions change often, as does the popularity of each. Keeping up is almost impossible. Many Linux users install new distributions every few days, weeks, or months. Sadly, many of these folks keep a Windows installation – not because they prefer Windows, but because it’s a “safe haven” for their data which can’t find a permanent home on any given Linux distribution. Can this pace continue? I say no.

Predicting the future is always risky for an author, especially one who contributes to internet sites, where your words are often instantly accessible to the curious. But I’m going to put my money on the table and take some guesses about the future of Linux. Here, in no particular order, are six theories that I believe are inevitabilities. Keep in mind that although I’ve been liberal in tone, nearly everything in this piece is speculation or opinion and is subject to debate. Not all of these theories are necessarily entirely original thought, but all arguments are.

1) Major Linux distributions will collapse into a small, powerful group.
“Major players” in the Linux market, until recently, included Red Hat, SuSE, Mandrake, Debian, and Slackware. Some would argue more or less, but now you have a number of popular distros making inroads into the community, Xandros, LindowsOS, and Gentoo to name a few. Another fringe including Yoper, ELX, and TurboLinux are making plays for corporate desktops. I’m coining a new term for this era of Linux computing: distribution bloat. We have hundreds of groups offering us what is essentially minor tweaks and optimizations of a very similar base. This cannot continue at this pace. There will from this point on, be a growing number of Linux installation packages as people become more skilled, but there will be fewer distributions on a mass scale as commercial Linux stabilizes.

I think we’ll see the commercial Linux market boil down to two or three players, and this has already begun. I expect it to be a Ximian-ized Novell/SUSE distribution, Red Hat, and some sort of Debian offshoot – whether it’s User Linux or not remains to be seen. Sun’s Linux offering, Java Desktop System, will be deployed in Solaris committed companies and not much more.

2) Neither KDE nor Gnome will “win;” a third desktop environment will emerge.
The KDE/Gnome debate is a troll’s dream come true. People are often passionate about their desktop environment. I believe they both have strengths and weaknesses. However, a third DE, with a clean and usable base, will emerge in time, its sole mission to unify the Linux GUI. Only when there is true consistency of the look and feel of the desktop, or close to it, will Linux become a viable home OS for an average user. Currently, we see this consistency forged by common Qt and GKT themes, and offerings like Ximian Desktop which attempts to mask the different nature of each application. This is not about lack of choice – it is, however, about not allowing choice to supercede usability of the whole product.

Features that a desktop must include are obvious by now: cut & paste must work the same way throughout the OS, menus must be the same in all file manager windows, the same shortcut keys must apply in all applications, and all applications must have the same window borders. Many seemingly basic tasks that haven’t entirely matured, or in some cases, been accomplished at all, yet.

In any event, the DE’s importance will lessen once greater platform neutrality exists. This will doubtlessly cause many to argue that I am wrong – admittedly, it’s a tall order especially with Gnome and KDE becoming established and accomplishing so much. I maintain that unless there is some sort of merging, not a set of standards like freedesktop.org, but rather, a common base for development, that there will be a fragmented feel to Linux that simply doesn’t exist in Windows today.

3) Distribution optimization will become more prevalent
Most distributions today can be used for anything – a desktop system, a web server, a file server, a firewall, DNS, firewall, etc. I am of firm belief that Windows’ greater downfall on the server is that it has been a glorified desktop for too long. The file extensions are still hidden by default, you’re forced to run a GUI, and you can still run all your applications on the system. I predict that we’ll start to see flavors within distributions tweaked at the source level for optimization. Systems made to run as a desktop will have many different default options from their server optimized counterparts.

4) Integration will force the ultimate “killer app”
I predict an open, central authentication system will take the Linux world by storm. There still isn’t a Linux comparison to NDS/eDirectory or Active Directory that makes user management across the network as simple as either of the two. While eDirectory will run on Linux, there is no open standard with a GUI management tool that automates this mass management. An authentication service whose job is only to watch resources including users, devices, applications, and files doesn’t exist and can’t be built without serious Linux know-how. This service, which I’ll casually refer to as LCAS (Linux Central Authentication System) for lack of a better term, will be as easy to establish as a new Microsoft domain’s Active Directory.

LCAS will operate using completely open standards (X.500/LDAP) and will be easily ported to the BSDs and to commercial Unixes. Unlike Active Directory, LCAS services will be portable, and stored in a variety of databases, including PostgreSQL, MySQL, and even Oracle and DB2. LCAS, like Linux, will be pluggable, so that as it matures, management of other objects, like routers and switches, your firewall, and even workstations and PDAs and eventually, general network and local policies, will be controllable from your network LCAS installation. Perhaps, in time, it will also manage objects on the internet and how they can act within your network. I envision the ability to block, say, a particularly annoying application‘s HTTP traffic, the ability for certain users to use specified protocols, or installing internet printers via LCAS.

5) Releases will become less frequent, and updates more common
There is a competition for versioning in the Linux world, as though higher version numbers are somehow “better.” Version inflation is commonplace, with companies incrementing the major version for minor overall updates, and going from X.1 to (X+1) after a few application updates and a minor kernel increase. There is also a software trend that eventually, when the version number gets too high and is abandoned in favor of less harsh sounding names. No one would upgrade Windows every six months, so why upgrade Linux every six months? Because the software gets better too quickly! And the best way to get new software that works is to upgrade the whole distro! This is backward. The software should be incidental to the distro, not the reason for its version stamp.

Gentoo Linux just changed their release engineering guide specs to include for a year number with subsequent point releases. This, I think, is the right idea. I predict that we’ll start to see releases like DistroX 2004, DistroX 2005. As a counterpart, we’ll begin to see downloadable updates like service packs, like DistroX 2004 Update2. These updates will be easily installable and will update and patch not only the OS, but all components that came with the distro.

It is not unlikely that we’ll see a front end installer that launches, checks your system and the server, asks which pieces you want upgraded, and then processes it. There are systems like this in place today, however, they are constantly updated. Too often, people don’t patch or update, they just reinstall. We’re going to see only security updates for each distro, and approximately quarterly, we’ll see an official Update. Updates distributed in this fashion are much more likely to be applied by a common user than the slew of updates issued on an almost daily basis. Updates like this allow users to utilize a modern system much longer in between releases – for years in some cases. Unless OpenCarpet catches on, I see a service pack mentality prevailing for all commercial distributions.

6) Linux-approved hardware will become common
Part of the fight for useable Linux is with device drivers and hardware. Getting your video card to work properly, even with a binary driver available, is still way too hard. While this isn’t always the fault of the hardware, we will see, in time, Linux approved hardware. The hardware will include Linux drivers on the accompanying disk. There will be a certification process that tests hardware against a certain set of standards. Soon, a Tux badge on a PC case will be as commonplace as the “Built for Windows XX” stickers on most cases today.

I don’t claim to be visionary by any means. I also don’t want to forcefully bring spirituality into the mix, but I believe all things exist in waves, with highs and lows. Linux started small, it’s gained an audience, and as it swells to a large point, we, the community, should anticipate the future refold of things. The eventual downswing shouldn’t be an implosion, but rather, an opportunity to organize and streamline the existence of free software. It doesn’t have to be a reduction in use, it can be a simple cooperation, reduction of market saturation, and convergence towards standards.

Within the next two years, we’ll likely see Linux kernel 2.8, Gnome 3, and KDE 4. We’ll see exciting new projects. We’ll see many new Linux distributions and many existing ones disappear. We’ll see the pre-Microsoft Longhorn media blitz. And I bet, not too much longer than that, we’ll see some of the above start to become a reality as well.

Adam Scheinberg is a regular contributor to osnews.

Source

Download TurnKey Django Live CD 15.1

TurnKey Django Live CD is a free and open source software appliance, a special Debian-based operating system that has been designed from the ground up to provide users with an easy-to-use solution for deploying dedicated Django servers with minimum effort.

Django is an open source high-level Python web framework that promotes rapid application development, as well as pragmatic, clean design. The appliance comes with a pre-configured Django example project, which is installed by default in /var/www/project.

This Django project is integrated with the Apache web server using the mod_wsgi module, as well as with the MySQL database server and the Postfix mail server. In addition, it includes an administration console that features embedded online documentation.

Among other interesting components of this TurnKey appliance, we can mention the iPython command shell for interactive computing, Webmin modules for configuring the MySQL and Apache servers, as well as SSL for secure connections.

When installing this appliance, users should keep in mind that the default username for the Webmin, SSH and MySQL components is root, and that the default Django admin console username is admin. After installation, users will be able to enter new passwords for these accounts.

In order to have a fully functional Django server, you’ll also have to add a valid email address for the Django ‘admin’ account. Optionally, you can initialize the TurnKey Hub services for securely storing your files, databases and package management information.

The appliance is distributed as Live CD ISO images, allowing users to try it without installing anything on their computers. However, their main purpose is to install the operating system on a local disk drive. In addition to the Live CDs, the appliance is also available for download as virtual machine images for Xen, OVF, OpenNode, OpenVZ and OpenStack virtualization technologies.

TurnKey Linux Django LiveCD Operating system TurnKey Linux Django LiveCD

Source

Python Seaborn Tutorial – Linux Hint

In this lesson on Python Seaborn library, we will look at various aspects of this data visualisation library which we can use with Python to generate beautiful and intuitive graphs which can visualise data in a form which business wants from a platform. To make this lesson complete, we will cover the following sections:

  • What is Python Seaborn?
  • Types of Plots we can construct with Seaborn
  • Working with Multiple plots
  • Some alternatives for Python Seaborn

This looks like a lot to cover. Let us get started now.

What is Python Seaborn library?

Seaborn library is a Python package which allows us to make infographics based on statistical data. As it is made on top of matplotlib, so, it is inherently compatible with it. Additionally, it supports NumPy and Pandas data structure so that plotting can be done directly from those collections.

Visualising complex data is one of the most important thing Seaborn takes care of. If we were to compare Matplotlib to Seaborn, Seaborn is able to make those things easy which are hard to achieve with Matplotlib. However, it is important to note that Seaborn is not an alternative to Matplotlib but a complement of it. Throughout this lesson, we will make use of Matplotlib functions in the code snippets as well. You will select to work with Seaborn in the following use-cases:

  • You have statistical time series data to be plotted with representation of uncertainty around the estimates
  • To visually establish the difference between two subsets of data
  • To visualise the univariate and bivariate distributions
  • Adding much more visual affection to the matplotlib plots with many built-in themes
  • To fit and visualise machine learning models through linear regression with independent and dependent variables

Just a note before starting is that we use a virtual environment for this lesson which we made with the following command:

python -m virtualenv seaborn
source seaborn/bin/activate

Once the virtual environment is active, we can install Seaborn library within the virtual env so that examples we create next can be executed:

pip install seaborn

You can use Anaconda as well to run these examples which is easier. If you want to install it on your machine, look at the lesson which describes “How to Install Anaconda Python on Ubuntu 18.04 LTS” and share your feedback. Now, let us move forward to various types of plots which can be constructed with Python Seaborn.

To keep this lesson hands-on, We will use Pokemon dataset which can be downloaded from Kaggle. To import this dataset into our program, we will be using the Pandas library. Here are all the imports we perform in our program:

import pandas as pd
from matplotlib import pyplot as plt
import seaborn as sns

Now, we can import the dataset into our program and show some of the sample data with Pandas as:

df = pd.read_csv(‘Pokemon.csv’, index_col=0)
df.head()

Note that to run the above code snippet, the CSV dataset should be present in the same directory as the program itself. Once we run the above code snippet, we will see the following output (in Anaconda Jupyter’s notebook):

Plotting Linear Regression curve

One of the best thing about Seaborn is the intelligent plotting functions it provides which not only visualises the dataset we provide to it but also construct regression models around it. For example, it is possible to construct a linear regression plot with a single line of code. Here is how to do this:

sns.lmplot(x=‘Attack’, y=‘Defense’, data=df)

Once we run the above code snippet, we will see the following output:

We noticed few important things in the above code snippet:

  • There is dedicated plotting function available in Seaborn
  • We used Seaborn’s fitting and plotting function which provided us with a linear regression line which it modelled itself

Don’t be afraid if you thought we cannot have a plot without that regression line. We can ! Let’s try a new code snippet now, similar to the last one:

sns.lmplot(x=‘Attack’, y=‘Defense’, data=df, fit_reg=False)

This time, we will not see the regression line in our plot:

Now this is much more clear (if we do not need the linear regression line). But this isn’t just over yet. Seaborn allows us to make different this plot and that is what we will be doing.

Constructing Box Plots

One of the greatest feature in Seaborn is how it readily accepts Pandas Dataframes structure to plot data. We can simply pass a Dataframe to the Seaborn library so that it can construct a boxplot out of it:

sns.boxplot(data=df)

Once we run the above code snippet, we will see the following output:

We can remove the first reading of total as that looks a little awkward when we are actually plotting individual columns here:

stats_df = df.drop([‘Total’], axis=1)
# New boxplot using stats_df
sns.boxplot(data=stats_df)

Once we run the above code snippet, we will see the following output:

Swarm Plot with Seaborn

We can construct an intuitive design Swarm plot with Seaborn. We will again be using the dataframe from Pandas which we loaded earlier but this time, we will be calling Matplotlib’s show function to show the plot we made. Here is the code snippet:

sns.set_context(“paper”)
sns.swarmplot(x=“Attack”, y=“Defense”, data=df)
plt.show()

Once we run the above code snippet, we will see the following output:

By using a Seaborn context, we allow Seaborn to add a personal touch and fluid design for the plot. It is possible to customise this plot even further with custom font size used for labels in the plot to make the reading easier. To do this, we will be passing more parameters to the set_context function which performs just like what they sound. For example, to modify the font size of the labels, we will make use of font.size parameter. Here is the code snippet to do the modification:

sns.set_context(“paper”, font_scale=3, rc={“font.size”:8,“axes.labelsize”:5})
sns.swarmplot(x=“Attack”, y=“Defense”, data=df)
plt.show()

Once we run the above code snippet, we will see the following output:

The font size for the label was changed based on the parameters we provided and value associated to the font.size parameter. One thing Seaborn is expert at is to make the plot very intuitive for practical usage and this means that Seaborn is not just a practice Python package but actually something we can use in our production deployments.

Adding a Title to plots

It is easy to add titles to our plots. We just need to follow a simple procedure of using the Axes-level functions where we will call the set_title() function like we show in the code snippet here:

sns.set_context(“paper”, font_scale=3, rc={“font.size”:8,“axes.labelsize”:5})
my_plot = sns.swarmplot(x=“Attack”, y=“Defense”, data=df)
my_plot.set_title(“LH Swarm Plot”)
plt.show()

Once we run the above code snippet, we will see the following output:

This way, we can add much more information to our plots.

Seaborn vs Matplotlib

As we looked at the examples in this lesson, we can identify that Matplotlib and Seaborn cannot be directly compared but they can be seen as complementing each other. One of the features which takes Seaborn 1 step ahead is the way Seaborn can visualise data statistically.

To make best of Seaborn parameters, we highly recommend to look at the Seaborn documentation and find out what parameters to use to make your plot as close to business needs as possible.

Conclusion

In this lesson, we looked at various aspects of this data visualisation library which we can use with Python to generate beautiful and intuitive graphs which can visualise data in a form which business wants from a platform. The Seaborm is one of the most important visualisation library when it comes to data engineering and presenting data in most visual forms, definitely a skill we need to have under our belt as it allows us to build linear regression models.

Source

GCC vs. Clang Compiler Performance On NVIDIA Xavier’s Carmel ARMv8 Cores

Since receiving the powerful NVIDIA Jetson AGX Xavier with its ARMv8 Carmel cores on this Tegra194 SoC a while back, it’s been quite a fun developer board for benchmarking and various Linux tests. One of the areas I was curious about was whether GCC or Clang would generate faster code for this high performance ARM SoC, so here are some benchmarks.

 

 

This CPU compiler benchmarking was done with the NVIDIA Jetson AGX Xavier while running the Ubuntu 18.04 LTS default L4T file-system and comparing the default GCC 7.3.0 against LLVM Clang 6.0 compiler options as officially supported by Ubuntu LTS Bionic Beaver. These are also the compiler versions supported by NVIDIA with their Tegra software on this Linux 4 Tegra sample file-system. The NVIDIA Tegra Xavier (T194) SoC as a reminder has eight “Carmel” ARMv8 CPU cores that are custom designed by NVIDIA. Tests on other more common ARMv8 cores with these different compilers will be coming up in future Phoronix articles with Clang 8 and GCC 9 releasing later this quarter. Rounding out this powerful Jetson AGX Xavier is the Volta GPU with 512 CUDA cores, 16GB of LPDDR4 system memory, 32GB of eMMC storage, two NVDLA deep learning accelerators, and a 7-way vision processor, granted those aren’t the focus of today’s testing.

Via the Phoronix Test Suite a wide range of C/C++ benchmarks were carried out on this platform for seeing how the GCC and Clang compilers compare from Ubuntu 18.04 LTS.

Source

WP2Social Auto Publish Powered By : XYZScripts.com