Feed aggregator

Using Kdump for examining Linux Kernel crashes

LXer - Thu, 2017-06-22 01:37
Kdump is a way to acquire a crashed Linux kernel dump, but finding documents that explain its usage and internals can be challenging. In this article, I'll examine the basics of kdump usage and look at the internals of kdump/kexec kernel implementation.read more

Mutter Continues Refining Its Display, HiDPI Support

Phoronix - Thu, 2017-06-22 00:35
GNOME's Mutter 3.25.3 window manager / compositor is now available as the newest release in the path towards GNOME 3.26...

Linux vs. Windows Server OS Comparison

TuxMachines - Thu, 2017-06-22 00:23

A comparison between Linux and Windows while selecting the server operating system is like being in stalemate while playing the chess game where the outcome is unpredictable. Various versions of the Microsoft—from Windows—and the Linux-based operating systems are available in plenty today. But deciding the best option is a tougher task, rather, finding the right solution that fits the organizational requirements is easier.

read more

Canonical Also Patches Ubuntu 12.04 LTS Against the Stack Clash Vulnerability

TuxMachines - Thu, 2017-06-22 00:15

Canonical today announced that it released a new kernel security update for the Ubuntu 12.04 LTS (Precise Pangolin) operating system series to patch the infamous Stack Clash vulnerability discovered recently by Qualys Research Labs.

read more

How to Install and Configure the ELK Stack on Ubuntu 16.04

LXer - Thu, 2017-06-22 00:11
ELK stands for Elasticsearch, Logstash and Kibana and is a robust open source solution for searching, analyzing and visualizing data. Elasticsearch is a distributed, RESTful search and analytics engine based on Lucene, Logstash is a data processing pipeline for managing events and logs and Kibana is a web application for visualizing data in Elasticsearch.

Best Linux Distro: Linux Experts Rate Distros

TuxMachines - Thu, 2017-06-22 00:10

Looking over this list, I notice that innovative, security-based, and community-developed distributions. However, I am not consistent in these preferences, since I do not include perfectly good alternatives like openSUSE or Linux Mint.

Still, one thing a list like this makes clear is that the total number of distributions might be declining, but the diversity of Linux variants is as strong as ever. Even if you don't find any of these choices to your liking, dig around and you should find several distributions that you can live with.

read more

Creating screencasts on Linux

TuxMachines - Thu, 2017-06-22 00:08

As this is a new blog on Fedora Planet, let me start off by introducing myself briefly. My name is Maxim Burgerhout, and I have been a Fedora contributor for quite some time. Truth be told though, I haven’t been able to spend much time maintaining my packages over the past couple of years. As a different way of giving back, I want to start sharing some experiences with open source software in a specific niche: screencast creation, and video editing.

read more

Former Ubuntu Phone Insider Shares His Thoughts on Why the Project Failed

LinuxToday - Thu, 2017-06-22 00:00

softpedia: Simon Raffeiner worked on the Ubuntu Touch operating system since its official announcement back in 2013, believing in the project's goals and objectives.

Wrote a collectd-postfix plugin

Reddit - Wed, 2017-06-21 23:41

I could not get the Tail plugin working right, so I decided to write my own plugin for Postfix with python. Could use some testers in other environments, feedback, critique. Thanks


submitted by /u/wyl1e
[link] [comments]

How To kill An Inactive OR Idle SSH Sessions

LinuxToday - Wed, 2017-06-21 23:00

Simple way to kill an inactive or idle SSH sessions in Linux.

Awesome way to run-execute multiple remote commands-shell scripts using ssh in Linux / UNIX.

LXer - Wed, 2017-06-21 22:46
In this article we will be discussing about how to run-execute multiple remote commands-shell scripts using ssh in Linux / UNIX.

Universal Error Codes-- What do you think?

Reddit - Wed, 2017-06-21 22:37

My friend came across an error a while back he didn't understand. He has great English, but there was a word in there he didn't know. It really frustrated him because all he wanted was the meaning of the error-- because of this frustration, he spat out, "Why can't it just be obvious, like 404?" From there, he came up with this idea.
Instead of different programs having different was of saying "wrong filetype," "no such file or directory," etc, what if they all used a universal set of error codes in a predictable, consistent format?
I.E., if you used grep on a non-existent file, it'll probably say "grep: $FILE: No such file or directory"
Under this hypothetical set of error codes, it could say, "grep: 204: $FILE" instead.

This could allow easier parsing of the error-- a script or program could simply look for the three-digit number in the output, and do whatever it must with it. Or the program could even return the error code. ("echo $?" after getting the above from grep would return "204")

But with the clarity for machines comes another issue-- a general lack of clarity (initially) for everyone. "What the fuck is a 208?" someone would probably say at some point. They'd have to fire up a web-browser, search "What is error 208", select a result, and read the page. How frustrating and tedious! This is why each error code should have it's own man-page-- the user would only have to use "$ man 208" to figure it out. While the meanings of the error codes wouldn't be obvious, the answer would be close at hand.

Making sure the error code's meaning is nearby also helps ease the harshness of a language barrier. I mean, if you're a systems translator, what's easier-- translating the error codes of hundreds of different utilities, of which may express the same problem differently, or only translating the error codes' respective manpages? If you're a developer, you wouldn't need to translate errors, just cite the error code. Often, errors aren't translated for non-base (especially for less popular languages-- in these cases, sometimes for base programs, too). I mean, if you only speak Tibetan, "204" followed by checking the 204 manpage in Tibetan is better than "No such file or directory."

Often, errors also need to specify where shit went down. For instance, you might have a long awk script. awk can't just throw you an error saying "oh, you hecked up," it needs to tell you what line, what statement...
So I purpose a simple format for this system-- after the error code, if there is other information it needs to tell you, state it after a colon like this:
E.g.: "cat: 204: ./FILE" for "no such file or directory" in cat.
Line # = L#
Phrase "..." = "..."
Filename = The relative path-- always like so: ./dir/file. The "./" should never be omitted
... so on and so forth.

The error code system could be laid out in ranges like this:
100-199 & 1000-1999: Library and system call errors
200-299 & 2000-2999: File I/O errors
300-399 & 3000-3999: Device errors
400-499 & 4000-4999: Network errors
500-599 & 5000-5999: Cli input/syntax errors
... so on and so forth. The three-digit ranges would be for common errors, the four-digits for more obscure/super-niche ones.

The system would allow greater consistency, cross-language understanding, parsing/interpreting, and ease the jobs of translators and developers a tad bit.

This is the rough start of an idea-- there's a ton of stuff that needs to be thought through more, elaborated more, things I haven't thought of yet, etc. etc.-- but there are a few problems I know about already:

  • Search-engine optimization. Different programs, protocols, and some operating systems already use their own error code systems-- if you looked up "error code 208," you would want to come up with this system but might come up with X software vendor's system. A remedy would be to make this system look unique somehow. Maybe prefixing each error code with a character? "#" is too generic for this, "$" could be confused with system variables... This prefixing character should be accessible on different keyboard layouts. It's no good if only one layout has it!
  • Categorization. Categorizing errors is kind of a monumental task in and of itself. What should be the categories? What fits where? Should "cannot write/create $FILE: permission denied" be considered a file-write error, or a permission error? Both? Neither? Etc etc.
  • Adoption. Spurring adoption would be a painful process, and gains wouldn't be possible nor visible for a long time. Getting people to adopt the system would also be difficult.
  • Infrastructure. There should be an "official" source of documentation. It is impossible to predict the new kinds of issues technology and software can come up with-- if they can't be simplified to the three-digit range of codes, it needs to be easy for someone to create a new four-digit error code-- so there would also need to be an "official," public-facing list of error codes (for ones that are generally agreed on and established) and a wiki-like, changing, not-yet-official-nor-stable list that can have error codes appended to it.

That's all I've got-- sorry for the semi-brain-dump/rantish blob of text, but I just wanted to get this idea out there.
Sorry if this is the wrong sub, too. I just really like the discussions that develop here.
EDIT: Added example for the additional information section.

submitted by /u/jadedctrl
[link] [comments]


Subscribe to LinuxInsight aggregator