Linux is my primary operating system. I used it on the servers, desktops, laptops, netbooks, and even mobile phones since approximately 1997. I’ve tried a number of distributions over the years, and even created a couple myself. I still look around sometimes to see what others are up to. But most of my machines are running some sort of Red Hat – either a quick and easy Fedora Linux, or a stable and secure Red Hat Enterprise Server, or a cheaper CentOS alternative.
And while by now I am very comfortable in the Linux environment (both graphical and command line), I still discover a lot of new and interesting things about it. When I come across something worthy, I usually share it with the rest of the Open Software world, using this category.
This is a good question albeit one with a boring answer. Different systems evolved different encodings for newlines in the same way they evolved different behavior for myriad other things: Each system had to standardize on something and interoperability in the days before email let alone the Internet was unimportant.
There are several ways to represent newlines. ASCII-based systems use some combination of carriage return and line feed. These derive from typewriters: A carriage return (CR) resets the typewriter carriage’s horizontal position to the far left and a line feed (LF) advances the paper one vertical line. For a typewriter, you need both, so some systems (DOS, Windows, Palm OS) adopted CR+LF as representation of a newline. Other systems, such as Unix, noted a computer didn’t have a carriage to return so a sole line feed was sufficient. Still others, such as Mac OS prior to OS X, adopted only a carriage return—arguably, this choice doesn’t make any sense, as a bare carriage return would swing the typewriter carriage back to the left but not advance the page. Still other systems used LF+CR, inverting the ASCII characters used in Windows.
Systems not based on ASCII, of course, did their own thing. IBM mainframes built around EBCDIC, for example, used a special newline character (NL). Perhaps oddest of all, VMS utilized a record-based filesystem where newlines were first-class citizens to the operating system. Each record was implicitly its own line and thus there were no explicit newline representation!
But none of this mattered, because these systems never had to interoperate with each other—or, if they did, they had to make so many other conversions that newline representation was the least of their worries.
Today, most Internet protocols recommend CR+LF but dictate compatibility with LF (CR and LF+CR are left out in the cold). Given the centrality of the Internet, the ubiquity of Unix, which heralds LF, the primacy of C and descendant languages, which (somewhat) map their newline to LF, and the fact we really only need one character to represent a newline, LF seems the clear standard going forward.
As part of systemd/DBus revolution, newer Fedoras have this annoying feature that all USB disks get mounted into to /run/media/[user]/[diskname] (also /var/run/media, which is a symlink).
To return old behavior back and make udisks2 change mount point to /media, create a file /etc/udev/rules.d99-usb-shared-media.rules:
udev should notice and read this file automatically. After this, just unplug and plug your USB drive back to see it in good old /media.
By Leonid Mamchenkov
And here is the moment we’ve all been waiting for … every single site on this server is now served by Nginx. Of course, there is Apache behind for now to smooth out the migration, but The World Domination is right around the corner.
P.S.: Placeholder websites are served by another instance of Nginx, which runs inside an OpenVZ virtual machine.
P.P.S.: Can anybody make any sense out if it?
By Leonid Mamchenkov
Here is a reminder to myself with three things to remember when writing cron jobs. Surprisingly, even after doing it fairly frequently for years and years, I still get caught by one of these once in a while.
- User. Just because the script is working fine under your user, it doesn’t mean it will work well from crontab. Cron jobs are often executed under a different user account. Check, don’t assume. And be noisy about permissions and other possibly related issues.
- Environment. This is slightly related to the previous point. But just because something works fine from the command line, doesn’t mean it will run smoothly as a cron task. Anything that requires particular environment variables, user input, or being executed in a specific directory should be double checked.
- Duration. Cron executes tasks on schedule. It doesn’t really care if the previous instances finished running. So, either make sure the script can run several instances simultaneously, or using a locking mechanism, to make sure two instances don’t step on each other’s toes.
It’s not every day that one gets to run shred -vfz -n 2 /dev/sda …
Red Hat, Inc, (NYSE: RHT), the world’s leading provider of open source solutions, and the CentOS Project today announced they are joining forces to build a new CentOS, capable of driving forward development and adoption of next-generation open source technologies.