Slashdot Mirror

Being a LKML lurker, here are a few of the new features.

• In-kernel Module Loader and Unified parameter support [kernel.org]
• Nanosecond Time Patch [iu.edu]
• Fbdev Rewrite [iu.edu]
• Linux Trace Trollkit (LTT) [iu.edu]
• statfs64 [theaimsgroup.com]
• POSIX Timer API [theaimsgroup.com]
• Shared Pagetable support [theaimsgroup.com]
• Hotplug CPU Removal Support and Kernel Probes (no link provided)

I can't understand why mailing lists restrict their archives to members only. This is one of the most pointless, irritating policies around. This prevents me from quickly searching a list to find out if someone has already asked my question, without subscribing!

On high traffic lists, this is an insane situation. Even on low traffic lists, it's time consuming and counter to the spirit of co-operation and openness that I expect in the system administration community. Moreover, it thwarts a newbies ability to dig up information without having unravel yet another esoteric oddity of computing. (In this case, it's particularly ironic because the Linux complaints list will have huge volume!)

Anyone maintaining a list, wake up and turn this "feature" OFF ! Open the archives, and help build the public knowledge base. Last I checked RedHat's rpm-list was members only -- it's presumably one of the first places a new user would check for help!

For those are stuck on this problem, take a look at the Mail Archive and the Mailing list ARChives for plenty of list archives.

A Linux complaint?

How about RedHat's installer. They keep ramping up the version number, without doing anything to improve the installer! Anaconda is still garbarge. The resolve dependancies interface needs an option to turn off individual packages that have failed dependancies! Why are the options constrained to "install dependancies to satisfy these packages" or "do not install these packages with failed deps"? If you go through individual package selection and miss something, this is a major pain in the A**! You have to go back, and find the package in the package list!

Also, print the group and category information on the failed deps screen, so it's easy to go back and quickly find the package and turn it off. As it stands, you have a package with failed deps, and have to hunt through the entire list for it! Go on, try to teach all this to a new user. Guess what? In the first five minutes, they've said "Forget it. This is why Linux sucks."

Another one? How about checking the hardware before offering package selection? How many times have I sat for 30 minutes going through package selection, only to have the installer crash when trying to write the new partition table! I have to go through the whole process again! If using an ftp install (or with an network available), why not offer to allow me to upload the package list to another box before bailing out... then I could just download it next time!

What about graphical install for ftp? I install from a local ftp mirror, downloading an X server and libraries over my LAN is trivial, but I'm still stuck with the text install on RedHat 9!

Given that the installer is the first point of contact for most users (especially new users), why not fix it up? Get some UI people working on it, and for crying out loud, stop driving up the release number until you do something decent with the installer.

(And one final rant, why doesn't this Slashdot script comment submit script check URLs for me? Don't we want computers eliminating these mundane tasks? Otherwise, what purpose are they serving?)

Was funding OpenBSD and OpenSSL, for a little while until they changed their minds

I'm sure I'm not the only one to notice the changelogs have been missing from kernel.org's home page over the last few releases of 2.6.0-test. In case anyone else is interested:

http://marc.theaimsgroup.com/?l=linux-kernel&m=105 932590109238&w=2

Being a LKML lurker, here are a few of the new features.

• In-kernel Module Loader and Unified parameter support
• Nanosecond Time Patch
• Fbdev Rewrite
• Linux Trace Trollkit (LTT)
• statfs64
• POSIX Timer API
• Shared Pagetable support
• Hotplug CPU Removal Support and Kernel Probes (no link provided)

Being a LKML lurker, here are a few of the new features.

• In-kernel Module Loader and Unified parameter support
• Nanosecond Time Patch
• Fbdev Rewrite
• Linux Trace Trollkit (LTT)
• statfs64
• POSIX Timer API
• Shared Pagetable support
• Hotplug CPU Removal Support and Kernel Probes (no link provided)

Being a LKML lurker, here are a few of the new features.

• In-kernel Module Loader and Unified parameter support
• Nanosecond Time Patch
• Fbdev Rewrite
• Linux Trace Trollkit (LTT)
• statfs64
• POSIX Timer API
• Shared Pagetable support
• Hotplug CPU Removal Support and Kernel Probes (no link provided)

http://marc.theaimsgroup.com/?l=linux-kernel&m=105 932590109238&w=2

And you're fired.

Since the promising 2.6 is alredy in a test phase, I would wait a couple of week to avoid the infamous module-related issues to upgrade a 2.4 kernel.
Is it possible to have 2.6.x (or even 2.5.75) as an option for the installation? Of course I woluld like it.

They don't need anymore. The problem is lack of time and ...

Also, NTFS is a very complex filing system, with many different versions. You don't want to get that wrong.

Very true.

Resizing was a more important goal, and that has been working for many months now.

Agree and based on the ntfsresize FAQ, actually it's just for one year.

As far as i understand this.

I don't know why your questioning who was first, but hyperthreading has been in 2.4.x since at least Linux 2.4.17-pre5 on 2001-12-06. Release kernels later than this clearly had it. (This obviously includes 2.4!) Though work may have begun in early pre-2.4.14 or "SMT P4" is what Linus called it. So this means when he forked 2.5, it already had it, and this supports why I couldn't find any mention of hyperthreading as a major addition by someone who has kept a record of 2.5.x release additions.

I don't know why your questioning who was first, but hyperthreading has been in 2.4.x since at least Linux 2.4.17-pre5 on 2001-12-06. Release kernels later than this clearly had it. (This obviously includes 2.4!) Though work may have begun in early pre-2.4.14 or "SMT P4" is what Linus called it. So this means when he forked 2.5, it already had it, and this supports why I couldn't find any mention of hyperthreading as a major addition by someone who has kept a record of 2.5.x release additions.

I don't know why your questioning who was first, but hyperthreading has been in 2.4.x since at least Linux 2.4.17-pre5 on 2001-12-06. Release kernels later than this clearly had it. (This obviously includes 2.4!) Though work may have begun in early pre-2.4.14 or "SMT P4" is what Linus called it. So this means when he forked 2.5, it already had it, and this supports why I couldn't find any mention of hyperthreading as a major addition by someone who has kept a record of 2.5.x release additions.

Last time I checked there were remote DoS attacks and local root attacks present in 2.5.7x

Re: Linux v2.6.0-test1

The whole thread is here Linux v2.6.0-test1

Last time I checked there were remote DoS attacks and local root attacks present in 2.5.7x

Re: Linux v2.6.0-test1

The whole thread is here Linux v2.6.0-test1

I want the patch referenced at number 30 here. http://marc.theaimsgroup.com/?l=linux-kernel&r=1&b =200307&w=2

Gosh. The plans listed at the linked discussion site are pretty unclear. I mean literally unclear; the site uses dark-grey text over a black background ;-)

.. is two doors down on the left.

php dev mailing list (php is bsd based)

due to the "virality" of the GPL they exclude the mysql library from php.

The real free license is BSD based , but there other people can walk away with your work.

According to guy who reported Linksys possibly not providing source code, his contact within Linksys finally responded and said the lack of source with the WRT54G was unintential. His contact also said that previously they shipped their products with source code on a CD. I found this on the lkml shortly after the slashdot article.

Have you had any issues with the fact that Namesys is a Russian company? I think we all remember the recent story about DARPA pulling their funding of OpenBSD. Do you worry about this happening to Namesys?

Alan Robertson, who maintains the heartbeat package and works for IBM, recently posted to the ha-linux list on this subject.

Alan does not accept patches to the heartbeat code that were developed on company time unless he receives a disclaimer from somebody at the company.

This is obviously spoofable, but it's probably a good way to legally protect the code -- Alan can honestly say he received it in good faith, which keeps IBM's lawyers' from breathing down his neck. It's kind of weird for me, though, I have to send a disclaimer giving myself permission to send in a patch....

So, to answer your question: explain to your CEO why helping the OSS community helps you to help your company, and get her/him to sign off on a policy that allows you to do so. Ask for legal authority to be delegated to yourself (or your boss) to license or assign corporate intellectual property to open-source projects. Then have HR propagate the policy to your co-workers.

List: linux-kernel
Subject: Route cache performance under stress
From: Florian Weimer <fw () deneb ! enyo ! de>
Date: 2003-04-05 16:37:43
Please read the following paper:

<http://www.cs.rice.edu/~scrosby/tr/HashAttack.pdf >

Then look at the 2.4 route cache implementation.

Short summary: It is possible to freeze machines with 1 GB of RAM and more with a stream of 400 packets per second with carefully chosen source addresses. Not good.

This is a gcc bug IMHO:

I'm not sure if this has been addressed in 2.5 yet, so apologies if it has.

Many thanks to Andrew for all his work, especially with ext2/ext3 (but much more I know). I'd like him to consider making sure that direct IO is properly working in 2.5 (and 2.4 for that matter). In particular ;

a) Support in ext3.

He posted a patch to the kernel list that added this, which I tested and it seems to work. It would be good if this is in the 2.4 and 2.6 kernel.

http://www.geocrawler.com/mail/msg.php3?msg_id=932 9947&list=7493

b) Correct functionality for non-4K multiple reads in ext2/ext3

i.e. less than 4K read as a remainder at the end of file. Again, Andrew posted a patch for this on the kernel list, and it seems to work. This is relevant for a) as well it seems.

http://marc.theaimsgroup.com/?l=linux-kernel&m=104 515769523283&w=2

Apart from that, all the stuff we need to make sure we can read and write as fast as possible to disk or RAID would be great. I need at least 300 MB/sec (PCI-X, U320 SCSI bus x2) but the more the better :-)

Keep up the great work!

While I'm personally sympathetic to Theo de Raadt, his accusations against Jonathan Smith are a vicious slander and a lie. The reporters simply haven't done their homework -- they haven't even bothered to look at the contracting terms. Let's try looking at the facts.

We know from a note sent by Theo that DARPA made a decision to cancel this project. Theo himself confirms that the source of the funding cut was DARPA, not Smith. So that you can understand the issues, let me explain briefly how these contracts work.

The cancelled contract was originally "let" by DARPA. Jonathan Smith is the "principal investigator" (PI) for this project. A principal investigator basically has two responsibilities: (1) manage the activities required by the contract (i.e. get the job done), and (2) provide periodic reporting to the funding agency (in this case DARPA).

One of the rules with any U.S. government contract is that the government can stop work and cancel any remaining funding at any time. This is clearly stated in the applicable FARS and DFARS contracting regulations, which are a part of every contract signed with the U.S. Government, including the Department of Defense. The POSSE contract is just like any other contract: DARPA has the right to stop work on it at any time. DARPA is not required to give a reason for stopping work. Usually such actions are the results of budget changes, but cancellations can and do occur for other reasons. Theo and his team were subcontractors on this project. They knew that these were the terms when they were hired to do the job. They have reason to be unhappy, but no basis for wild accusations.

A principal investigator has no control over cancellation of funding. Theo knew the risk that his contract could be cancelled. He chose to speak out about something important to him, and he is now dealing with the consequences.

Theo is clearly he is frustrated, but there are two important points to remember:

1. Neither Jonathan Smith nor the University of Pennsylvania have broken their contract with Theo, and
2. Jonathan Smith has absolutely no control over DARPA's decision to terminate the POSSE project.

This is not a free speech issue. It is a consequences of free speech issue. Theo spoke negatively about his employer (DARPA). DARPA cut him off. Jonathan Smith is not curtailing Theo's free speech -- in fact, Smith and Penn had no decision making power in this situation at all! DARPA is not curtailing Theo's free speech -- Theo isn't in jail or under any threat of legal consequences for his words.

Free speech doesn't mean what Theo and some irresponsible reporters might like it to mean. Free speech does not mean "speech without consequences". Free speech means you can say what you wish without being prosecuted as long as you don't actively harm someone else (e.g. by libel and slander, for example the statements that Theo has made about Smith that Theo clearly knows are false). You have the right to speak, but the people who associate with you, either personally or professionally, have the right to respond to your speech. I do not know why DARPA cancelled this contract. DARPA is not required to give a reason. I do know that their actions are completely acceptable within the terms of the contract.

It is a little puzzling to me that Theo seems to feel that it is okay to slander someone who has generously assisted the OpenBSD team in getting a large amount of funding (remember: the contract was almost complete).

It is even more puzzling to me that various newspaper editors feel that such one-sided and selective reporting of the facts constitutes responsible journalism.

But the most puzzling thing to me is why so many people appear to be lining up on the side of the slanderer, and forgetting that Jonathan Smith's role in this who

look at the top 2 items of this link

propolice is the same gcc stack protection that trusted debian uses, written by the same author whose email address is etoh@openbsd.org.

w^x is similar in concept to pax, but it is faster and doesn't break applications.

this has produced a hilarious 'debate' on the openbsd misc mailing list, as evidenced in threads like this and this

look at the top 2 items of this link

propolice is the same gcc stack protection that trusted debian uses, written by the same author whose email address is etoh@openbsd.org.

w^x is similar in concept to pax, but it is faster and doesn't break applications.

this has produced a hilarious 'debate' on the openbsd misc mailing list, as evidenced in threads like this and this

Don't all these "overflow checkers" kill the speed of C(++) apps?

But yes, 128k is too small for a regular Linux kernel, but other UNIX-like systems do work in space that small. The question arises still whether Palm's quick-time-to-market and corporate success is worth the years and years of backwards compatibility woes for developers. I don't think so: Palm has to take the blame for what they did.

Backwards compatibility is the only reason that Palm has the market share they do. Same thing with IA32 processors and all flavors of Windows. Windows kicked the Mac's ass because it could run DOS apps on old-school PC hardware. No one cares about that now, but Windows couldn't have succeeded as well as it did if it weren't compatible when it counted.

See Linus' Comments on this recently on the LKML.

> Do you *want* ID3-tagged MP3's or would you prefer to leave them as-is?

I do not want them.

There are still some players that dislike them.

The song is free. If it was not free, it would not be on our CD.

I pay money to make sure it is free.

taken from misc@

http://marc.theaimsgroup.com/?l=gentoo-user&r=1&w= 2

Check the above link for some of the gentoo-user mailing list archives - discussion started a few minutes after the newsletter went out. Common consensus is that it's April Fools - killing the package management system that makes Gentoo unique and requiring X is just too big a step to make without any discussion on the gentoo-dev list. Kurt did a really good job on this one if Slashdot bit!

Well, he wants everyone to write everything in perl, except for the fact that he brings up, that perl is just as insecure itself.

So what will everything be written in??? Every part of the OS in java? Nevermind the performance, and the lack of a good, Open Source JVM/JDE.

If you want secure programs, start putting strong-typing, and other security measures into GCC. You can't have a string overflow if GCC checks everywhere data is input, and makes sure the input can be no longer than the string...

A bit different, but it deserves to be mentioned that OpenBSD 3.3 (which will be released VERY soon-already tagged), has numerous protections as described here, by Theo. Yes, that's right... OpenBSD has been doing the job before Lasser even lifted a finger to complain.

I downloaded RC3, the md5sums are the same. Plus there's this wonderful message on the Cooker mailing list: http://marc.theaimsgroup.com/?l=mandrake-cooker&m= 104861019216735&w=2

Hmm, interesting... my guess is that's just some overzealous copy and paste from the previous security update.

Now, as for which OpenSSL bug this is for... my /usr/lib/libssl.* and /usr/lib/libcrypto.* are still dated 03/03. Here's a list of the files included in the update:

./usr/bin/make_printerdef Tue Mar 18 18:40:38 2003
./usr/bin/make_smbcodepage Tue Mar 18 18:40:40 2003
./usr/bin/make_unicodemap Tue Mar 18 18:40:42 2003
./usr/bin/nmblookup Tue Mar 18 18:40:43 2003
./usr/bin/rpcclient Tue Mar 18 18:40:41 2003
./usr/bin/smbcacls Tue Mar 18 18:40:43 2003
./usr/bin/smbclient Tue Mar 18 18:40:35 2003
./usr/bin/smbcontrol Tue Mar 18 18:40:38 2003
./usr/bin/smbpasswd Tue Mar 18 18:40:39 2003
./usr/bin/smbspool Tue Mar 18 18:40:36 2003
./usr/bin/smbstatus Tue Mar 18 18:40:37 2003
./usr/bin/testparm Tue Mar 18 18:40:36 2003
./usr/bin/testprns Tue Mar 18 18:40:37 2003
./usr/libexec/httpd/libssl.so Tue Mar 18 11:33:25 2003
./usr/sbin/nmbd Tue Mar 18 18:40:34 2003
./usr/sbin/smbd Tue Mar 18 18:40:33 2003
./usr/sbin/swat Tue Mar 18 18:40:35 2003

So it looks like OpenSSL itself wasn't updated--only mod_ssl for Apache. It's now at version 2.8.13, with fixes for the RSA timing attack. Seems like they should've instead upgraded OpenSSL itself to the version that always turns on RSA blinding.

i'd like to see a script to automate an install of a suidless, fully systraced OpenBSD system, a la Dug Song style, as in this post.

This one seems to make a cleaner text patch than the last one I linked to.

- Sam (compiling the kernel as we speak)

Different mirror

I guess these are the same.. haven't read the origial ./ed site, but this is from lklm and guess they're the same...

Honest, I'm not Karma-whoring, it just ticks me off.

link

Except when they steal code off each other, possibly breaking each others license. Even Microsoft steals BSD code.

Theo has already spoken.

But you _can't_ claim it as your own.

From http://marc.theaimsgroup.com/?l=openbsd-misc&m=104 570206117686&w=4
You are STRONGLY urged to use ssh instead of telnet, rlogin, or rsh! ssh is included in all MicroBSD systems. The implementation is OpenSSH, which we are the developers of. (emphasis mine)

So you see, they didn't give credit where credit is due.

No, I never assume the public has a brain. Your comments are completely correct. However I was addressing a vulnerability in SSL and HTTPS in particular, rather than a vulnerability of the user sitting in front of their computer.

I've written many times about how blindly clicking "YES" is a great way to defeat your security. SSL is not a magic bullet, SSH MITM Attack "Challenge" writeup, and a good section in HLEv2 which is unfortunately not availble online. I'm sure you can find a few of my rants in the Stunnel mailing list archives as well.

Do I trust that users will possess a brain and use it? Hell no. But that wasn't the original question.

I have yet to see a lengthy FSCK or a corruption.

The article in question was complete FUD. The NSA are still working on SE Linux along with open source developers. See this post from Russell Coker (one of the lead SE Linux developers outside of NSA), which mentions the official position of the NSA.

The article in question was complete FUD. The NSA are still working on SE Linux along with open source developers. See this post from Russell Coker (one of the lead SE Linux developers outside of NSA), which mentions the official position of the NSA.

It was originally posted on the Linux Kernel Mailing List (lkml) by Russel King, here.

Oh oh. i386 and powerpc, two very common architecures, have ominous notes. Now you guys know why I want fast sparc64 machines to run.

Note 1)

The i386 is not capable of doing per-page execute permission. At most it is only capable of drawing a line through the address space, by limiting the code segment length (using the code segment register). So we can say, "from 0 to this point is executable" and "from that point on to the end of userland is not executable".

This sucks, but it is the best we can currently do. We can protect the stack, and not much else.

There are a lot of other i386 details that are interesting to some of us, but you don't want to know them. Anyways we are investigating some possible changes that might help us protect more.

By the way, hammer will not have this problem...

Note 2)

The powerpc has a slightly more flexible mechanism than the i386, but let me just say it still totally sucks. We can protect the stack, and not much else.

They have regularly provided helpful posts to linux-kernel listing huge number of bugs, see their most recent message listing potential buffer overruns.

This would be an extremely valuable tool for any Software project, proably even more useful than e.g. valgrind.