Slashdot Mirror

Oh? Where can I find the repository for security patches for linux 1.0?

https://www.kernel.org/.

The reality though by compitors I unsurprisingly meant (but not limited to :) Firefox http://www.mozilla.org/en-US/firefox/new/ and Chrome https://www.google.com/intl/en/chrome/browser/

XP exists on about 20% of computers...or about 220,000,000 which is why the point is about XP :)

I find that using git-svn with a central SVN repository results in a very nice workflow. In my local git repository, I'm free to develop in a nonlinear, exploratory fashion. At logical stopping points, this work gets neatly reconciled with reality in the form of sensical SVN commits. It's the best of both worlds, and allows me to do useful work even on an airplane.

I'll just leave this here so people get to see a comparison that's actually useful.

https://git.wiki.kernel.org/index.php/GitSvnComparison

From https://www.kernel.org/doc/Documentation/development-process/2.Process (emphasis mine):

A relatively straightforward discipline is followed with regard to the merging of patches for each release. At the beginning of each development cycle, the "merge window" is said to be open. At that time, code which is deemed to be sufficiently stable (and which is accepted by the development community) is merged into the mainline kernel. The bulk of changes for a new development cycle (and all of the major changes) will be merged during this time, at a rate approaching 1,000 changes ("patches," or "changesets") per day.

(As an aside, it is worth noting that the changes integrated during the merge window do not come out of thin air; they have been collected, tested, and staged ahead of time. How that process works will be described in detail later on).

The merge window lasts for approximately two weeks. At the end of this time, Linus Torvalds will declare that the window is closed and release the first of the "rc" kernels. For the kernel which is destined to be 2.6.40, for example, the release which happens at the end of the merge window will be called 2.6.40-rc1. The -rc1 release is the signal that the time to merge new features has passed, and that the time to stabilize the next kernel has begun.

Over the next six to ten weeks, only patches which fix problems should be submitted to the mainline. On occasion a more significant change will be allowed, but such occasions are rare; developers who try to merge new features outside of the merge window tend to get an unfriendly reception. As a general rule, if you miss the merge window for a given feature, the best thing to do is to wait for the next development cycle. (An occasional exception is made for drivers for previously-unsupported hardware; if they touch no in-tree code, they cannot cause regressions and should be safe to add at any time).

As fixes make their way into the mainline, the patch rate will slow over time. Linus releases new -rc kernels about once a week; a normal series will get up to somewhere between -rc6 and -rc9 before the kernel is considered to be sufficiently stable and the final 2.6.x release is made. At that point the whole process starts over again.

[...]

2.3: HOW PATCHES GET INTO THE KERNEL

There is exactly one person who can merge patches into the mainline kernel repository: Linus Torvalds. But, of the over 9,500 patches which went into the 2.6.38 kernel, only 112 (around 1.3%) were directly chosen by Linus himself. The kernel project has long since grown to a size where no single developer could possibly inspect and select every patch unassisted. The way the kernel developers have addressed this growth is through the use of a lieutenant system built around a chain of trust.

The kernel code base is logically broken down into a set of subsystems: networking, specific architecture support, memory management, video devices, etc. Most subsystems have a designated maintainer, a developer who has overall responsibility for the code within that subsystem. These subsystem maintainers are the gatekeepers (in a loose way) for the portion of the kernel they manage; they are the ones who will (usually) accept a patch for inclusion into the mainline kernel.

The dm-cache device mapper target was added to the kernel in Linux 3.9. bcache is apparently on track for 3.10

That's interesting. There are lots of people complaining about USB I/O on Linux (e.g. https://bugzilla.kernel.org/show_bug.cgi?id=12309 ), and I've experienced it myself. And many also say that CFQ is quite poor at I/O, especially when it comes to latency, so I'm really surprised that you found it to be the best. Did you try deadline?

I sure hope BFQ becomes the default someday. Blows everything else out of the water as far as latency goes, and sometimes throughput too.

As far as I know, every ath9k device supports AP mode. I have one and run hostapd on it.

More info: http://wireless.kernel.org/en/users/Drivers/ath9k

I use Arch, and decided to stick with ext4 for now--I don't want a filesystem that bleeding-edge, btrfs does not yet directly support swap files, and though my laptop has enough memory to fit a container ship or two (16 gibs, good god...) I'd still rather have one, both for resume and general swappy stuff if ever needed.

Personally I'd like file birth time support (and not just for btrfs) to jog my memory about the times I've made old stuff, but it seems I'd have to move to e.g. FreeBSD for that and I prefer the more-up-to-date-iness of Arch.

I need to offer you credit; you are right. The issue isn't really PAE, it's how the kernel manages memory on 32 bit x86 architectures with more than 1GB of memory installed. PAE simply exacerbates the problem. Here's an explanation of the complaint:

On ia_32 systems, the kernel splits memory into 3 zones; DMA, NORMAL, and HIGHMEM.

ZONE_DMA is the first 16MB of memory, and is generally avoided unless needed (due to lack of available higher memory, or for DMA mappings.) The kernel tries to reserve this address range for devices that use DMA mapping.

ZONE_NORMAL is an address space that is directly accessible to the kernel, and extends from 16MB to 896MB. Kernel data structures are stored in this space, including the kernel page tables. Memory mappings start to consume a lot of memory in ZONE_NORMAL, and thus PAE on ia_32 with a lot of installed memory can cause out of memory issues, even when there is a lot of available physical memory. User data can be allocated into ZONE_NORMAL, but is preferred to be placed in ZONE_HIGHMEM to free ZONE_NORMAL for kernel data structures.

ZONE_HIGHMEM is memory above the 896MB barrier. This address range is not directly accessible to the kernel. In order for the kernel to access anything in this zone, a temporary map must be made into ZONE_NORMAL. These mappings consume pages of ZONE_NORMAL, and suffer a performance hit. User space processes can access these pages directly (handled by the virtual memory manager system, of course.)

Generally, memory will be allocated to ZONE_HIGHMEM, ZONE_NORMAL, or finally ZONE_DMA in that order of preference.

The x86_64 architecture eliminates the need ZONE_HIGHMEM. ZONE_NORMAL extends all the way from 16MB to the end of physical memory. This approach simplifies memory management, improves performance, and is generally more flexible.

You're correct that there was a major issue with my original post... My memory of the kernel architecture had garbled HIGHMEM with PAE, and I was thinking that PAE required mapping pages above 4GB into lower memory. This would of course cause a huge performance penalty for any process consuming memory above 4GB. I deserve downmods for the technical inaccuracy.

Here's a very brief summary of the problems with HIGHMEM:
http://linux-mm.org/HighMemory

Here's a bunch of links used to refresh my memory:

http://www.makelinux.net/ldd3/chp-15-sect-1
https://www.kernel.org/doc/gorman/html/understand/understand005.html
http://unix.stackexchange.com/questions/5143/zone-normal-and-its-association-with-kernel-user-pages

Yes, this is a bit of an oversight on my part. I really should have been discussing the way PAE is implemented on ia32 processors. I had a little bit of difficulty finding information about it online, I'll have to consult my architecture books at home, and will expand on the original post. Here's a bit of the info I could find about PAE weirdness on IA32.

https://www.kernel.org/doc/gorman/html/understand/understand005.html#sec: High Memory

The key quote:

PAE allows a processor to address up to 64GiB in theory but, in practice, processes in Linux still cannot access that much RAM as the virtual address space is still only 4GiB. This has led to some disappointment from users who have tried to malloc() all their RAM with one process.

Secondly, PAE does not allow the kernel itself to have this much RAM available. The struct page used to describe each page frame still requires 44 bytes and this uses kernel virtual address space in ZONE_NORMAL. That means that to describe 1GiB of memory, approximately 11MiB of kernel memory is required. Thus, with 16GiB, 176MiB of memory is consumed, putting significant pressure on ZONE_NORMAL. This does not sound too bad until other structures are taken into account which use ZONE_NORMAL. Even very small structures such as Page Table Entries (PTEs) require about 16MiB in the worst case. This makes 16GiB about the practical limit for available physical memory Linux on an x86. If more memory needs to be accessed, the advice given is simple and straightforward, buy a 64 bit machine.

Linux is just a kernel. Naming the whole system after a kernel seems a bit excessive to me, especially since it would be relatively simple to replace the kernel with other kernels such as the BSD, and no user would be able to tell the difference. Most of the software would still run without modification since the chromebooks are all about web apps and almost no native code.

Moreover, Linus and all other kernel developers game a written consent to everyone to do this.

So the authors of the kernel are fine with this and gave written permission to do it. Google is fine with this and seeks what they perceive to be the best marketing strategy. Who are you to complain? this is really a matter to be resolved between the authors of the kernel and Google, no one else has any skin in this game.

Well, no, you're ignoring the other possibility: users don't get to have both a newer kernel and a useful module at the same time. Coincidentally, I spent much of today in a meeting about a development team in very much that position, where an entire project is potentially being delayed because sorting out basic Linux functionality is now the critical path. So you're really trying that argument on the wrong guy today. :-)

Yes you do have to get the module and the kernel at the same time or all bets are off. An old module will probably work with a minor point revision but there is no guarantee it will. Anyone who uses the binary blobs against the kernel (e.g. NVidia, VirtualBox guest additions etc.) would know this all too well. And that is why the first thing most people do after an update is reinstall their proprietary drivers which usually involves running a script which compiles a shim module to compensate for any differences.

In fact the kernel documentation has a specific file to cover this point. Simply put, providing backwards compatibility or multiple APIs is a burden on the pace of development and impacts on stability and security.

I'm puzzled by your idea that paying so much attention to compatibility might not be a smart idea for open source software.

Compatibility is fine where it makes sense. But this particular thing was a major refactor. Not only that it, it was related to security and privacy. You appear to be suggesting that Firefox should maintain two APIs or some quirks mode just to keep a handful of extensions like Lazarus happy. I hope you can see that from a security perspective what a disastrously bad idea that is, especially when the extension could just be updated.

Go ahead, it's at http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/i915?id=HEAD ...and there's about 19,000 lines in that particular directory (find drivers/ -name i915*|xargs cat|grep -ve '^[/ ]\*' -e ^$ |wc -l), and it depends very heavily on a few other modules (agp, ~2kloc for intel-*; there's a couple more I think...)
That's 21kloc right there, or 3 years if you have the same team that reviewed L4...and almost all of that's changed in the year from 3.4 to 3.8, if I read the output of git diff properly.
Meanwhile, Intel's working on a couple new gpus.

And the Linux equivalent would be using Linux Containers (LXC) over Btrfs.

(The parent poster mentionned OpenVZ, although that one is living out of tree and thus still stuck at the 2.6 generation of kernels, whereas LXC is in mainline kernel).

Well, have a better look before spreading lies. For kernel, web browser and libreoffice

Kernel:
Stable - 2.6
Testing - 3.2
Unstable - 3.2 (released July, 2012)
Current version - 3.8
Those 3.6/3.7 files seen in your link? Experimental. Yeah you could make it work, but then you aren't running Sid anymore. Not entirely. And if you run too much experimental for too long, something is going to end up horribly broken.

Firefox/Iceweasel:
Stable - 3.5
Testing - 10esr
Unstable - 10esr (released March 2012)
Current Version - 19.0

Libreoffice:
Stable - 3.5
Testing - 3.5
Unstable - 3.5 (released February 2012)
Current version - 4.0

YOU DO have very recent packages available, even right now, during the freeze of testing. I haven't checked DE and X, since I don't know what you run (eg: which graphic card, and which environment you like).

I run XFCE on testing, not that it matters.

XFCE:
Stable - 4.6
Testing - 4.8
Unstable - 4.8 (released Jan 2011)
Current Version - 4.10 (released April 2012)

Like I said, Sid isn't bleeding edge. Of the packages here, the newest in Sid is the kernel: 7 months old.

It's also worth noting that drivers receive unblock from the release team so that they can enter stable.

Well that's great (and I genuinely mean that), but a bleeding-edge enthusiast would only see that 3.2 != 3.8.

Were the files over 2GB? I believe that was the IE bug wrt large files: downloading files over 2GB or 4GB (depending on the version of IE) would fail spectacularly including negative progress. It's even documented on kernel.org.

I bought a Samsung laptop at the start of January :( Not only that...I bought it specifically to install Ubuntu :( Bah.

Now what do I do?

I installed Arch in UEFI mode on my new Samsung Series 9 in December... I was getting constant machine check exceptions[1] and found that I had to blacklist the samsung-laptop module from the boot menu (append modprobe.blacklist="samsung-laptop" to your kernel cmdline at boot); this will prevent the samsung-laptop module from loading. Without that I couldn't even boot the Arch USB in UEFI mode! If your Linux distro is using a kernel from 3.7.6+ then this workaround is unneeded, as that module has been disabled from Linux 3.7.6[2]).

Or... you could just choose to install your OS in BIOS mode. :)

[1] http://mjanja.co.ke/2012/12/machine-check-exception-on-samsung-np900x3c-on-uefi-boot/
[2] https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commit;h=98e1ea492c1cf36ea3b391d9b5161681ee4ea18a

Uhm yes, the license text itself? Just diff COPYING in the kernel tree with the one available at gnu.org. Honestly, it's not that difficult.

Anyway, since you were to lazy to do it, the difference is this added preamble (sans some layout changes):

NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of "derived work". Also note that the GPL below is copyrighted by the Free Software Foundation, but the instance of code that it refers to (the Linux kernel) is copyrighted by me and others who actually wrote it.

Also note that the only valid version of the GPL as far as the kernel is concerned is _this_ particular version of the license (ie v2, not v2.2 or v3.x or whatever), unless explicitly otherwise stated.

Linus Torvalds

Welcome to open.

You must take the good with the bad.

Where ANYone can:
sudo apt-get install git-core wget && mkdir -p ~/bin && export PATH=$PATH:~/bin \
      && wget http://android.git.kernel.org/repo && chmod a+x ./repo \
      && mv ./repo ~/bin && mkdir android && cd android \
      && repo init -u git://android.git.kernel.org/platform/manifest.git \
      ; repo sync ; make

Define 386 support, cause the kernel wont work on a 386 chip, hell its hard to find one that supports a pentium, think 2.4 or somewhere around there was the death of that

No, this was very recent. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=743aa456c1834f76982af44e8b71d1a0b2a82e21

Sure, most distros compile for 486 or Pentium and above these days, but the kernel itself could still be built for 386 until just over a month ago.

>> "didn't actually speed Android up."

If you actually read the bug mentioned in the summary - most devs are arguing that explanations about why the fixes work don't make sense in terms of Dalvik (java) that the android bug was filed against - not that it doesn't improve latency or that it doesn't work or there isn't a lower level issue. One developer https://code.google.com/p/android/issues/detail?id=42265#c162 (sorry I don't know enough about android to know if he is part of the core team or not) - is doing testing to measure results of a patch from the mainline linux kernel https://patchwork.kernel.org/patch/1745611/ plus some re-arranging of the android code to see if he has found a lower level solution.

For example:

Similarly, don't be too polite or subtle about things. Politeness easily ends up going overboard and hiding the problem, and as they say, "On the internet, nobody can hear you being subtle". Use a big blunt object to hammer the point in, because you can't really depend on people getting your point otherwise.

I fail to see the impressive part. Impressive would have been fixing GCC to optimize simple functions on its own.

memcmp (and the other functions like it) is something that gets repeated in slight variations in code A LOT, and is trivial to implement. This is almost a textbook optimizer target if I've ever seen one.

The optimizations talked about here are specific to processor models (e.g. AVX and SSE for intel) and not just architectures. Compiling them into programs is a bad idea^^, so improving gcc is not an option. The glibc mem* functions have implementations for each of those processor features and the right function to use gets implemented via the STT_GNU_IFUNC mechanism based on the features the current processor has.

^^ If you don't know why it's a bad idea, it's because you don't want to compile your program for every machine you want to run it on. You want to compile for the general architecture so that it can be distributed widely.

They're useful if you have multiple error conditions...just goto an error cleanup path. Also useful for skipping to the end of a loop but where you still want to do something before the next iteration.

See nohz_kick_needed() and distribute_cfs_runtime() in at http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=kernel/sched/fair.c for examples of each scenario.

Since I haven't used a goto since the 1980s, except in assembler, I'd love to see some examples.

And I mean of actual gotos, not similar statements like break and continue.

Then you may want to look at the linux kernel sometime.

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=mm/vmscan.c;h=adc7e9058181eb4d38c2f22d77bd1e413d3457e7;hb=HEAD#l674

That lovely function uses a lot of gotos for obvious reasons. Should be obvious why they use all these gotos (there are other examples in that source file)

So then I read the second link and it actually says:...

The actual git log explains this:

Merge branch 'x86-nuke386-for-linus' of git://git./linux/kernel/git/tip/tip

Pull "Nuke 386-DX/SX support" from Ingo Molnar:
  "This tree removes ancient-386-CPUs support and thus zaps quite a bit
    of complexity:

The part you quoted was badly phrased, but technically correct.

I don't see any indication that a) this has any relation to the size of the directory

The cited bug points out a problem with readdir(). This manifests itself as failures with other software, including dovecot (where maildir is used) and bonnie++. Some of those other bugs were reported and marked as duplicates, some weren't.

Ultimately it boiled down to a flaw in Linux NFS that was fixed by Trond Myklebust and was still perculating through distributions over a year later.

Never in years has it given me one problem, but hey, that's just me.

Yeah, that's just you. Me? I've been watching hapless administrators discover NFS flaws since the 90's and I have long since abandoned NFS as a serious tool for production operations. It's fine in most cases as a file share for interactive use (/home and ad hoc shares) and not much else. Under certain conditions with extremely good NFS implementations (netapp, for example) you can pull it off. The other 99% of the time it's just a mistake.

Why not btrfs and backups?

BTRFS is not stable! I just lost my /home and all it's snapshots, two days ago.

"You should keep and test backups of your data, and be prepared to use them."

Yes I know about the latest tools. In the end I had to do a btrfs-restore.

https://btrfs.wiki.kernel.org/index.php/Restore

Stable or not, Oracle Linux has already declared Btrfs "production-ready" https://emeapressoffice.oracle.com/Press-Releases/Oracle-Announces-Production-Release-of-Unbreakable-Enterprise-Kernel-Release-2-for-Oracle-Linux-29ab.aspx

Why not btrfs and backups?

BTRFS is not stable! I just lost my /home and all it's snapshots, two days ago.

"You should keep and test backups of your data, and be prepared to use them."

Yes I know about the latest tools. In the end I had to do a btrfs-restore.

https://btrfs.wiki.kernel.org/index.php/Restore

BTRFS will be quite interesting: https://btrfs.wiki.kernel.org/index.php/Main_Page. And of course ZFS: http://en.wikipedia.org/wiki/ZFS

I was using git long before I knew any nitty gritty details. Here's a useful site for beginners: Everyday GIT With 20 Commands Or So

--Sorry bout that; it's just the way you came across. Personally, I had only a vague idea that Reiser4 was still in semi-active development until I saw this Slashdot headline.

--I did come up with a few links, but as for when $bug was fixed in Reiserfs, you would prolly have to search the kernel mailing lists or the project's home page.

https://wiki.archlinux.org/index.php/Reiser4

http://en.wikipedia.org/wiki/Reiser4#History_of_Reiser4

https://reiser4.wiki.kernel.org/index.php/FAQ

And the thin and light blurb. No Linus, I actually happen to like a big screen.

You're entitled to your preference, but some people happen to like a computer that fits in the bag they already have, like my 10" Dell laptop.

And I like dual drives, a DVD drive/Blue ray, and decent speakers.

All of which I have hanging off a USB hub at home. One plug, and I have a mouse, keypad (for Blender, which works acceptably on a GMA 3100), CF/SD writer, and a fourth port to connect either an external hard drive or a tablet. I don't need these peripherals while riding the bus to and from work.

If I want a fairly crippled system - I can go get one based on an ARM platform

The advantage of x86 is that it runs the non-free applications you already have. Look at the license of Linux: it's not the GPLv2 alone but the GPLv2 with an explicit exception (or clarification) to allow the use of non-free applications. "NOTE! This copyright does not cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does not fall under the heading of 'derived work'."

Isn't the Linux kernel and its API expressly exempted from the viral nature of the GPL? Per the COPYING file: “NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of "derived work".”

i agree that git is a great tool, especially when i do not have to use it; as Linus Torvalds put it, git stands for:

1. “Global information tracker”: you’re in a good mood, and it actually works for you. Angels sing and light suddenly fills the room.
2. “Goddamn idiot truckload of sh*t”: when it breaks.

One specific use of git that i love, and where you never have to touch git at all, is SparkleShare, granted that i self host it in a mini NAS

I've been using btrfs on two computers for about a year now. I'd say it's quite stable. I'm using it for /home as well as a data partition, with zlib compression on /home. The snapshot feature is amazing and should be used liberally. Early on I experienced some disk corruption (mostly due to rapidly switching kernel versions 3.0, 3.2, 3.4, 3.5), which was not a problem because there existed snapshots on the disk. The primary partition can be corrupted, but if you have an uncorrupted snapshot, you can mount it. So, it's a good idea to get in the habit of making regular snapshots. I've been doing it by hand, but a daily rotating snapshots would be a great idea for reliability. There are many cron jobs, shell scripts and whatnot to accomplish this (e.g. Autosnap). Furthermore there is apt-btrfs-snapshot which on Debian/Ubuntu systems will automatically snapshot whenever upgrading/installing a package. This basically takes care of changes in /usr (and you'll need a cron job for /home). The only real drawback I've encountered is that dpkg is very slow (likely due to my use of zlib compression). But dpkg's database access has been a snail for a long time and is dpkg's problem (and I hope someone looks into this soon, it's pissing me off -- zlib just exacerbates the problem). But since apt-get upgrade can run in the background while I'm working, it doesn't really bother me.

I'm also using RAID1 on all magnetic disks (plus one SSD not in a RAID configuration). After countless disk failures, I just don't trust magnetic disks any further than I can throw them. And, they are cheap enough that two instead of one is not a huge burden. In the last year, I have not had occasion to recover from a failure due to RAID1, but I have experimented with mounting one half of the RAID1, and it operates normally. There are a few tricks to re-sync the drives when its partner is re-added to the array, that one should be aware of. It's not fully automatic. One of my RAID1 arrays is over two LVM volumes, with the left half consisting of a single 3 TB disk, and the right half consisting of three disks concatenated into a single LVM. This makes it easier to add disks later. LVM and btrfs can both resize.

A couple things to be aware of: you cannot place a swap file on a btrfs partition. So use another filesystem, a full partition, or just buy more RAM (my preferred solution). You should not use a kernel version less than 3.5. There have been many fixes between 3.0 and 3.4, and you're asking for trouble if you use btrfs on a 3.0 or 3.2 kernel. Since I installed 3.5 kernels on all my machines, I have not had any btrfs-related problems. FWIW, I regularly have to reboot because ATI's shitty video driver causes a kernel panic, sometimes via a hard reset. I have yet to see any filesystem corruption due to this. And everyone should know how to use the Magic SysRq key in the event of kernel panics too. (Alt-SysRq- REIUSB should unmount, sync, and boot, leaving filesystems in a consistent state)

I highly recommend BTRFS at this point. I'm not sure the distributions are up to noob auto-installs, but if you like to do things yourself, it offers a lot of advantages over ext4.

"If you have all the code on a machine, then that machine can't be connected to the internet, sorry."

You need to tell that to the rest of the world, who have been doing it that way for decades.

"So for a FOSS project, you don't expose the master copy of the source to the internet."

Really? Again, you don't know how best practices work.

"When it's commercial software the difference is that the source code is commercially valuable (as opposed to just valuable). And just try to guess how carefully that audit trail needs to be guarded."

If only there was a way to do it right! You are missing the whole point, which is that if you make it impossible for people to get and build the code they are working on without jumping through a million hoops, they will simply work around it by grabbing a local copy on their poorly secured machines, including laptops. This is security 101, actually.

Also, there is no commercial viability to stolen proprietary code. Anyone who tries to package it and sell it as their own will be caught. It is also more costly to try to reuse a code base when nobody has any experience with it than it is to simply do it yourself. Only a complete moron would try to steal proprietary and try to leverage it commercially. The only place where an air gap makes sense is between the code signing infrastructure and the rest of the world. An air gap between your code base and your developers is the absolute last thing you want.

In my experience this is the exact opposite. Much free source control software has documentation 'when the developers get around to it'.

In late 2005, git documentation was kinda lacking.

Seven years later in 2012 you buy a copy of "pragmatic guide to git" from you know who, I think there's an oreilly book, Scott Chacon's book is CC licensed and freely downloadable at the link below, but the kernel wiki at the link below is really all you need.

http://git-scm.com/book

https://git.wiki.kernel.org/

If you have too much money and want literal hand holding I believe there are in-person classes and seminars available. A majority (all?) modern devs already use some form of version control and much like languages learning the 3rd takes about 5% the time of learning the 1st, so simply ask a more experienced coworker. I can teach someone the basics of "how to use git at $work with the cheat sheet" in, eh, 5, 10 minutes tops. If they're too dumb to figure it out given a sheet that shows exactly what to type at exactly what time, I don't want to be stuck cleaning up the mess they would make of the code, so its excellently self limiting in that manner.

[quote]There are some interesting parallels here. Google is starting to look more and more like an operating system, with the menu bar at the top and the integration of a lot of their services into a desktop-like interface. [/quote]

You are mistaken, operating systems do not offer anykind (I repeat, not anykind) user interface. Operating system is just a few hundred kilobytes to megabytes size software what allocates hardware resources for processes (every other software) and operates all of them so we can have more than just one program (process) running by CPU.

Google use Linux operating system (what is a monolithic operating system) in their products, from Android to their own servers and ChromeOS software system

You can download whole Linux operating system source codes from there and then compile it as you want. But notice, you need more than just operating system to get your computer work, as you need programs, what needs libraries etc. So you end up having a OS + system software + system programs + software platforms + application programs etc.

And no, you don't need to have software what gives you a user interface (shell like a Bash or graphical user interface like X11 + KDE) to get operating system working, but lots of softwares and especially YOU need such software to work with computer, operating system just runs all of them.

They tried writing drivers themselves and again they sucked.

Dead wrong. Intel drivers are excellent and I and many others have had great success with them. They also usually work quite closely with the kernel community as a whole to make sure things work as expected; that's why what this article is saying seems to out of character for Intel. For instance, try searching for "intel.com" in the git commit log. Lots of kernel developers are on Intel's payroll, including core people like Alan Cox.

Hell if you are worried about power you can buy one of those little plug computers or my personal favorite the little cheap E350 AMD kits. Those things are cheap, make great mini-servers or office boxes, only draw about 18w under load and less than 6w on average, great little units

Seconded, however you'd best steer clear of the Asus and Asrock boards if you plan on doing anything with the PCI slots on those boards. They all use the ASMedia 1083 pci bridge, which happens to be broken beyond belief. See here and here. TL;DR: the controller has a hardware bug where it fails to deassert its interrupt status, causing IRQ storms which effectively makes connected devices useless.

NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of "derived work".

If this "NOTE!" is proved necessary, Oracle could claim copyright infringement against anyone who bundles a modified OpenJDK with GPL-incompatible applications.

Yes, the patches (1,2) were merged back in May.

Yes, the patches (1,2) were merged back in May.

This networkworld.com article gets submitted to /.:

A host of small modifications and a large number of system-on-a-chip and PowerPC fixes inflated the size of release candidate No. 7 for Version 3.5 of the Linux kernel, according to curator Linus Torvalds' RC7 announcement, made on Saturday.

LAST TIME AROUND: Linux kernel 3.4 released

Torvalds wasn't happy with the extensive changes, most of which he said he received Friday and Saturday, saying "not cool, guys" in the announcement. However, the occasionally combustible kernel curator didn't appear to view this as a major setback.

"Now, admittedly, most of this is pretty small. The loadavg calculation fix patch is pretty big, but quite a lot of that is added comments," he wrote, referring to the subroutine that measures system workload.

However, he noted, there were also the assorted changes for SoCs, PowerPC compatibility, USB and audio to be folded in, forcing a comparatively large RC7.

"Ok, so it's still not *huge*, but it's bigger than -rc6 was. I had hoped for less," wrote Torvalds.

He also hopes that it won't be necessary to deploy an eighth release candidate before Version 3.5 of the kernel can be properly rolled out, and urged the community to "go forth and test."

Among the biggest new features expected in Linux 3.5 is enhanced compatibility with the ARM processor family, which are used in a wide array of low-cost computing devices. Several ARM-related fixes are part of 3.5-RC7, according to the official announcement email and changelog.

The H-Online reported earlier today that the final version of Linux 3.5 should be deployed next weekend, if all goes well with RC7.

The h-online.com article the networkworld one is a rehashing of:

Over the weekend, Linus Torvalds reluctantly published a seventh release candidate (RC7) for the 3.5 Linux kernel. In the LKML announcement email, the Linux creator says that he originally thought another RC would not necessarily be required; however, a large number of small pull requests submitted by developers late last week necessitated an additional RC for testing, leading Torvalds to tell the developers, "Not cool, guys. Not cool."

These changes include media fixes, random SOC fixes and PowerPC fixes, as well as patches for the leap second bug that caused Linux systems to freeze because of permanent high CPU loads that resulted in increased power consumption and wasted electricity. "Ok, so it's still not *huge*, but it's bigger than -rc6 was," said Torvalds, adding, "I had hoped for less."

Linus has asked the kernel developers to test the rc7 release to "make sure it's all good", and is hoping that he "won't have to do an -rc8". Barring any major problems over the coming week, Linux3.5 will likely be released next weekend. An overview of the changes made in the 3.5 kernel can be found in TheH's Kernel Log mini-series "Coming in 3.5" which examines the various subsystem developments in the upcoming release.

Review each article and notice what is and what is not a link, and where the links lead.

This networkworld.com article gets submitted to /.:

A host of small modifications and a large number of system-on-a-chip and PowerPC fixes inflated the size of release candidate No. 7 for Version 3.5 of the Linux kernel, according to curator Linus Torvalds' RC7 announcement, made on Saturday.

LAST TIME AROUND: Linux kernel 3.4 released

Torvalds wasn't happy with the extensive changes, most of which he said he received Friday and Saturday, saying "not cool, guys" in the announcement. However, the occasionally combustible kernel curator didn't appear to view this as a major setback.

"Now, admittedly, most of this is pretty small. The loadavg calculation fix patch is pretty big, but quite a lot of that is added comments," he wrote, referring to the subroutine that measures system workload.

However, he noted, there were also the assorted changes for SoCs, PowerPC compatibility, USB and audio to be folded in, forcing a comparatively large RC7.

"Ok, so it's still not *huge*, but it's bigger than -rc6 was. I had hoped for less," wrote Torvalds.

He also hopes that it won't be necessary to deploy an eighth release candidate before Version 3.5 of the kernel can be properly rolled out, and urged the community to "go forth and test."

Among the biggest new features expected in Linux 3.5 is enhanced compatibility with the ARM processor family, which are used in a wide array of low-cost computing devices. Several ARM-related fixes are part of 3.5-RC7, according to the official announcement email and changelog.

The H-Online reported earlier today that the final version of Linux 3.5 should be deployed next weekend, if all goes well with RC7.

The h-online.com article the networkworld one is a rehashing of:

Over the weekend, Linus Torvalds reluctantly published a seventh release candidate (RC7) for the 3.5 Linux kernel. In the LKML announcement email, the Linux creator says that he originally thought another RC would not necessarily be required; however, a large number of small pull requests submitted by developers late last week necessitated an additional RC for testing, leading Torvalds to tell the developers, "Not cool, guys. Not cool."

These changes include media fixes, random SOC fixes and PowerPC fixes, as well as patches for the leap second bug that caused Linux systems to freeze because of permanent high CPU loads that resulted in increased power consumption and wasted electricity. "Ok, so it's still not *huge*, but it's bigger than -rc6 was," said Torvalds, adding, "I had hoped for less."

Linus has asked the kernel developers to test the rc7 release to "make sure it's all good", and is hoping that he "won't have to do an -rc8". Barring any major problems over the coming week, Linux3.5 will likely be released next weekend. An overview of the changes made in the 3.5 kernel can be found in TheH's Kernel Log mini-series "Coming in 3.5" which examines the various subsystem developments in the upcoming release.

Review each article and notice what is and what is not a link, and where the links lead.

From my own machines and comparing notes with some other people (all in all, about 3k servers) the bug seems to affect machines randomly. Known facts:

There's a kernel patch that fixes the supposed issue: https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=6b43ae8a619d17c4935c3320d2ef9e92bdeed05d

Affects Debian stable a lot.

Affects Java and Virtualbox (starts using too much CPU).

Affected my browser (iceweasel on debian testing).

Affects SOME mysql installs (5.1 and 5.5, but not all, and of two identical installs one might be affected, the other not).

My own Debian Stable server running 2.6.32 and MySQL 5.1.63 had zero problems. It is also an NTP pool stratum 2 server but it worked just fine.

More interestingly, none of the 1.600+ servers at work had any problems. About 400 of these are Linux, mostly Debian (various distributions) but also some RHEL and some CentOS. There are also about 20 OpenBSD and FreeBSD servers which also performed flawlessly.

From my own machines and comparing notes with some other people (all in all, about 3k servers) the bug seems to affect machines randomly. Known facts:

There's a kernel patch that fixes the supposed issue: https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=6b43ae8a619d17c4935c3320d2ef9e92bdeed05d

I don't think that's the issue. The issue discussed in this lklm thread is a different issue with, presumably, a different John Stultz fix.

The fix has been posted at lot of places: /etc/init.d/ntp stop; date; date `date +"%m%d%H%M%C%y.%S"`; date; /etc/init.d/ntp start

Presumably meaning "workaround" rather than "fix".

(I'm all for switching unix time to a simple counter and leaving it to the calendar libs to put the leap seconds where necessary)

Sounds good to me, but I thought that was a good idea back in the late '80's; the POSIX people thought otherwise, so....

At least as I read RFC 5905, time stamps in NTP packets are essentially "simple counters", and count positive leap seconds and don't count seconds removed with negative leap seconds. I'm not sure what an NTP implementation is supposed to do with the "leap indicator"; that might be dependent on what sort of time the system is supposed to provide to applications. I don't know whether the Linux kernel giving a damn about leap seconds is due to it trying to supply "POSIX time", i.e. time represented as "seconds since the Epoch" rather than as the number of seconds that have elapsed since the Epoch (yes, the two are different), or if it has to do that to function as an NTP client.

the difference being this bug was patched already it only affected systems the were not kept up to date.

A bug, perhaps. This bug, perhaps not.

The bug has already been fixed for months now

A bug might have been fixed for months now, but I don't think that's the bug here.