Letters to the Editor
I found the article [Setting up Services in the April 1995 issue] interesting. I think that there was one major point that was missed. Administrators should not randomly assign ports to services. In fact there is an RFC that lists the ports. The latest is rfc1700. This is very important for novices to learn.
—Matthew B. Guest email@example.com
I agree emphatically with the letter from Graham Leach (firstname.lastname@example.org) in the April 1995 issue of Linux Journal. Your magazine is excellent. But the “linked list” format is annoying. Please avoid it, or at least minimize it.
I disagree with one of your justifications, namely that readers expect “important” articles near the front of the magazine. I certainly don't. I would guess that most of your regular readers, like me, would read each issue cover-to-cover, and more than once. Perhaps you could poll your readers, to find out for sure.
As I said, your magazine is superb. But the format makes it difficult to read, needlessly so.
—Carl Renneberg email@example.com
Just received my first issue of Linux Journal: April. Great!
WRT the split article issue raised by Graham Leach in a letter to the editor, may I suggest something that worked well for me back in the dark ages of paste-ups: Instead of “no jumps”, which is really tough, how about a goal of no more than one jump per article. It would also be helpful to add the article name to the “continued from...” at the top of jump pages.
Thanks for an interesting, readable book.
—John Miller, N4VU jsm@n4vu.Atl.GA.US
We have been discussing this and this issue has a keyword from the article title added to the “continued from” lines, as you suggest. Also, I agree with the one jump max rule and we will try for that. From more information on our new layout, please see Stop the Presses.
I was very pleased to read Robert A. Dalrymple's article on Scilab. I've been using Scilab for 7 years and I think that it is a terrific product (much more powerful than Matlab). It's wonderful that INRIA decided to make this tool available to the public as free software.
My purpose for writing this letter is that I think your readers will be interested in knowing some additional facts about Scilab which did not come out in the article. One of the most powerful aspects of Scilab is its ability to easily perform data abstraction and operator overloading.
Scilab is delivered with several pre-defined abstract data types such as rational polynomials and linear dynamic systems. Overloading of the usual operators such as “+”, “-”, “*”, “/”, and “=” allows the user to easily manipulate these abstract data types and the development of higher level operations is greatly simplified. Here is an example with two rationals:
^> r1=(2+3*s)/(1+s**2) r1 = 2 + 3s ^^^- 2 1 + s ^> r2=s/(5+s) r2 = s ^^^ 5 + s ^> r3=r1+r2 r3 = 2 3 10 + 18s + 3s + s ^^^^^^^^^ 2 3 5 + s + 5s + s
Notice that even though the rationals in the example are user defined objects, the overloading of the “=” operator gives rise to a user friendly on-screen representation which is recognizable as that of a rational. Furthermore since the “+” operator is overloaded for rationals, their sum is defined and requires no special function (like r3=poly_add(r1,r2) as an example).
The implementation of the rational abstract data type in Scilab allows all the usual operations that one would expect between two rationals as well as between a rational and other data types (such as scalars and matrices).
The user of Scilab can easily define new abstract data types and develop Scilab macros for the implementation of user transparent operator overloading. These Scilab features are unique in the Matlab-like class of products and is the reason for which I believe that Scilab is a much more powerful product than Matlab.
I hope that these comments will be of use to your readers.
—Carey Bunks firstname.lastname@example.org
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
- Three More Lessons
- Django Models and Migrations
- August 2015 Issue of Linux Journal: Programming
- Hacking a Safe with Bash
- Secure Server Deployments in Hostile Territory, Part II
- The Controversy Behind Canonical's Intellectual Property Policy
- Shashlik - a Tasty New Android Simulator
- Huge Package Overhaul for Debian and Ubuntu
- Embed Linux in Monitoring and Control Systems
- KDE Reveals Plasma Mobile