Slashdot Mirror

Competitors to Microsoft exist: Apple, Linux

Competitors to Yahoo exist: Google, etc.

Competitors to MySpace exist: Facebook, etc.

Competitors to YouTube exist: Revver, Vobbo.

The network makes it difficult, but nobody's ever given up because something was difficult. There are always options, and yes - there can be significant barriers to entry, but it's never "impossible".

Sure I could report it to the lkml, but chances are they'll need more than "Tyan 2882 and UHCI no work."
That's right, but the procedure is fully documented here: http://www.kernel.org/pub/linux/docs/lkml/reportin g-bugs.html

Well maybe you should stick with 2.6.16? You don't necessarily have to upgrade everytime a new kernel comes out. Also I believe you report kernel bugs to http://bugzilla.kernel.org/. To report a bug all you need to do is list your hardware config, kernel config, dmesg and basic outline of your problem.

Yes - they will need more than "Tyan 2882 and UHCI no work." - in the case of kernel bugs stopping previously working functionality - you can use the excellent git bisect functionality to quickly (within a few reboots) narrow down exactly which patch broke the functionality. For instructions - see http://www.kernel.org/pub/software/scm/git/docs/ho wto/isolate-bugs-with-bisect.txt malc

May I ask what you do with over 5GB?

I routinely use 20-30 GB/month, and that's when I don't use BitTorrent. 5 GB/week would keep me pretty much perpetually bandwidth-limited.

How many Linux distributions can you download and USE in one day?

The last Debian release alone was 8.5 GB, and that's only for i386. Source code is another 8.8 GB. (These links are for reference only, if you want to download Debian CD/DVDs, go here to avoid flooding the kernel.org mirror.)

On top of that, you'll probably want to download a live CD such as Knoppix.

But to partly answer your question, I've recently downloaded 5 distros in one day. It was 3 different versions of Mandriva (which is a terribly-designed OS, IMHO), Fedora Core 5, and Knoppix. Coincidently, it was because I was doing some work my university hired me to do (though I don't live on campus).

Personally, though, I'm not sure that all students in residence should be required to pay for more bandwidth than is reasonably considered necessary for their education, so 5 GB/week is probably fine as a baseline, as long as:

1. No punitive actions are taken for exceeding this bandwidth. (Just throttle the connection once usage gets too high, which will happen legitimately from time to time);
2. The traffic is metered outside the local network (local traffic is exempt); and
3. Individual students have the option of paying for better service at a rate comparable to what is offered by high-speed Internet providers in the local area. Alternatively, students could have the option of getting third-party high-speed service to supplement the baseline service provided by the university.

Basically, people in university residences should have access to decent bandwidth, but it doesn't necessarily need to be provided automatically.

May I ask what you do with over 5GB?

I routinely use 20-30 GB/month, and that's when I don't use BitTorrent. 5 GB/week would keep me pretty much perpetually bandwidth-limited.

How many Linux distributions can you download and USE in one day?

The last Debian release alone was 8.5 GB, and that's only for i386. Source code is another 8.8 GB. (These links are for reference only, if you want to download Debian CD/DVDs, go here to avoid flooding the kernel.org mirror.)

On top of that, you'll probably want to download a live CD such as Knoppix.

But to partly answer your question, I've recently downloaded 5 distros in one day. It was 3 different versions of Mandriva (which is a terribly-designed OS, IMHO), Fedora Core 5, and Knoppix. Coincidently, it was because I was doing some work my university hired me to do (though I don't live on campus).

Personally, though, I'm not sure that all students in residence should be required to pay for more bandwidth than is reasonably considered necessary for their education, so 5 GB/week is probably fine as a baseline, as long as:

1. No punitive actions are taken for exceeding this bandwidth. (Just throttle the connection once usage gets too high, which will happen legitimately from time to time);
2. The traffic is metered outside the local network (local traffic is exempt); and
3. Individual students have the option of paying for better service at a rate comparable to what is offered by high-speed Internet providers in the local area. Alternatively, students could have the option of getting third-party high-speed service to supplement the baseline service provided by the university.

Basically, people in university residences should have access to decent bandwidth, but it doesn't necessarily need to be provided automatically.

MS sells the OS Windows. There is no need to include "3rd party" functionality.

Linux is just an OS too. Yet its ok for them?

First off, Linux is a kernel, not a complete OS. Go on to http://kernel.org/ and download some DVD authoring software from there. I'll wait. Not there is it?

Linux distributions bundle a kernel with the other stuff (from the GNU project, from X.org, from the GNOME and KDE projects, etc.) to make it work. Plus, Linux distributors aren't selling you just an OS either. A desktop Linux distribution is a complete desktop operating system bundled with a complete set of applications and all of the spit and polish to make it pretty and work seamlessly.

http://www.kernel.org/software/mon/ I was one of the implementation crew for small noc (about 7 people incl. managers) and approx 150 machines in various locations.. I reviewed quite a lot of free software and while most of them where looking quite nice (nagios/bigbrother/etc.), allmost all of them where filled with features that where really not essential just for "monitor the healt of the system" so i ended up with mon. Mon, for me was really the "unix way" of creating stuff, make things easy/simple and extend it with other tools.. The generic layout we used was net-snmp on client hosts either being polled in intervals or sending traps to the main machines.

http://www.kernel.org/pub/linux/kernel/v2.6/

The Quickest Patch Ever that I know is the 2.6.8 to 2.6.8.1 patch which was released 5 hours and 10 minutes after the affected version's release.

the real patch here
http://www.kernel.org/


OMFGROFFLEZ!!1!!! Yuo r teh intarweb COMEDY GENIUS!!!!1!

http://www.kernel.org/

Slashdot, the most left-wing computer-related website in the world!

Nah, Steve Ballmar tells me that this site is a real bastion of communism.

2.4 is old but by no means 'dated'. 2.4 is significantly leaner than 2.6, runs on old hardware and has a lot of backports from 2.6 http://kernel.org/pub/linux/kernel/v2.4/ChangeLog- 2.4.33

Even DSL uses 2.4. I still use 2.4 on my old PIIs and newer hardware myself.

Slack aims to run on as many types of hardware as possible. Besides, you can always compile your own 2.6 kernel into your slack system.

Um, there is no body that has oversight for the Linux kernel. As a public service announcement for you, most of what people call "Linux" is actually the Linux kernel plus the GNU Free Unix base and a windowing layer. There is no maintaner because the because the various licences that cover these code bases (including the gpl v2) are permissive. You are allowed to use the code as long as you list in your own documentation where the code came from and who it is copyrighted to. Usually, there are conditions in a particular license where derivative code must be released under the same license. Some licences such as the gpl require you to publish your source code while others such as the bsd license doesn't require this and also allows commercial use without any payment.

First, pick the list that matches the desired job skills closest. I suspect you want some people who can operate that 1000+ machine environment, so http://vger.kernel.org/vger-lists.html#linux-admin might be the place to go.

Second, make it clear what your post is about, so people who are NOT looking for a job can simply ignore it. Use a topic like "Job Offer: Startup looking for Linux admins".

http://vger.kernel.org/

You'd have to post it as a lament though.

Man, I wish I could find some programmers as good as you guys for my positions starting at $95k with full medical and dental. It's amazing how many people turn down our 401k and stock option program, especially with the incredible opportunities for advancement.

Anyway, you make a good point about user mode autodetect with the current situation, although I still think in-kernel autodetect should be the goal.

http://www.kernel.org/

"Windows 2000 or later". Windows 2000 came out around 1999-2001. Linux 2.6.17.6 came out 4 days ago, yet it refuses. [Slashdot "foot" icon here]

That's the way it's *supposed* to work, and I'm willing to grant that it may well work that way on stable. I'm running testing.

(OTOH, I was shocked whin an install of debian-keyring didn't tell me "you already have the newest version installed". Something strange here... but AFTER installing it, and running update again:
Reading package lists... Done
W: GPG error: http://security.debian.org/ etch/updates Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 010908312D230C5F
W: GPG error: ftp://mirrors.kernel.org etch Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 010908312D230C5F
W: You may want to run apt-get update to correct these problems

Just like before [though *I think* there were two unknown keys before I did the install].)

FWIW, I do have some non-debian repositories in my sources...but previously it has complained about packages not-being signed with a known key that I have KNOWN were from the Debian repository. Now it isn't saying what package it's referring to, so I can't tell if this is still true. (I'm also quite certain that I've installed debian-keyring before, though I'm only "rather certain" that it's been since I last did a clean install.) I'd been presuming that this was a common problem with Etch...

Microsoft still has an obligation to (legal) users of XP. These users supposedly paid for a product. Basically Microsoft is giving the finger to it's XP consumer base. Although, no surprises there.

The Linux kernel can be freely downloaded at http://kernel.org/ I don't think upgrading to Vista will be a zero-cost venture, especially since the hardware requirements are excessive.

When I need Linux source code, I go to http://kernel.org./ Or sourceforge for any godzillion Open Source projects and get it. Or openoffice.org. Also, I can contribute, make changes, in other words code is not a snapshot. It's a river.
I think EU is absolutely correct: Microsoft exhibits barbaric business model based on closed source and some fairly scary business practices. This cannot be good for EU, or for China, US, Russia, India or any country in the world. Go, EU, go.

1. You're gonna need multiple Linux flavors and versions from multiple sources that specialized in these platforms.
   
   • ALPHA
     
   • ARM
     
   • I686
     
   • IA64
     
   • M68K
     
   • PowerPC PenguiPPC Denx
     
   • MIPS
     
   • S390
     
   • SuperH
     
   • UltraSPARC
     
   • X86_64
     
   
   
2. To determine which versions of crosstool (compiler, linkers, debugger), check out The Matrix Guy (Dan Kegel), or more specifically THE MATRIX of workable gcc/g++/ld/gdb.
   
3. To ease your pain of figuring out the "./configure" options, definitely checkout PTXDist. Menuconfig is similar to Linux 'make menuconfig'. PTXDist also help to build a root file system in a jiffy, which in my book, is a PLUS!
   

Wrong!! Ints on most 64-bit CPUs, including AMD, are 32-bit.
Only longs and pointers are 64-bit, which is a negligible amount of space on average.

Only heavy pointer activity is going to slow you down, but that is offset on average by several factors. Such as the extra registers on AMD64 compared to X86. And faster amd64 memcpy and string functions in glibc. (Yes, shuttling 64-bit chunks of data around can be more efficient than 32-bit ones.)

You also may have noticed a performance patch for a 10gigE card in a bleeding edge kernel today as well.
http://www.kernel.org/pub/linux/kernel/v2.6/snapsh ots/patch-2.6.17-git3.log
"Introduce __iowrite64_copy. It will be used by the Myri-10G Ethernet
        driver to post requests to the NIC. This driver will be submitted soon.

        __iowrite64_copy copies to I/O memory in units of 64 bits when possible (on
        64 bit architectures). It reverts to __iowrite32_copy on 32 bit
        architectures."

Moral of the story is 32-bit is the dark ages. The day will come (soon!) when only embedded devices will be 32-bit.

On the other hand, this obscurity probably prevents the newbie compiling a crap and buggy kernel and destroying his/her system and serves a purpose. Who knows?

I too am a fan of Slackware, and am typing this on a Slackware 10.2 system with a 2.6.16.9 SMP kernel (built from the kernel source), to support one of those new dual-core Pentium 4 gizmos. In other words, it goes like stink...

Even though I can download the CD images, I always buy a copy of each new release.

It's not a crime for a Linux system to look like Unix, and if your hardware barfs over a text-based install, you really do have a problem. I like being able to download source (including kernels), build it and it just works. I still have nightmares about the time I tried to help somebody upgrade a kernel on a Fedora Core box. Shudder.

Slackware isn't a pre-packaged Linux system in a can: open the can and pour it out, ready to go. It's a construction set for building any kind of Linux system you want. And it's all the better for it.

Thanks, Patrick.

...laura

$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torv alds/linux-2.6.git linux-2.6
defaulting to local storage area
Unpacking 242108 objects
  7% (18843/242108) done

Actually...
Rather than assume anyone^H^H^H^H^H^Heveryone on slashdot has any brains when it comes to Securing SSH let me give you some tips I/Other people have

Restricted ssh shell for scp/sftp http://sublimation.org/scponly/
Patch to lock out IPs brute forcing passwords http://ethernet.org/~brian/src/timelox/

Can add restrictions to authorized_keys file
from="hostipaddress",command="/usr/local/sbin/ssh_ command_allow_rsync",no-port-forwarding,no-X11-for warding,no-agent-forwarding,no-pty ssh-rsa AA...= backup_key

Securing sshd in /etc/ssh/sshd_config
        Protocol 2
        PermitRootLogin without-password
        PasswordAuthentication no
        ChallengeResponseAuthentication no
        ClientAliveInterval 60
        ClientAliveCountMax 30

The first line says to stop using the old, lower security ssh protocol-1.

The second line is a hedge that says never allow root logins using the unix password -- always use some other authentication.

The third line says don't allow skey authentication. It is a good idea to turn this off if you aren't using skey at this time. (Skey implements a series of non-reusable, one-time passwords. If you were using it you would know.)

The fourth and fifth lines simply make sure that any connection to a client that doesn't respond at least once each half hour gets closed. After editing the sshd file, restart sshd or reboot for the changes to take effect.

31-12-2004: new rate-limiting feature in -current. This would block hosts that exceed 10 connections per 60 seconds.
    pass in on $ext_if proto tcp to $ext_if port ssh flags S/SA \
                keep state (max-src-conn-rate 10/60, overload )
    block in on $ext_if proto tcp from to $ext_if port ssh

Also my previous post to do with limiting user connections to SSH during the scarey SSH port scanning days of not so long ago...
http://it.slashdot.org/comments.pl?sid=156058&cid= 13084357

Repeated here for your convenience:
Ways around SSH Brute forcing (Score:1)
by meridian (16189) on 11:06 AM July 17th, 2005 (#13084357)
(http://www.thief.net/)
There are esentially three ways to fix this problem.
The first is to patch sshd which is probably the least preferable way as you would need to continually keep patching with each upgrade. But this seems effective allowing you to exec a system command such as iptables.
http://ethernet.org/~brian/src/timelox/ [ethernet.org]

The second is to use iptables to limit connection attempts from an IP address. One problem with this is people who use scp alot may quickly rack up that connection limit.
Here is a recent example from the iptables mailing list
iptables -A INPUT -p tcp --dport 22 -s ! $My_Home_Firewall_IP -m state --state NEW -m recent --name SSH --set --rsource -j SSH_BF
iptables -A SSH_BF -m recent ! --rcheck --seconds 60 --hitcount 3 --name SSH --rsource -j RETURN
iptables -A SSH_BF -j LOG --log-prefix "SSH Brute Force Attempt: "
iptables -A SSH_BF -p tcp -j DROP

The best in my opinion is a pam module found at http://www.kernel.org/pub/linux/libs/pam/modules.h tml [kernel.org] called pam_abl
This does not have the problem of the IPTables method that may mistake multiple fast scps etc as an attack attempt, and will not require coninutal repatching of the kernel such as the timelox patches.

"ZIP is good enough. RAR and 7z (and bz2 and ...) are stupid.
WAV is not a compressed format. Apples and oranges."

Damn straight

You mean like these?

Without going as far as far as DBSD's threading it would appear you could reduce the number of locks currently used in the Linux TCP stack at the expense of adding a bit of the TCP stack to userland. Take a look at these slides on Van Jacobson's Net Channels where Linux's TCP performance is improved by implementing channels (seen via Dave Miller's blog).

I did go looking for links but it's been hard going. One reference at Linux Weekly News that Linus wanted the 2.3.x dev cycle to be "half the length or less" of the 2.1.x dev cycle. (In reality, 2.3 took 18 months vs. 2.1's 27 months--shorter, but only by a third.)

Then, when 2.5 kicked off, they said they wanted to shorten 2.5.x over 2.3.x, and, well, 2.5.x took 25 months.

BTW, you can look at kernel.org if you don't beleive me on the timeline.

What the kernel really lacks is a good standard for coding practices, like say adding comments and indenting at least somewhat sensibly [yeah I know for some of you "elites" you can take reading a complete lack of consistent indentation but for the rest of us ...]

The kernel includes a document detailing the coding style to use. It lives in Documentation/CodingStyle.txt You can read the current version from Linus' Git tree here. If you spot anything in the kernel that doesn't follow CodeingStyle.txt you should submit a patch to the kernel janitors to fix it up.

I haven't seen a posting point this out, but there is a bugzilla site setup for kernel bugs. http://bugzilla.kernel.org/. Some of the bugs in there look pretty old, but there does show to be active entries in there also. AFAIK, the site has been up for a couple of years or so.

As another poster pointed out, people who can identify and fix bugs that they didn't create should be in higher demand than who can't. Don't know if it generally possible, but I don't see it being unreasonable for developers to point to specific bug entries that they closed out on their resume/portfolio.

I know Linux doesn't really "do" *cohesive documentation* or anything like that but a table of { kernel versions vs. hardware drivers (with both module name and an actual descriptive name, and author/contact person/website) -> status (not supported; present but experimental/untested; available from a third party patch/module; present but bugs outstanding; stable) } is one of the most basic and most useful things that could be placed on http://www.kernel.org/ and actively maintaned by the driver authors and other developers.

> Is there no bug tracking database for the kernel?

Yes. http://bugzilla.kernel.org

If I have old hardware that doesn't run 2.6, I can and do drop back to an older kernel. Hell, 2.0.40 came out in 2004. And note the size! That kernel boots as fast on my 133MHz machine as 2.6 does on my 1GHz frankenstein. New features on a new kernel mean nothing on hardware that can't use it. If you want to keep running a new kernel on old hardware, obviously you're going to suffer plenty of bloat, as evidenced in the Windows world. And speaking of that, if MS had kept their old version on the market. They could have slimmed down the new versions considerably. Of course, most of us know that older versions are MS biggest competition, so that's why the lockdown, all made possible by our gracious IP overlords. So be it. I don't need them anymore. Even Apple put up their old old versions for free. But it doesn't run on new hardware. And their new software doesn't run on old hardware. And furthermore, wouldn't it be easier to troubleshoot and fix bugs in the older, smaller kernels? My general rule is to use a kernel that is approximately 6 months to a year newer than the hardware it's running on. We shouldn't try to make a single kernel to run on all hardware. We have lots of them, one for each specific time period. This also applies to the distros. The older ones are still available for your old hardware.

FTA: Nowadays, many kernel developers are employed by IT companies, such as hardware manufacturers, which can cause problems as they can mainly be motivated by self-interest.

Am I supposed to be surprised by this? Even the most altruistic of us are generally motivated by self interest. We all want some kind of return for our efforts....even if it's a simple "Thank you".

First of all, I am not a user of *BSD, although I do appreciate their goals. I am a Debian user and have been one for quite some time now.

One fact to appreciate about Debian is that it is loosing its ties to the Linux kernel and becoming more and more general, now including even BSD efforts (like the kfreebsd5 port).

So, even though I am a Debian user, I have this secret appreciation for all the work that the BSD people have done and continue to do and I am downloading the OpenBSD release from the torrent site listed in the parent post (that is http://openbsd.somedomain.net/).

We all know that these smaller projects don't have big companies supporting them financially and one thing that other people could do to help visibility (and, in the long term, more users, and, perhaps, even commercial support) is to promote OpenBSD.

This starts with being kind on their servers and helping with the serving of the release for others, keeping your torrent clients open and serving others. Please, do help others "free" their machines with Free Software.

I'm doing my small share helping others to "get their foot wet" with the support for the torrent.

Regards, Rogério Brito.

GNU/Linux distributions are based on the Linux kernel. BSD distributions are based on the BSD kernel. For completeness, GNU/Hurd distributions are based on the GNU Hurd kernel.

first of all, the right to modify software is utterly useless to most people, because they don't have the skills.

as another poster already mentioned, if you mandate that software be free, you are sacrificing the freedom of one group of people "developers" for the freedom of another "users."

use OS, (and before you jump at me for using the wrong term, I'd like to point out that they're exactly the same kind of software - free software is open source, and OSS is by definition free

don't tell a professional publisher to use GIMP instead of photoshop when he's told you a thousand times that having the source code does nothing for him, and he needs some functionality that photoshop has and GIMP doesn't.

right now I'm advocating linux because I believe even to someone who can't program at all, it's a great option for an OS, and also because I do want more people using it, so that we can hopefully break the monopoly, and be closer to that ideal free market I mentioned.

Export that info somewhere, once the the cpu scheduler know what features the CPU has it can start to try to take decisions optimized for that cpu. 2.6.17 will feature a new "scheduler domain" which optimizes scheduling decisions for multi-core CPUs, for example.

Of course you could choose not to export that info and let the CPU do it transparently, but does that have any sense at all? Now that cores are becoming so important you may end having more than one CPU with different number of cores each one, and the OS wants to know that.

The Linux kernel 2.2 is still be actively maintained

Not just DSL, but it should be more of a 'roll your own' thing for a machine like this. The Linux kernel 2.2 is still be actively maintained, and would be well-suited to lower end hardware like this, especially customized to support only the included hardware. A "sparse" window manager and light-weight applications are key too.
It should be that difficult, but it will take some work.

Wait...
Ive got it!
Here is the message in question (before we burn all of the cache engines available):
List: linux-kernel
Subject: Re: Moving to BK
From: Linus Torvalds
Date: 2006-04-01 4:30:40
Message-ID: Pine.LNX.4.64.0603312030060.27203 () g5 ! osdl ! org
[Download message RAW]

On Fri, 31 Mar 2006, David S. Miller wrote:
>
> April 1st is upon us again.

I really like the new slashdot look. "OMG!!! Ponies!!!"

I hope they keep it after Apr 1st.

                Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-------------
And a reply:
-------------
List: git
Subject: Re: Moving to BK
From: "Randy.Dunlap"
Date: 2006-04-01 6:42:28
Message-ID: 20060331224228.aece94a8.rdunlap () xenotime ! net
[Download message RAW]

On Fri, 31 Mar 2006 20:30:40 -0800 (PST) Linus Torvalds wrote:

>
>
> On Fri, 31 Mar 2006, David S. Miller wrote:
> >
> > April 1st is upon us again.
>
> I really like the new slashdot look. "OMG!!! Ponies!!!"

Goes with the sandals and pony tails.

> I hope they keep it after Apr 1st.

---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at http://vger.kernel.org/majordomo-info.html

Now, everybody hit "Refresh" a couple of times, and lets burn slashdot to the ground!
MUAHAHAHAHAR*cough*cough*HARHAR!

Wait...
Ive got it!
Here is the message in question (before we burn all of the cache engines available):
List: linux-kernel
Subject: Re: Moving to BK
From: Linus Torvalds
Date: 2006-04-01 4:30:40
Message-ID: Pine.LNX.4.64.0603312030060.27203 () g5 ! osdl ! org
[Download message RAW]

On Fri, 31 Mar 2006, David S. Miller wrote:
>
> April 1st is upon us again.

I really like the new slashdot look. "OMG!!! Ponies!!!"

I hope they keep it after Apr 1st.

                Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-------------
And a reply:
-------------
List: git
Subject: Re: Moving to BK
From: "Randy.Dunlap"
Date: 2006-04-01 6:42:28
Message-ID: 20060331224228.aece94a8.rdunlap () xenotime ! net
[Download message RAW]

On Fri, 31 Mar 2006 20:30:40 -0800 (PST) Linus Torvalds wrote:

>
>
> On Fri, 31 Mar 2006, David S. Miller wrote:
> >
> > April 1st is upon us again.
>
> I really like the new slashdot look. "OMG!!! Ponies!!!"

Goes with the sandals and pony tails.

> I hope they keep it after Apr 1st.

---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at http://vger.kernel.org/majordomo-info.html

Now, everybody hit "Refresh" a couple of times, and lets burn slashdot to the ground!
MUAHAHAHAHAR*cough*cough*HARHAR!

Linux at least *does* have support for a number of TPM chips (these reside in drivers/char/tpm . You don't have to enable the relevant drivers, of course, but chances are your mainstream distribution has done so.

Whether that actually *means* anything is another matter entirely, of course, and as long as you stick to free software, you shouldn't have to worry about anything really (one should hope). But it's not true that Linux doesn't support these things.

To: Steve Ballmer
RE: Possible Patent Infringement Linux Kernel Source

Dear Mr. Ballmer,

http://www.kernel.org/

Have at it!

Cheers,
Linus

And that's the ACPI thing, you've a sysfs interface for other sensors.

I don't what he means by "fully enabled randomised memory allocation", but....

http://kernel.org/git/?p=linux/kernel/git/torvalds /old-2.6-bkcvs.git;a=commit;h=6a638354be1afb0a1345 58869e05ddc414707205
http://kernel.org/git/?p=linux/kernel/git/torvalds /old-2.6-bkcvs.git;a=commit;h=f1a6b09deaee24b90b1f ab42f93ce1b90f0d319b
http://kernel.org/git/?p=linux/kernel/git/torvalds /old-2.6-bkcvs.git;a=commit;h=6562d1975c95c8d6817e 373c54f256013d062c5c
http://kernel.org/git/?p=linux/kernel/git/torvalds /old-2.6-bkcvs.git;a=commit;h=ad4f9c53a04ce077ae2d de82029bb20a6db705ab
http://kernel.org/git/?p=linux/kernel/git/torvalds /old-2.6-bkcvs.git;a=commit;h=c0e5a50b1f28e83b1563 453f90f6f0866f3a9a90
http://kernel.org/git/?p=linux/kernel/git/torvalds /old-2.6-bkcvs.git;a=commit;h=42a172a814759a29020e 5d1ee580bf4eb86afed2
http://kernel.org/git/?p=linux/kernel/git/torvalds /old-2.6-bkcvs.git;a=commit;h=6833da342273d41d0593 33e7b6ae81f18dbe6dde
http://kernel.org/git/?p=linux/kernel/git/torvalds /old-2.6-bkcvs.git;a=commit;h=9bdac354e0bea82ce76e bdf51d6bbd3993782f78

I don't what he means by "fully enabled randomised memory allocation", but....

http://kernel.org/git/?p=linux/kernel/git/torvalds /old-2.6-bkcvs.git;a=commit;h=6a638354be1afb0a1345 58869e05ddc414707205
http://kernel.org/git/?p=linux/kernel/git/torvalds /old-2.6-bkcvs.git;a=commit;h=f1a6b09deaee24b90b1f ab42f93ce1b90f0d319b
http://kernel.org/git/?p=linux/kernel/git/torvalds /old-2.6-bkcvs.git;a=commit;h=6562d1975c95c8d6817e 373c54f256013d062c5c
http://kernel.org/git/?p=linux/kernel/git/torvalds /old-2.6-bkcvs.git;a=commit;h=ad4f9c53a04ce077ae2d de82029bb20a6db705ab
http://kernel.org/git/?p=linux/kernel/git/torvalds /old-2.6-bkcvs.git;a=commit;h=c0e5a50b1f28e83b1563 453f90f6f0866f3a9a90
http://kernel.org/git/?p=linux/kernel/git/torvalds /old-2.6-bkcvs.git;a=commit;h=42a172a814759a29020e 5d1ee580bf4eb86afed2
http://kernel.org/git/?p=linux/kernel/git/torvalds /old-2.6-bkcvs.git;a=commit;h=6833da342273d41d0593 33e7b6ae81f18dbe6dde
http://kernel.org/git/?p=linux/kernel/git/torvalds /old-2.6-bkcvs.git;a=commit;h=9bdac354e0bea82ce76e bdf51d6bbd3993782f78

I don't what he means by "fully enabled randomised memory allocation", but....

http://kernel.org/git/?p=linux/kernel/git/torvalds /old-2.6-bkcvs.git;a=commit;h=6a638354be1afb0a1345 58869e05ddc414707205
http://kernel.org/git/?p=linux/kernel/git/torvalds /old-2.6-bkcvs.git;a=commit;h=f1a6b09deaee24b90b1f ab42f93ce1b90f0d319b
http://kernel.org/git/?p=linux/kernel/git/torvalds /old-2.6-bkcvs.git;a=commit;h=6562d1975c95c8d6817e 373c54f256013d062c5c
http://kernel.org/git/?p=linux/kernel/git/torvalds /old-2.6-bkcvs.git;a=commit;h=ad4f9c53a04ce077ae2d de82029bb20a6db705ab
http://kernel.org/git/?p=linux/kernel/git/torvalds /old-2.6-bkcvs.git;a=commit;h=c0e5a50b1f28e83b1563 453f90f6f0866f3a9a90
http://kernel.org/git/?p=linux/kernel/git/torvalds /old-2.6-bkcvs.git;a=commit;h=42a172a814759a29020e 5d1ee580bf4eb86afed2
http://kernel.org/git/?p=linux/kernel/git/torvalds /old-2.6-bkcvs.git;a=commit;h=6833da342273d41d0593 33e7b6ae81f18dbe6dde
http://kernel.org/git/?p=linux/kernel/git/torvalds /old-2.6-bkcvs.git;a=commit;h=9bdac354e0bea82ce76e bdf51d6bbd3993782f78