Slashdot Mirror

Text of Linus' short message can be found at http://marc.theaimsgroup.com/?l=linux-kernel&m=114 386596009004

Hey Taco, fix yourself! ;)

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

We have received 350 financial donations (Centered around $20) in the last month. I did not know there were so few OpenSSH users in the world.

There you have it. What a better place the world is for OpenSSH. I remember years ago how using telnet was the norm, and what a step up using SSH was. Now, greedy selfish users/corporate giants could care less.

Oh, the humanity!!

I would like to educate people of something which many are not aware of -- how X works on a modern machine.

Some of our architectures use a tricky and horrid thing to allow X to run. This is due to modern PC video card architecture containing a large quantity of PURE EVIL. To get around this evil the X developers have done some rather expedient things, such as directly accessing the cards via IO registers, directly from userland. It is hard to see how they could have done other -- that is how much evil the cards contain. Most operating systems make accessing these cards trivially easy for X to do this, but OpenBSD creates a small security barrier through the use of an "aperture driver", called xf86(4) (...)

Who is this Jeffrey Zeldman?

And, as Rasmus Ledorf said, ". Lots of people have been using similar things long before it became "AJAX"."

http://marc.theaimsgroup.com/?t=112068507200001&r= 1&w=2

Hopefully the patch for making this a mount option will make its way into 2.6.16 along with another couple of patches that we (FastMail.FM) add for other reiser issues. It's still the best filesystem by far for large Cyrus installations though.

"Swap is now encrypted by default in OpenBSD 3.8:

http://marc.theaimsgroup.com/?l=openbsd-cvs&m=1111 85331505174&w=2 "

Sweet, thanks, I missed that one =D

I have no idea why these mechanisms are not enabled by default on these OSes (not even on OpenBSD!) as the overhead really isn't that noticble...

Swap is now encrypted by default in OpenBSD 3.8: http://marc.theaimsgroup.com/?l=openbsd-cvs&m=1111 85331505174&w=2

--snip--
Despite recent speculation concerning patents, we remain confident that we had the necessary rights to release SELinux in the manner and under the conditions in which we did and that SELinux may be used, copied, distributed, and modified in accordance with the terms and conditions of the GPL.
--
Peter Loscocco
SELinux Project Leader
National Security Agency
--snip--

I'm this guy: http://marc.theaimsgroup.com/?w=2&r=1&s=derekm+hac kunix.org&q=a

And these are my vitals:

Derek P. Moore
PO Box 10051
Kansas City, MO 64171-0051
SSN 323-80-9292

Uh oh, someone is really gonna fuck me over now... I'm shakin' in muh boots.

As a developer you should care about this release. The malloc/free implimentation has been changed to release memory immediately to the OS, causing any read-after-free bugs to immediately throw a SIGSEGV.

See theo's post to misc@.

One of the most important things new in this release is the mmap(2) based malloc(3) implementation. I can't believe the submitter didn't mention it. It has huge implications, in terms of added security and increased code quality overall. Already, important off-by-one bugs have been found and fixed in X.org which had been sitting there un-noticed for years. These bugs could cause the X server to crash on many systems, but OpenBSD exposed them reproducibly so they could be fixed.

Read more about it in this Security Focus article titled Security-related innovation in Unix and in Theo de Raadt's post to misc@.

NTFS does support hardlinks and, as the developers of the NTFS driver for Linux recently discovered (see details in this thread), it also supports symlinks, provided Microsoft Services For Unix are installed.

The important part of all this, is, I think, that open source tools ranging from the linux fs drivers (ntfs and cifs/smb) to the cygwin stuff should get updated and start managing the thing the way MS does it (on MS filesystems, of course).

Fiction. There are *many* resources out there...

And don't forget the actual books that are available too...

• Absolue OpenBSD
• Building Firewalls with OpenBSD and pf
• FreeBSD & OpenBSD Security
• Secure Architectures with OpenBSD

1) OpenDOS was licensed using something entirely incompatible with the GPL.

2) Yes, he (Udo Kuhnt) modified the source code, but was bound by the Caldera license. See also the opinion of Pat Villani, the original FreeDOS kernel developer
here
It is not possible to relicense something GPL-incompatible as GPL without permission of all copyright holders.

3) Yes

4) Yes, and they are able to do so (snatching) because their license allows them to do so. "stolen", as used on the freedos site is not the right word to use IMHO, because Udo Kuhnt could read in the OpenDOS license that this was possible.

5) This is about two utilities only (only these and not the kernel are GPL), and well it looks like DRDOS Inc has done something about it here: "Portions are licensed under GPL (SYS v2.6 and FDXXMS v.92) or other licenses."

There is a linux equivalent in development, see http://marc.theaimsgroup.com/?l=linux-netdev&m=112 872348122315&w=2 Quote: Here at Devicescape we've written an IEEE 802.11 stack for Linux, and are considering some design changes as part of proper kernel integration and open source release. We have many man years worth of work in this codebase, and it is running multiple commercial products, as well as being part of the Wi-Fi testbed. ... These new ethernet interfaces are virtual (have no tx queues), and simply encapsulate the frame with an 802.11 header, and transmit it on the real hardware interface. In merging with net/ieee80211 these interfaces could also work with 802.11 frame format, and then they are there simply to multiplex and demultiplex multiple virtual access points, WDS links or client connections.

http://marc.theaimsgroup.com/?l=php-general&m=1121 98633625636&w=2 This explains it very simply and easily. Basically you have the backend deliver content on-demand, and the frontend is a single HTML page powered by JavaScript which queries the backend for the necessary data. Just like a desktop application.

http://marc.theaimsgroup.com/?l=php-general&m=1121 98633625636&w=2 there you go.

It is not so much the technology as the economic might of the one of the biggest developers of AJAX: Google. They are giving a wall to wall 24x7 demo of AJAX technique and its effectiveness to anyone who pays attention. The fact that middleweight clients that can support a bit of asynchronous update traffic in what , to the user, is the "background", is not so much technically amazing as perceptably practical and a better web experiance. I was looking for better doc on AJAX, having first got the impression it had to be JavaScript [which, frankly, is a crappy tool for designing ambitious software]. This article is a good addition to a topic that doesn't have much presence in the bookstores yet. There are other sources on line. Its not just for XML and its not just a J language either... Ruby will do.

Linux eh? Your completely right Linux is free of DRM http://marc.theaimsgroup.com/?l=linux-kernel&m=105 115686114064&w=2. Linux does (obviously) have more control but less complications? Thats certainly a disputable point.

Linux does have a "comparable" feature (soon to be merged in mainline) called "kprobes", or "systemtap" (systemtap uses kprobes)

You can see a fairly detailed analisis in the 2005 Proceedings, Volume 2, page 57 of the linux symposium

Also some doc from IBM: http://www-128.ibm.com/developerworks/linux/librar y/l-kprobes.html

also there's a "linux trace toolkit". A post about LTT vs dtrace...whatever, too much flamewar for my taste.

This of course, comes with a performance penalty. In Linux, everything is a kernel thread. This gives it a big performance advantage, making it appropriate for servers operating under controlled conditions, as the tests indicate. However, OS X's design choice makes for more secure communication between user-space threads and the kernel, which gives an advantage in the workstation-space, since you can keep a user process from running amok in the kernel.

Except that people who implements M:N-style threading like mac os x believe that it can be fast (reasonabily fast)

Not having achieved it (still) is a "achilles heel" indeed. Apple has to work on that and make their threading implementation performant

There's a very good post from Ingo Molnar explaining why linux chose 1:1 and not M:N, and he points out a possible "users-space threads" issues:

"Plus there are other issues like security - it's perfectly reasonable in the 1:1 model for a certain set of server threads to drop all privileges to do the more dangerous stuff. (while there is no such thing as absolute security and separation in a threaded app, dropping privileges can avoid certain classes of exploits)"

Also, expect desktop apps to start using threads heavily (in the future) to use multi-core CPUs

There's also a discussion about this on the linux-kernel mailing list (lkml) currently - certainly worth reading:

http://marc.theaimsgroup.com/?t=112541793700006&r= 1&w=2

You shouldn't buy hardware from a scumbag company selling empty promises such as Genesi.

Fuck off :)

Linux has held all the IPv4 and IPv6 records for about the past year.

You might also find this interesting.

In light of some *real* information and facts, I contend that Linux has the best TCP/IP stack.

I wish them luck, but this has to give pause to anyone who wants to place a heavy bet on the continued availability of OpenBSD/Alpha -- if it can get wiped out because they can't get a specific piece of legacy hardware to fit Theo's rack!

You mean "printer on fire". And that one, funny as it may sound, actually was a valid and true error message, back in the dark ages - see this lkml post for an explanation. :)

And this is quite possibly the funniest (and oddly relevant to this discussion) email on the subject.

• 3.3 - Sun refuses to release full documentation for the UltraSparc III processor.
• 3.4 - OpenBSD loses funding after no-strings-attached grant turns out to have strings attached limiting freedom of speech
• 3.5 - Cisco attempts to assert patent rights on IETF standards (VRRP)
• 3.6 - "Free" software projects becoming less free
• 3.7 - Open wireless drivers and free firmware (OpenBSD is now the only free BSD. Ironic, no?)

You can raise the clock interrupt frequency to get the latency reasonably low.

Well, not really. 1000 is already putting strain on the system, and 10000 is crazy - and you're still adding .1ms on there in that case.

However, that's the inherent trade-off you have to make. In general, a system cannot switch methods quickly enough for polling to be effective after an interrupt.

Yes it can. There was a large amount of research and development and testing into this when NAPI was implemented. It is definitely a win - ask the 10GbE vendors testing with Linux.

It works in SMP systems, though it would only use a single processor.

OK, well FreeBSD's networking stack is pretty well single threaded, so I guess not.

From what papers I've found with a quick search, it seems NAPI doesn't get much benefit from additional processors anyhow.

Umm, yes it does. You didn't actually look at any papers, did you? Linux routes 1.05Mpps with a single CPU, and 2.1Mpps with dual CPUs. And let this post also shut up all those idiots saying "Linux can barely do 100kpps".

Actually you are way off bat here, if you read misc@ (The OpenBSD mailing list) you'd soon realise otherwise especially when users cannot be bothered to read documentation (http://www.openbsd.org/faq/index.html) or use tools availble to them: http://www.yahoo.com/ http://www.google.com/ http://marc.theaimsgroup.com/

Certainly. The answer, unfortunately of course, is "it depends". It depends on what your own tolerance of false-positives is, and what your current level and nature of spam is (where "you" also includes the users of your system - there's a world of difference between an ISP with tens of thousands of paying customers, a small organisation with a hundred employees, and a personal family/friends server).

My best advice is to carefully examine the policies of the RBLs, and revisit that examination on a regular basis. Look at whether the process by which IPs are added to a list is automatic, or human-moderated. Are they using spamtraps? Do they allow just anybody to submit addresses for listing? Is the listing process openly specified, or a black box? What is the procedure for de-listing an address? Google around for others' experiences using the list. This Declude page is a useful starting point (I have no relation to Declude).

Currently, I see the least collateral damage with the Spamhaus lists. My top recommendation would be the sbl-xbl.spamhaus.org list, a composite list consisting of known spammers plus a pretty good list of compromised/trojanned systems.

On one extreme, SPEWS is hardcore - I would never recommend them to anyone who isn't very well aware of the implications of what they are doing. On the other end of the scale, open relay lists like relays.ordb.org and the like are very benign, but less useful, since there hardly are any more open relays these days. I used to really like Spamcop's lists, but I lost faith in them a couple of years ago when I experienced some inexcusable cock-ups. More recently, Spamcop changed listing policy and started listing systems that were sending "mis-directed bounces", which I personally find misguided (long story, see this discussion for a start). Also be careful about "multi-stage" or "multi-hop" lists. These can often end up listing major ISP servers, simply because one of their clients relayed a spam that way, typically caused by a trojan-type infection.

I've also had trustworthy results with cbl.abuseat.org, and in a typical configuration I often also use relays.ordb.org (open relays) and list.dsbl.org.

P.S. Sorry about the previous premature post - somehow accidentally hitting CR whilst in the subject field submitted it, and then Slashdot seemed to disappear off the Internet, and then it wouldn't let me post, because I'd posted 11 minutes ago, which was less than 2 minutes!

Long Answer: The concern is the misdirected bounce. By default and in accordance with the RFC, qmail bounces messages it accepts then later decides it can't deliver back to the sender. Spammers use false return addresses, so you end up bouncing spam back to innocent third parties. When used with naive spam-filtering techniques, this can be a problem i.e. qmail accepts the message, but a spam filter rejects it, and it is bounced. Here's what SpamCop.net has to say about it:

Qmail: Qmail is one popular mail exchanger which suffers from this problem by default. If you use qmail, please apply a patch: spamcontrol or qmail-ldap.

There is also an experimental patch for qmail which allows you to send bounces, but isolate them on a different IP address (so that spamcop can block them without blocking other mail): Richard Lyons BOUNCEQUEUE patch

PZInternet.com reports chkuser is a very good qmail patch to avoid misdirected bounces - very easy to install too! http://www.interazioni.it/opensource/chkuser/

For users of qmail-toasters, check out the simscan patch

This is indeed old news. An announcement was sent at the time to the mailing lists. A day or so ago, someone's broken email system remailed the message to the lists (check the wicked delay in the Received: headers). How it made to the front page of /. is another question...

http://marc.theaimsgroup.com/?l=patchmanagement&m= 111773947308242&w=2 Eric from Shavlik, produced many counterpoints to this article by eWeek. It is not the final update for Windows 2000 - security updates will be released for it long after this roll-up.

http://marc.theaimsgroup.com/?l=patchmanagement&m= 111773947308242&w=2 Eric from Shavlik, produced many counterpoints to this article by eWeek. It is not the final update for Windows 2000 - security updates will be released for it long after this roll-up.

http://marc.theaimsgroup.com/?l=patchmanagement&m= 111773947308242&w=2 Eric from Shavlik, produced many counterpoints to this article by eWeek. It is not the final update for Windows 2000 - security updates will be released for it long after this roll-up.

Why invest in an all new line using it's own developed Sun hardware based on AMD Opteron chips?

From what i've read, Sun's Opteron line is just rebranded Newisys servers.

This was linked to below by an AC, Arnd Bergmann@IBM, who wrote it. I'm reposting here so it's seen. Best info I've yet seen on how to actually work with the Cell;

On the surface, a typical programmer will represent the SPE as a library backend, so a multithreaded application can simultaneously run computational code on some of the SPEs while doing something else on the CPU. Splitting the code, arranging transfers between CPU and SPE memory as well as parallelizing over multiple SPEs is done by the developer.

Arnd <><

But, now we have to flash-cut our production systems, unless someone knows how to changes things to work under both namespaces...

I don't follow it closely enough to know.

It shows. As does your arrogance. I've been using OpenBSD for 6 years and Linux for 8 years. I have been following OpenBSD very closely.

X? I don't think so. gcc? No.

Such strong statements for someone who does not follow it closely enough.

Xfree forked.

x11 - Houses OpenBSD's adaptation of the XFree86-3 software project. xf4 - Houses OpenBSD's adaptation of the XFree86-4 software project.

gcc is worked on within OpenBSD's source tree and part of their work enabled an mvme88k port.

A few choice quotes from here.

FB: Another license war has started and it seems worse than before. Does OpenBSD really want to fork XFree starting from the last 4.4.0-RC2?
ME: Yes.

And I'm one of the guys who works on gcc and binutils on a continuing basis.

Anil took it one step further and introduced an extension attribute to gcc: bounded, that can tie two function parameters, so that you can say, "Here is the buffer and the corresponding size, try to check that it fits."

With a few small changes to gcc, and with declaring that read is such a function, gcc is now able to detect erroneous code, such as:

ME: ProPolice is a gcc extension developed by Hiroaki Etoh, from IBM, based on older concepts such as StackGuard. ProPolice makes several advances compared to StackGuard:

Hiroaki is also an OpenBSD developer, by the way.

Integrating ProPolice in OpenBSD has been hard work. ProPolice has found tons of bugs in various programs that shipped with the system. It's also been the first real-scale test of ProPolice itself. With a lot of hard work from Hiroaki Etoh and Miod Vallat (and Peter Valchev and Christian Weisgerber...). ProPolice itself modifies gcc a wee little bit. But, like most programs of its size, gcc itself is buggy, partly due to its gigantic design that is not quite sane in places. In a typical release of gcc, you don't see the bugs, because the corresponding code paths are never taken. Add ProPolice, and suddenly you're sending gcc through some dark venues that have seen less attention, and all of a sudden you are fixing actual, genuine bugs in gcc.

Not it is not maintained, it is called packaged. That they might have a few patches of their own isn't at all unusual - even if they are leet security fixes.

They have made major changes to Apache and as evidenced here and here, they forked it and are taking care of their own branch. Much as they have done for years before the Apache license change. Bundling some software up into a package might be what some Linux distros do, but not OpenBSD with Apache.

"Bolt Apache on" isn't very descriptive. That could be applied to the OpenBSD process too.

There is no way it can be applied to OpenBSD. They have made major changes over the years to the Apache they provide.

Sorry, no. OpenBSD does not maintain X, they do not maintain Apache. That is an insulting and slighting to the developers who do maintain those packages.

I was not saying OpenBSD developers maintain THE xfree and Apache code bases. It should have been obvious from my English that I was referring to the xfree and Apache which they release as part of their base OS. Thier changes do make it back to parent projects though from time to time.

Linux distros

It was real life trolling, not online trolling that is linkable. PHK went to BSDCan, and during an openbsd presentation on their wireless card support, started trying to claim they are doing something illegal by using reverse engineered code in their free drivers, and saying they should be happy with binary only freebsd drivers.

Here's a link to Theo forwarding PHKs email about trolling at BSDCan to the openbsd list though:
http://marc.theaimsgroup.com/?l=openbsd-misc&m=111 619770429208&w=2

I was running bridging between multiple Qemu instances (around 5), using tun/tap interfaces on a 2.6.9 kernel. There were some problems and I reported them to the netdev mailing list. It was suggested that I try out the then current 2.6.10-rc, and they disappeared.

Here is the URL for my post to the list :

[2.6.9] Networking crash, slightly exotic setup, bridged tap/tun

Have you reported the problems to the netdev mailing list, or possibly the bridge maintainers ? Here are the bridge details from the MAINTAINERS file in the linux kernel source :

ETHERNET BRIDGE
P: Stephen Hemminger
M: shemminger@osdl.org
L: bridge@osdl.org
W: http://bridge.sourceforge.net/
S: Maintained

and the netdev list

NETWORKING [GENERAL]
P: Networking Team
M: netdev@oss.sgi.com
L: linux-net@vger.kernel.org
S: Maintained

There's a more likely explanation for what you experienced. If the old authoritative servers thought they were still authoritative, they would have continued to answer queries with the old information. Recursive servers that had the NS record cached would go back to the old server until the TTL of the cached NS record was zero. Problem is that in the meantime, each time the recursive server hits the server listed in cached NS record, the server returns the list of old servers as additional information. Thus as long as someone using the recursive DNS server hits something in that zone before the TTL on the NS record expires, the server will never go back to the root for the new NS records.

The solution is to update the zone on the old DNS servers, or remove it completely.

See http://marc.theaimsgroup.com/?t=111057230600004&r= 1&w=4

No, actually 2.0 was biglock based. 2.2 I think may have had a couple of seperate locks for some things, but 2.4 had pretty fine grained locking. The biggest problem with 2.4 was the single lock for the scheduler and single lock for the block layer.

Note, this is a single lock for *just* the scheduler, and *just* for the block layer, not a single global lock.

But FreeBSD 5 and even 6 I think still use their SCHED_4BSD as default, which uses a single runqueue for all CPUs, so don't go trying to call the kettle black here.

FreeBSD 4 has a *single* lock protecting the kernel. It is completely serial. If you really have no idea about Linux and operating systems in general, then I suggest you shut up and stop making a fool of yourself.

Linux 2.4 has pretty damn good scalability for many applications and systems smaller than 16 way. That's better than you can say for FreeBSD 5, which has the most abysmal scalability I've ever seen on similar benchmarks (ie. parallel compiles).

Yeah, it's more like an honest mistake. Given Torvalds's recent level of morality (force other people to use a system they don't want; work with people trying to block development of free SCM systems; try to get your colleague fired; criticise colleagues in public), it's pretty easy to believe he would say something like that. In fact, as The Register pointed out, that's pretty much what he did say, just he said it about his "friend"'s wonderful BitKeeper product and its files.

Did anyone notice Torvald's admission that it was actually himself who got rid of BitKeeper (out of spite?) ( "... got to the point where I decided that I don't want to be in the position of trying to hold two pieces together..." ) and is now trying to blame Tridge.

How would you like it if Microsoft's OS user license forbid you to work on any software development which could compete with their products? The terms are draconian, even more so than the license terms Microsoft usually uses.

It may have been a good tactical solution, to solve the tool problem he had at the moment, but you should never commit that mistake. It can lead you to winning a battle that will result in you losing the war. A Pyrrhic victory. Thankfully the consequences are bad, but not irrecuperable. Similar to the stupid tactics used by planners in WWI which led to massive waste of human life, albeith not costing the war, this ordeal will cost dearly in terms of transitioning costs, not to mention the costs to develop the alternative tools. This will surely delay Linux kernel development by several months.

Linus is still trying to spin this as if it was a good idea, that it increased the rate of development two times because he learned to trust other developers more, so it wasn't all bad. The problem is, this is self-delusion. Those are all social fixes which were problems in his working social model and are totally orthogonal to BK.

He could just as well be using CVS to get his social fix, and given rights to Morton to commit to the tree, plus some other personnel. If the problem was about bickering because of ego stroking, just wipe the kernel tree committers names from the output or the history so no one knows who has rights or who did what.

This is another example of not using tools which already exist for no good reason. If he cannot track his patches, he could have just made a ticket system available to the public.

Many other projects of the same size use these tools (e.g. CVS, Bugzilla) and they work. If he does not like their social model, fine. Use a different one. These tools will still work, just be a bit more clumbsy. But still orders of magnitude less clumbsy than a mailing-list, and handpicking patches from his mail box.

I still have not even seen him make a detailed public request list with what he wants on his model. I am certain someone in the community would work on it, if he wanted to help develop it, all the better. His main problem as a manager seems to be that he does not know how to delegate tasks and always wants to do everything by himself.

In less then two years of work (with very little destabilization of the kernel during that period, by the way), we are now within shouting distance of FreeBSD's and Linux's SMP parallelism.

Very dependant on your definition of shouting distance ;)

I mean, I wouldn't call FreeBSD as anywhere near shouting distance of Linux's SMP scalability after seeing this post showing it is only scaling with about 30% efficiency to 12 CPUs on something as simple (for the kernel) as a parallel gcc make.

I was quite surprised about that. Considering the kernel compile fixation a few IBMers had very early on in 2.5 development (~2.5.5 IIRC), where they got it compiling a linux kernel in about 4 seconds flat on a 32-way POWER4. With most of that time chewed up by Amdahl in the final link stage.

And then Linux has gone on a long way from there, and on *real* workloads, too.

Even _booting_ on a 512-way is no mean feat. SGI had some issues where some shared cachelines (for fairly unimportant statistics, IIRC) in the timer interrupt was literally causing livelocks redering the system unbootable.

But I wish you all the best of luck. I'm very very interested to see what your performance looks like when you remove the big lock.