Advanced

Innovation in Linux: An extraordinary Linux review

Posted by dcparris on Apr 16, 2006 1:21 PM · 26 comments
LXer.com; By H. Kwint

  
There are plenty Linux reviews, though almost none of them are about Linux. You see, Linux is only a kernel, but most Linux reviews are about KDE, SuSE, the desktop and so on. Those reviews aren't about Linux, strictly speaking. In contrary, this review IS about Linux, made for the people who normally don't configure and compile their own kernel. In a previous LXer feature, my colleague Tom Adelstein said Linux is a me-too technology. That may be true for the desktop, but it is not fair to judge the whole Linux technology on its desktop. I hope to show, Linux (the kernel!) is full of innovation and peculiar features, which sometimes even sound like secret language, and is preceding its Big Competitor when it comes to features.

To be honest, a lot of kernel features need other programs on a user-level, to do anything usefull, so this article is not only about the kernel, but also about the userspace software to turn that kernel features to anything usefull.
Another note: We shouldn't forget, drivers for Windows are usually supplied by the hardware-vendors. Out of the box, Windows doesn't support that much hardware.
In the Linux kernel however, all drivers are included "out of the box". This means, the drivers are tested for Linux, and found stable by the "Linux kernel" team. After that, they are added to the linux kernel, to be used by everybody.

As I will try to show in this article, Linux has a lot of drivers and features. It also lacks some necessary drivers, especially for onboard gigabit-ethernet chips, onboard sound-chips, and video cards. Here, the hardware manufacturers sometimes offer proprietary drivers if you are lucky. But, normally, the hardware-vendors are to blame here. You probably can't imagine the efforts it took, to make the reverse engineered forcedeth-driver as an example. This driver had to be made, just because the hardware-vendor didn't feel like giving full documentation for its hardware.

Note: The following information is outdated. Please see this discussion for a better way, and why not to use the way represented here.
It might be nice to make this article a bit interactive, since it would be more convincing to see the features Linux offers for yourself, than only reading it here. Therefore, I advise you to get the Linux 2.6.15 sources, open a terminal, become root (using sudo is also fine), and change to your kernel directory:

$cd /lib/modules/$(uname -r)/source

Now, type

$sudo make xconfig

or

#make xconfig

if you did $su.

If all is like it should, you are in the Linux configuration menu now, and we can start discussing the features around. By the way, if you don't want the graphical interface, exchange 'x' by 'menu', using 'make menuconfig' instead of 'make xconfig'.

There we go. The kernel hierarchy is on the left, the items are on the right, and if you click on an item, you can see a short help on the right below the items. Sadly, it starts with some not very interesting stuff, but hold on to see some stunning features. I won't talk about all features, but feel free to look around, especially to the things I don't mention, there are long hardware-support lists which are worth looking at. I will limit myself to some eye-catching features in this article.

  • General Setup

    Two things are worth mentioning here. The first is the kernel .config support. It means, the configuration is saved in the kernel itself. This is nice, since we can never lose our .config file: we can do
    #zcat /proc/config.gz > /usr/src/linux/.config
    and our config is back. This is especially interesting on LiveCDs, like the Gentoo 2006.0 LiveCD: When compiling our kernel, we can use the exact same configuration as the LiveCD kernel has. Furthermore, the Linux kernel can be optimized for size, which means you can optimize it for old systems. The Windows kernel doesn't offer us this stuff.

  • Loadable module support

    Simple to tell: The loadable module support offers us the possibility to compile drivers and start them without rebooting. I don't have to say much about Windows XP and rebooting, do I?

  • Block layer

    Here, we find an option to optimize for desktop use, or even database use.

  • Processor types and features

    Like most people probably know, we can optimize for a processor type here. We can also choose to make a low-latency kernel here, by enabling the preemptible kernel. This works nice for music and movies. Also, we find a "Boot from EFI" option. EFI could be the successor of BIOS, and Microsoft already told, they don't want to support this option. If we have much memory and a 32 bit processor, we can also enable the support of mapping 64GB RAM here.
    Then, here comes one of the most interesting features in a long time (in my opinion): The kexec system call. "Sounds nice, but what does it mean?" you might think. Well, it enables you to stop your current kernel from running, and start another one. In theory, you should be able to update your kernel without rebooting. Not only will you be able to start a Linux kernel, but you should also be able to start other kernels, like a BSD or an OpenSolaris kernel, though I wonder if that' s a good idea...

  • Power Management Options
    I can't really tell a lot about it, since I don't use this. It's mainly intended for laptops. However, one thing that stands out here, is the "CPU frequency scaling" feature, which enables changing the CPU frequency on the fly.

  • Bus Options
    Here, we find an interesting feature: PCI hotplug. If you have suitable hardware, it means you can remove and add PCI cards without rebooting.

  • Device Drivers
    We skip two sections, and find ourself in the biggest submenu of the main menu: the Device drivers. This submenu is mainly about making all our hardware work. And like you will discover, there really is a plethora of supported hardware here.

    • Memory Technology Devices
      Here, we can enable stuff for ROM memory in embedded devices, like Flash etc.

    • Block devices
      In this submenu is the Network Block Device support. This means, it is possible to export block devices, like harddisk partitions, through a network, and then mount the filesystems on it. Furthermore, we can enable the cryptoloop support here; which enables us to make a file, map that file to an encrypted block device, and put a file system on that encrypted block device. After that, we can use that block device as usual, thanks to the device-mapper.

    • Multi-device support (RAID and LVM)
      We find something Windows doesn't have here*: software RAID, Logical Volume management and hardware encryption. Because of the device-mapper, which enables making 'virtual block devices' which can be seen as 'virtual hard disks', all is very flexible. I use EVMS as an interface for software RAID and LVM2 logical volume management.
      A short example: On my two harddisks, I make two partititons: sda2 and sdb2. This two partitions together form a RAID partition, md0. On this RAID partiton, I make a LVM container, c1. On this container, I can create regions, which are like DOS-partitions. On this regions, I can make filesystems.

      You may wonder why somebody wants to do all this. Mainly, this is because one can change the size of this virtual partitions - called regions - , add regions to the RAID partitions to increase its size, add regions to the LVM container, and because of all this, add harddisks, and use the new harddisk-space in the already made RAID, LVM and EVMS regions. Furthermore, we can make 'snapshots'. This means, if I have file a,b, and c on region X, and remove file b, file b will be written to the snapshot region. If I want to reverse region X to its original state, like putting back a backup, I can simply copy the snapshot back to region x.

      The device mapper also enables us to encrypt whole harddisks. Because all encryption software is open source, we can check if our data is really encrypted. This is one of the problems with closed source encryption tools: nobody grants us the data is encrypted in a correct way, and we can't find that out for ourselves. Therefore, I'd say closed source encryption software is simply useless.
      *Note: In our forums, reader mastertsunami made me aware of Windows Dynamic Disk, which offers most of the EVMS features, though EVMS is more elaborate.

    • Network device support
      Not only does Linux have Gigabit ethernet support, it does also have 10Gbit ethernet support.

    • Telephony support
      That's right, the kernel provides VOIP support.

    • Character devices
      Some interesting feature for me has always been the TI Parallel link cable support. It allows to connect a TI graphical calculator, which I own, to your parallel port, using a home-made $4 parallel cable. However, this is deprecated since the calculators use USB cables now.
      One thing that always made me curious, are the Watchdog cards. It seems, this are cards that 'watch' if your computer hangs, and if it does, restart you computer. Except for hardware watchdog cards, Linux also offers support for software watchdog 'cards'.
      Also here is the Real Time Clock support, which enhances the timing, for example when using ALSA sound. This is important when using your computer for mixing music.

    • Video for Linux
      Here is the support for video input cards, and FM Radio cards. It seems Video4linux also supports quickcams. It is used, amongst other, in FreeVO, the free competitor of TIVO, and MythTV.
      There's also support for Digital Video Broadcasting, an European standard, to turn your Linux PC into a personal video recorder, in combination with MythTV or FreeVO.

    • Graphics support
      Here we enable the most-wanted Linux feature: Support for frame buffer devices, and VESA VGA Graphic support. It gives you the best Linux-feature especially women seem to want (own experience): The bootup penguin!

    • USB
      I found it stunning, Windows XP without any service packs doesn't offer USB 2.0 support. Gladly, Linux does. If you are tired of your mouse, there are several touchscreen drivers here. There are also some interesting other gadgets, like the Xbox gamepad driver, USB LCD support and USB thermometer support.

  • File Systems

    • (Network) File systems

      Windows XP only offers NTFS and FAT support, and SMB/CIFS (extended SMB) for networking file-systems. That's not much, compared to Linux.
      Linux provides filesystem support for the three mentioned filesystems, and, amongst others, for ext2, ext3 (ext2 + journailing), Namesys' ReiserFS (good performance!), IBM's JFS, Sillicon Graphics' XFS, BSD's UFS, iso9660 CDROM, UDF CDROM and Apple's HFS file systems. Then there is support for the more exotic filesystems, like Amiga FFS, BeOS' BeFS, SquashFS (used by LiveCD's) and OS2 HPFS.
      But that's not all, there's also support for virtual filesystems (pseudo-filesystems), like the deprecated devfs support, most notably /proc support, and /sysfs support.
      Last, but not least, there are the network file systems. We can turn on NFS, CIFS, a part of Kerberos, and even Plan 9 resource sharing.

    • Automounter
      Something that has to do less with filesystems, but is very interesting, is the automounter. It's something Windows users take for granted, and maybe all users should take it for granted. Anyway, it makes sure that, whenever we plugin an USB stick, load an audio CD, or notice a network filesystem, it is mounted on the right place. It has the nice feature, CD's etcetera are unmounted after an amount of 'idle' time. This stops the CD from spinning if it is unused for some time.
      Together with 'udev', this makes a flexible system. Udev, for example, is able, when a CD is pulled in, to get its title via CDDB over the internet, and make a device with the name of the CD, /dev/<<cdname>>.

      Ok, that's nice, but far more important, is the feature udev offers to distinguish between USB sticks. I have two of them, one Apacer MP3 player and one PQI data-only usb-stick. If you pull them in a Windows box, the number of harddisks, the number of card readers and the configuration of virtual CDROMs (Deamon-tools) will determine the letter that is assigned to the USB-stick.
      Worse, if I first plug in the PQI and after that the Apacer, the PQI will get (for example) letter H and the Apacer will get I. But if I first plug in the Apacer and then the PQI, the Apacer will get the letter H and the PQI the letter I. If I were to use a script to copy mp3's to my MP3 player (I do), this would all go wrong because off this awkward drive-letter situations.
      Fortunately, udev offers us the possibility to identify USB-sticks on the basis of information from /sysfs, including ID's and possible the brandname and other more unique characteristics. In this way, it is possible, to always give my MP3 player the device-name /dev/mp3, and my PQI stick the name /dev/usb. Now, what the automounter is able to do, is mount my MP3 device to /home/user/mp3 and my PQI stick to /home/user/usb. This way, I can write scripts. udev and the automounter even enable me to start scrips after devices are plugged in or out of the computer. That way, I can decide a U2 audio-CD should always start playing immediately, and all Windows CD's are immediately ejected (don't worry, just an example!).

  • Security options

    It's always wise to enable the different security models here. Most people think: "Root is always root, and can screw up everything!" Yeah right, if you are sure of that, review the BSD secure levels here. They enable to define several 'root' levels, and if you are in the most 'insecure' root level, root can't screw up that much. To change to a level of more privileges for the privileged user, you have to give an extra password (on top of the normal password) first. An interesting way of making your computer more secure. Furthermore, we can enable SELinux here. Also, here's the 'Root Plug' option, which for example enables us to disable starting new programs as root if a certain USB plug isn't plugged-in.
    If you are really interested in security, get an hardened kernel, for example the Gentoo hardened kernel. While configuring one of those, you will find a lot of extra options here, like PaX, which, most of the time, prevents buffer overflows from leading to exploits.

  • Cryptographic functions

    Secret stuff goes here. Well, secret, the ciphers and digests are open source, so anybody could check if all is implemented in a right manner. Apart from the wide-known SHA/MD5 digests and the DES ciphers, there is plenty more here. I always use the AES cipher. It is approved by the US government to use for classified data, and invented by Belgians (for the paranoid Europeans). Here's also support for the new VIA processors with hardware en- and decryption acceleration.

So, that's what Linux currently has to offer. If that's still not fancy enough for you, maybe you should try the Linux-mm-2.6.16_rc6 kernel. At this moment it's bleeding edge, but in two months, people will probably be laughing about it, because the Linux kernel evolves rather quick the last few years. It doesn't always follow the competing kernels, but also comes with features unique to Linux. And that's a good thing to see.

Return to the LXer Features

Comments (26)

A needed article

I have been looking for an article like this for six months now. This is exactly what I needed to read, not a how-to on compiling and installing there are plenty of articles out there for that, but what each of the options do. I am not a total newb, nor am I a kernel guru, yet I cannot seem to find help on what features I need. I read the options when compiling my kernel but am unsure about all of the features so I went through a lot of trial and error with mixed results. This is good a good map of features that is needed for the non-experts who want it to just work.
Starting with a precompiled kernel is a great idea. Change one thing, see what happens. I like the Debian kernels because everything that can be a "module", other that a good variety of boot devices, of course, are built that way. So recompiling has never been needed, by me anyway.
Thanks for the compliments.

The article was not meant as an HOWTO, but if it's helpfull, that's great!

You see, to write a really helpful HOWTO, I would need to know much more about the options. This are only the options I am aware of, but I don't run servers or embedded devices, only a desktop etc.

I wrote the artcile because I configured a kernel from scratch, and you can't imagine how much work that is, even when you know your way around. I spent longer configuring the kernel than Xorg took to compile, for example. And all those stuff made me curious. I mean, that's how to learn about the kernel: start wondering about those features.

I agree it's a good idea to turn things on and off, but I prefer looking on wikipedia, the internet, and the Documentation. All documentation can be found in

/usr/src/kernel/Documentation

by the way.

So just keep trying, and most important, don't be afraid.
Sure, "Don't be afraid" is important.

Also, "Don't erase a working kernel until you've tested its replacement" is good advice. :^)
Quoting: "Don't erase a working kernel until you've tested its replacement" is good advice. :^)


Ahh.... That's 'critical' advise :D !
The ancient rules of computing bear repeating:

Rule #1: Never go from A to B without a way back to A.

Rule #2: Never violate Rule #1.
And, grouch and I have never violated either rule :-D.
You mean, like putting "apt-get update && apt-get dist-upgrade --yes" in a cron job while tracking Sid?

:^)

There, is that better? BTW, never listen to recordings of the Penn Jillette radio show http://www.pennradio.com/ before going to sleep. It really promotes wakefullness!
Bob_Robertson:

Add '--yes' to that and become truly evil. ;)
Oh, and never pull out the power-plug while glibc is installing... (Last time I did, whole Gentoo had to be reinstalled)
LOL hkwint! Kinda hard to compile anything if your glibc bootstrap died in mid boot, eh? (I realize it was not likely a laughable matter at the time, but you obviously worked through it).

BTW, the power plug is only intended to be used as the emergency exit from Viciously Insane.

Rarely Addressed, Thank You.

Even a moderately experienced Linux user (that is, someone who is has compiled a kernel, done some distribution upgrades, wrestled successfully with hardware) going to Windows will find themselves disfunctionally restricted. It's easy to say that "Linux is scary" compared to Windows, because of the greater functionality, flexibility and control, but the reverse is closing and locking the prison door on ones self.

What a simple thing, tossed into this article without a second thought, to follow along by the reader examining the Linux kernel compile options themselves. In Windows, that is IMPOSSIBLE.

As somewhat experienced Linux people, it's easy to overstate the functionality and flexibility to a prospective Windows-using convert. Doing so scares them, because then they think they MUST compile their own kernel (for example). The idea of merely opening the Windows Registry is enough to send most Windows users into apoplexy of worry that they might break something and have to reinstall everything. Again.

The first objection out of most prospective converts mouths is, "I am not competent to recompile my own software." Microsoft Marketing department success at its finest.

Bob-
Again, the MS 'Empire of Ignorance'. The less they know, the more dependant they are.
metoo to both comments! Great article.
Should post this to /. and other sites... it's worthy.
Already posted it to some sites myself, and /. usually doesn't post our stuff, but all efforts are very, very welcome, so thanks!

Great article!

One of the aspects that I most enjoyed is that I always knew a few details about how Linux surpasses Windows; this article added quite a few details.

Also, it was written in a conversational tone that made for enjoyable reading... this might otherwise be quite a dry topic.

Thanks!

Two things:

1) If you're using an older Linux version from 2001, which is around the time scale (and thus comparable) when XP was released, you won't get 2.0 support either. That (initially) didn't come until the 2.5.2 kernel, so the point is rather moot as most modern XP installs ship with SP1 or SP2 slipstreamed.

2) You can do software raid in XP, except Microsoft calls it "Dynamic Disks." You can do it in 2000 as well.

Other than that, good article.
Ok, I was afraid of that, but I use Windows for that stuff too less to really know about it.

A few mistakes ...

You are perpetuating some (long) outdated things in your article. I'll describe the mistakes below and quote Linus's own words on these things from an email he posted on LKML back in the year 2000 - http://uwsg.iu.edu/hypermail/linux/kernel/0007.3/0587.html - I suggest you read the entire email as well, it's a good one :-)

1) You tell people to configure and build the kernel as root. That is not the proper way to do it and has not been for years. The proper way is to configure and build the kernel as a normal user. You need to be root only to install the kernel and modules, but that's a different thing.

2) You tell people that they should build their kernels in /usr/src/linux . That's about as wrong a location to pick for that task as you can possibly choose. The recommended location is somewhere in your regular user homedir.

3) It's nice of you to tell people about "zcat /proc/config.gz > /usr/src/linux/.config", but you should probably also mention that whenever you base a new config on an existing config file you should always run "make oldconfig" as the very first thing after putting a .config file in place. "make oldconfig" will read the .config, make sure it matches the current source and prompt the user for selections if any options have changed - even if your old .config is from the same kernel version you are recommended to still run "make oldconfig" after copying it to the source tree.

Here's a blockquote from Linus's email on these things :

" I would suggest that people who compile new kernels should:

- NOT do so in /usr/src. Leave whatever kernel (probably only the header files) that the distribution came with there, but don't touch it.

- compile the kernel in their own home directory, as their very own selves. No need to be root to compile the kernel. You need to be root to _install_ the kernel, but that's different.

- not have a single symbolic link in sight (except the one that the kernel build itself sets up, namely the "linux/include/asm" symlink that is only used for the internal kernel compile itself)

And yes, this is what I do. My /usr/src/linux still has the old 2.2.13 header files, even though I haven't run a 2.2.13 kernel in a _loong_ time. But those headers were what glibc was compiled against, so those headers are what matches the library object files.

And this is actually what has been the suggested environment for at least the last five years. I don't know why the symlink business keeps on living on, like a bad zombie. Pretty much every distribution still has that broken symlink, and people still remember that the linux sources should go into "/usr/src/linux" even though that hasn't been true in a _loong_ time.

Is there some documentation file that I've not updated and that people are slavishly following outdated information in? I don't read the documentation myself, so I'd never notice ;) "

Note that he says "... this is actually what has been the suggested environment for at least the last five years ..." and that email was written more than 5 years ago, so as of now that has been the way for more than 10 years (and it's also what's described in various files in Documentation/ with any halfway recent kernel source, if you read them).

i tried to do what you say some time ago. decompress the src of the kernel in one directory in my $HOME

but what i dislike is the link /lib/modules/$(uname -r)/build which points to where the src are ... and in my $HOME when you install the kernel

i revert back to the use of /usr/src/linux ...
JesperJuhl: Thanks for the comments. I didn't know about that.

The way I told it just works for me, and it's the way it's in the Gentoo Docs

http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=...

If I emerge a kernel, it goes to /usr/src, NOT to my home_dir. To be honest, I don't care that much about it. Nonetheless, I believe there are reasons to put it in /home, but it is just easier to do it the old way. Can you give me some useful reasons to do it in your home_dir?

Furthermore, when compiling the closed nvidia drivers (graphics / nvnet / nvsound) they rely on /usr/src/linux as far as I know.

About the "make oldconfig": I forgot that part.

Don't forget: This article was meant as a Linux kernel review, NOT as a "kernel compiling HOWTO". Some people may find it useful as a HOWTO, though they should look at the documentation their distro's provide. Looking at what Linus told, the Gentoo docs are outdated. I believe, if compiling as root in /usr/src/linux really was that bad, the distro's already would have changed it, so I don't think it gives big problems.

This article however explains how most users can _view_ their kernel configuration.
NVidia relies on the symlink /lib/modules/$(uname -r)/build to find the source.
To hkwint:

"The way I told it just works for me, and it's the way it's in the Gentoo Docs"

Those docs seem to be outdated.

"Can you give me some useful reasons to do it in your home_dir?"

Well, for one there are the file permissions. If you extract the kernel source as root (as you would tend to do if you are using /usr/src/ , since on most dists that dir has perms like this "drwxr-xr-x 3 root root 4096 1993-11-24 21:33 src") then you'll get a kernel source tree with world writable files due to the way the tarballs are made :

-rw-rw-rw- 1 root root 18693 2006-03-20 06:53 COPYING

On the other hand, if you extract the source tarball as a normal user (in which case doing so somewhere in your homedir is the logical location), then you get files with more sane perms :

-rw-r--r-- 1 juhl users 18693 2006-03-20 06:53 COPYING

ofcourse you could just manually chmod the files after extraction as root, but I doubt very many people will do that, and as a consequence they will have a source tree that everyone can muck around with - that's a nice and easy way to crack a system, modify the kernel source to install a backdoor, then wait for the admin to build and install the new vulnerable kernel - instant root privileges to ordinary users - whoops! You don't even need to wait for a vulnerable kernel to actually be installed. Since you can write to any of the files and the admin will likely run 'make' as root, then you have plenty of oppotunity to write a Makefile that will grant your user root privs and then continue building the kernel as normal. So all you really need is for the admin to run "make clean" , "make menuconfig" or "make" or whatever.

Another good reason to do it in your homedir as a normal user is that $PATH is usually setup differently for root and ordinary users. On some distributions, not all the tools needed to build a kernel are in root's PATH while they are in ordinary users PATH's (granted, this is rare, but I've come across it a few times over the years).

"Furthermore, when compiling the closed nvidia drivers (graphics / nvnet / nvsound) they rely on /usr/src/linux"

Wrong, the nvidia drivers rely on the /lib/modules/$(uname -r)/source symlink to find the kernel source for the currently running kernel. On my box that link looks like this :

$ ls -l /lib/modules/$(uname -r)/source lrwxrwxrwx 1 root root 47 2006-04-09 14:41 /lib/modules/2.6.17-rc1-mm2/source -> /home/juhl/download/kernel/linux-2.6.17-rc1-mm2/

So the nvidia drivers (that need to be installed as root and thus won't have any problems reading files in the oridnary user juhl's homedir) won't have any trouble whatsoever.

"Don't forget: This article was meant as a Linux kernel review, NOT as a "kernel compiling HOWTO"."

I realize that, but that still doesn't mean that the article shouldn't strive to be accurate and should not provide outdated info.

"This article however explains how most users can _view_ their kernel configuration"

Wrong. The articles instructions assume everyone has root access to the machine they work on, that's a flawed assumption. Obviously the largest set of users is those with access to a regular user account - everyone who has root access also has access to a regular user account or can easily create one. Those who don't have root access only have access to a regular user account. So by giving instructions in the article that require root, you limit the usefulness of the article to those who have root access and leave those who don't out in the cold. Had the article given instructions that could have been followed by a regular user, then both those with and those without root access could have followed the instructions to view a kernel configuration (obviously only those with root access could view the current configuration stored in /proc/config.gz, but more people would be able to view *a* configuration, even if only the default one).

Grouch and JesperJuhl:

Ok, thanks very much for your comments, I really learned something. I will send people to this discussion for a better way to do things, since I'd say changing the article all over after this amount of time isn't fair.

Update: I changed the cd command to
Quoting: cd /lib/modules/$(uname -r)/source


Maybe I'll post a bug on the Gentoo docs.

Some last notes: Gentoo portage fixes the permissions BTW, and my root user has a more elaborate PATH then the normal user. Furthermore, it doesn't sound right to me that kernel files, which I consider as system files, should go to the /home directory, which I consider as all my 'private', 'not needed for system maintenance and update' files.

What I learned is that a lot (maybe even most) of kernel info on the net is outdated, since you are the first person telling me to not do it in /usr/src (ALL articles I read tell you you most likely will find it there), so obviously there is something wrong somewhere.

Excellent - very much needed

We need to see more of this - since the 2.6 release, there has been a lot of innovation. Great article and much appreciated.

Post a comment

A free account is needed to post. Write your comment here first: your text is kept in this browser while you sign up or log in, and is waiting for you when you come back.

Your message:
|||||
10
Markdown: **bold**, *italic*, [text](https://link), - lists, > quotes, $x^2$ for math. Formatting help

Sign up and post (it is free)  or  Log in and post

LXer

  Latest Features
bob: LXer now speaks Markdown
Oct 27, 2026

bob: How to protect against PHP2Shell
Oct 26, 2026

Scott Ruecker (San Diego, U.S.): Linux That's Small
Oct 14, 2024

penguinist: Encryption, Trust, and the Hidden Dangers of Vendor-Controlled Data
Aug 27, 2024

Scott Ruecker (San Diego, U.S.): My Linux Mint Tribute
Aug 23, 2024

Scott Ruecker (San Diego, U.S.): How I Turned My Chromebook Into A "Mintbook"
Jul 08, 2024

Scott Ruecker (San Diego, U.S.): Adventures With My New Chromebook
Jun 10, 2024

Scott Ruecker: My Linux Laptop
May 08, 2022

Scott Ruecker: Laptop Dual Boot Project: Part 2
Nov 30, 2021

Scott Ruecker: Laptop Dual Boot Project
Nov 30, 2020


View all

  Search Features

Search LXer Features:

[ Copyright © LXer | All times are recorded in Central Daylight Time (CDT) ]

[ Contact Us | Privacy Policy | Terms of Service | About us | rss | Mobile ]

Login