Slashdot Mirror

The Winner of the splash screen contest has been announced

Read the announcement from the mailing list archives
here or here

Link to the Winning Splash screen image,
"work in progress..." by Bill Luhtala

This guy has demonstrated the ability to be a complete ASS when confronted with criticism about his software. Even if someone did find some remote root exploit in qmail, I'm sure it'd be downplayed, the money not given out, and a lawsuit filed against the submitter.

Just look at shit like this

http://www.mail-archive.com/
http://archives.neohapsis.com/
http://readlist.com/
http://marc.theaimsgroup.com/

Some of the sites have their own search, and some have a nice readable interface. Take your pick. Though I'm sure hundreds of mailing lists aren't indexed anywhere, perhaps thats what gmail is for ;-)

The OpenSSH developers won't support Redhat users, because of their messing around with the distribution tarball and ongoing refusal to discuss the issue in public.

"It took Intel about two weeks to come back and say that they cannot give us freer redistribution rights." [4th paragraph, first line.]

http://marc.theaimsgroup.com/?l=openbsd-misc&m=109 994542424009&w=2

Use of this driver requires that you download Intel firmware which is covered by a very non-free and restrictive license.

I urge you to write to Intel and let them know that you are dissatisfied with their license and that you want the ability to freely distribute their firmware.

Please note that nobody is asking them to open the source of their firmware--they just need to make it so that free operating systems can distribute their firmware without having to force their users to agree to this licensing.

Here's one

FYI, buying from Intel is discouraged

My home firewall is an OpenBSD box that is my access point as well. I use IPSec to setup VPN to secure my wireless network. Only authenticated IPSec traffic is permitted, so all a war driver can do is to DoS my wireless network.

If setting up IPSec is too much work, one can use OpenVPN that has a Windows client as well.

If you just want to prevent unauthorized usage of your wireless network, you can authenticate using authpf.

All the soloutions above assumes that you uses OpenBSD as an access point. OpenBSD can now support Atheros wireless chipset (for 802.11a), and soon 802.11g will be supported as well : Atheros HAL layer.

I think that you have been lied to. see here (and the discussion that ensues).

Please don't even bring up the notion of a freely distributable binary/closed source driver - that's what things like NDISulator basically workaround, they're nasty ugly kludges that are a REALLY REALLY bad idea for a large number of reasons (I won't get into them here, just like I won't go into why FCC arguments are a red herring). Closed binary firmware isn't ideal, but it's what we've dealt with for quite a while already (only, as mentioned before, it shipped on flashmem built into the hardware, not as a binary loaded by a driver).

As an aside, you mention the prospect that some of these chipsets are SDR's. If one of these vendors -did- open up the firmware binary or provide some sort of SDR chipset SDK, just think of what projects like GNURadio could accomplsih affordably and ubiquitously. THAT, unfortunately is probably a pipe dream for now, but would be WICKED cool (think affordable GNURadio, mixed with MythTV maybe). That sounds like another activism campaign worth fighting for someday for GNURadio. Today, let's just stick to the issue at hand and try to get these firmware binaries licensed in a manner that would allow OSS vendors to ship them out of the box.

All your stuff about radio licenses, considering that we're talking about unlicensed spectrum is silly and uninformed (I used to work for a cell/ss7/tcpip vendor and we dealt with LICENSED spectrum). If you stay under certain dB/wattages (which the -hardware- will restrict you to no matter what wonky firmware you might dream could be concocted), there's no issue. Don't believe me? Go out and buy a normal prism2.5 chipset based wireless NIC, flash it with the same firmware of a 300mW Zcomax prism2.5 card. Guess what, you won't have boosted the signal any, even though you can run them on the same firmware, why do you think that is? Your arguments wrt to FCC, though you make them sound good, don't hold any water.

You also don't sound like you're actually clear on the distinction between firmware binary or driver, you should read the post (and links) to clarify this. Moreover, there's a HUGE distinction between firmware binary and a HAL (hardware abstraction layer) as you mention in the atheros drivers.

I'll explain: In the case of firmware binaries - they substitute for what would typically be written to a flash chip on a network card, and are platform independent. A HAL layer, as in the case of the ath drivers, is an obfuscation layer within the -driver- itself. It is kept in binary form simply to attempt to thwart reverse engineering attempts as far as I can tell, and would never be written to flash memory as a standard firmware binary would be in traditional hardware design.

As a result, the HAL binary is platform and architecture specific. That may be fine if you only have to use it with x86 architectures, but you'll never be able to use that driver (with binary HAL) in, for example a G4 mac, or an ultrasparc. In the case of the firmware binary however, the driver is completely cross platform (assuming it's well written) and the firmware binary is specific to the Network card which could be shoved into any PCI (or maybe pcmcia) slot, it does not care what the architecture of the machine which the card is plugged into. The firmware binary is mated to the NIC; whereas the HAL binary is mated to the driver. Get the difference?

In other words, Atheros chipsets and drivers are a completely DIFFERENT issue than what we're talking about here. I'm glad that you're happy with it in Linux, on presumably an x86 machine - people who use other OS's and platforms (or OS's which run on multiple platforms and try to support them all diligently, e.g. OpenBSD, or even NetBSD) will continue to look elsewhere unless we see what Theo means by 'another creative way'

Being locked into hardware vendors for stupid reasons isn't desireable, regardless of what you think of Theo in this case - this is not an argument specific to OpenBSD. All OSS vendors (be they Free/Net/*BSD, Linux distros or more) can benefit form amiable firmware licensing. If these vendors hadn't cheaped out, we could all live with them and the already existing GPL and BSD licensed drivers, flashing firmware in rare occasions. We have that with prism2.5, hermes/lucent and other older legacy chipsets, but seems like a bunch of people decided to lessen dependence on flash memory and OSS users as a whole are feeling the pinch slowly but surely unless we tell them what we want.

All your stuff about radio licenses, considering that we're talking about unlicensed spectrum is silly and uninformed (I used to work for a cell/ss7/tcpip vendor and we dealt with LICENSED spectrum). If you stay under certain dB/wattages (which the -hardware- will restrict you to no matter what wonky firmware you might dream could be concocted), there's no issue. Don't believe me? Go out and buy a normal prism2.5 chipset based wireless NIC, flash it with the same firmware of a 300mW Zcomax prism2.5 card. Guess what, you won't have boosted the signal any, even though you can run them on the same firmware, why do you think that is? Your arguments wrt to FCC, though you make them sound good, don't hold any water.

You also don't sound like you're actually clear on the distinction between firmware binary or driver, you should read the post (and links) to clarify this. Moreover, there's a HUGE distinction between firmware binary and a HAL (hardware abstraction layer) as you mention in the atheros drivers.

I'll explain: In the case of firmware binaries - they substitute for what would typically be written to a flash chip on a network card, and are platform independent. A HAL layer, as in the case of the ath drivers, is an obfuscation layer within the -driver- itself. It is kept in binary form simply to attempt to thwart reverse engineering attempts as far as I can tell, and would never be written to flash memory as a standard firmware binary would be in traditional hardware design.

As a result, the HAL binary is platform and architecture specific. That may be fine if you only have to use it with x86 architectures, but you'll never be able to use that driver (with binary HAL) in, for example a G4 mac, or an ultrasparc. In the case of the firmware binary however, the driver is completely cross platform (assuming it's well written) and the firmware binary is specific to the Network card which could be shoved into any PCI (or maybe pcmcia) slot, it does not care what the architecture of the machine which the card is plugged into. The firmware binary is mated to the NIC; whereas the HAL binary is mated to the driver. Get the difference?

In other words, Atheros chipsets and drivers are a completely DIFFERENT issue than what we're talking about here. I'm glad that you're happy with it in Linux, on presumably an x86 machine - people who use other OS's and platforms (or OS's which run on multiple platforms and try to support them all diligently, e.g. OpenBSD, or even NetBSD) will continue to look elsewhere unless we see what Theo means by 'another creative way'

Being locked into hardware vendors for stupid reasons isn't desireable, regardless of what you think of Theo in this case - this is not an argument specific to OpenBSD. All OSS vendors (be they Free/Net/*BSD, Linux distros or more) can benefit form amiable firmware licensing. If these vendors hadn't cheaped out, we could all live with them and the already existing GPL and BSD licensed drivers, flashing firmware in rare occasions. We have that with prism2.5, hermes/lucent and other older legacy chipsets, but seems like a bunch of people decided to lessen dependence on flash memory and OSS users as a whole are feeling the pinch slowly but surely unless we tell them what we want.

Top 10 reasons IPTABLES is better than PF:

10. Parsing IPTABLES config files excellent preparation for subsequent
learning of Asian pictograph-based languages.

9. Standard logging via syslogd helps eliminate clutter in /var/log.

8. GPL prevents Steve Jobs from stealing your code.

7. Simplistic man pages encourage development of social skills via mailing
lists.

6. Multiple distributions, versions, kernels, modules, plugins, etc. keep
hackers confused as to exactly what they're attacking.

5. "Mangle" just sounds so much more 133+ than "Scrub".

4. Complexity of structure leads to more opportunities for obfuscation and
subsequent job security.

3. New and experimental kernel modules make life exciting again.

2. GUI and Web based utilities mean that anyone can set one up without knowing
what they're doing.

And the number one reason IPTABLES is better than PF:

1. No distracting arguments about whether to port it to OpenBSD.

Shamelessly stolen from the pf mailinglist.

The official release has just happened. Here are the official announcement, the undeadly.org thread and a torrent for the i386 binaries (149MB, matching MD5 which might beat some of the mirrors). Cheers ;)

There has been so much development in all the BSD's, and a new BSD system (DragonFlyBSD) coming out, how can anyone say *BSD is dead? The OpenBSD community has even pushed some vendors to release firmware for various hardware in a more open source way. If a "dead" community can convince hardware vendors to do that, then why isn't the Linux community doing more to make vendors release more firmware/docs in an open way.

here. It's work in progress. The patch, as submitted, is based on the wrong tree, needed further patching even to make it work with a stock kernel, busts 4k stacks and spits error messages. The submitters make it clear that there are a lot of versions to come.

Their intentions and goals are good, but it's a long way from ready for inclusion. It's a step along the road, but they need to submit a final and fully debugged version that doesn't bork anything, and with less marketdroid spin and more comprehensive testing and performance metrics.

Here is the LKML thread discussing this (including explanation of why it isnt accepted into mainline).

Actually, it already compiles for the most recent kernel (2.6.8-rc3) so I guess "big driver push" really means something else this time. Maybe 64 bit support. :p

Oh and they've hired some guy called Michel from the DRI project; http://marc.theaimsgroup.com/?l=dri-devel&m=109418 851616952&w=2

*shrug*

First, the old Pegasos 1 (which that usenet post mentioned) is long discontinued. The parent post to yours was talking about the successor, Peg2.

Second, you might wanna let people see that post in context, including the responses to the post. Perhaps a separate link to the following retraction and apology for some of the false accusations against Genesi would be in order as well.

And do we slashdotters really need to be reminded of that Theo "The rat" De Raadt is an absofuckinglutely raving lunatic?

Read this for more

Email from Darren to the ipfilter list

The apache webserver is switching to subversion. This was said in the mailing list post here and if you follow the thread it gives some good reasons behind using subversion. Examples from the original proposal include mod_dav_svn and mod_authz_svn which are Apache modules for web interface to the source repository.

Other examples include The Commons TLP and the SpamAssassin project which are projects of the Apache foundation are already using subversion. To see all the projects Apache foundation projects using SubVersion just go here

Useful links: Subversion homepage

Version Control with Subversion Book (mirror)

Replying to myself.

According to this, the GDI+ issue is also in the comment handler.

Is the page fault scalability patch the patches you were refering to?

Because the JPEG COM field length variable is 2 bytes wide, and itself is included in the length value, the minimum value for this field is 2, this implies an empty comment. If the comment length value is set to 1 or 0, a buffer overflow occurs overwriting heap management structures.

The problem is GDIPlus normalizes the COM length prior to checking it's value; a starting length of 0 becomes -2 after normalization (0xFFFE unsigned), this value is converted to the 32 bit value 0xFFFFFFFE and is eventually passed on to memcpy which attempts to copy ~4G bytes into heap memory.

Have a look at this funny catfight among "top" FreeBSD developers, starting here.

Wow, such "professional engineers", they're not like those idiot pimply faced teenagers who hack the Linux kernel.

Yes, it can do SpamAssasin or others:

james-user

Also, it can not only do local mailboxes, but you can easily tell it to use a db as a mail store (again, extremely simple xml file). This is nice as it lets you then repurpose mail into other programs/utilities as it's just more data in the db. There are lots of free webmail solutions on sourceforge that work well with james. Search the same user list above for the keyword "webmail" and you should be all set.

That whole thread on "no more apache updates" had nothing to do with security. It had everything to do with the OpenBSD team deciding not to keep using Apache HTTPD because of the new ASL 2.0 license. Personally I think the OpenBSD team is completely wrong on this issue and their attitude is incredibly offensive. Moreover, if you read the whole thread you'd find this response that the apache group has been responsive to the patches but that many of them are BSD specific and that's why they were not put into the main source tree.

That whole thread on "no more apache updates" had nothing to do with security. It had everything to do with the OpenBSD team deciding not to keep using Apache HTTPD because of the new ASL 2.0 license. Personally I think the OpenBSD team is completely wrong on this issue and their attitude is incredibly offensive. Moreover, if you read the whole thread you'd find this response that the apache group has been responsive to the patches but that many of them are BSD specific and that's why they were not put into the main source tree.

If you want wide adoption of Linux

Who told you 'we' do? Lots of kernel developers disagree

If you want wide adoption of Linux

Who told you 'we' do? Lots of kernel developers disagree

If you want wide adoption of Linux

Who told you 'we' do? Lots of kernel developers disagree

If you want wide adoption of Linux

Who told you 'we' do? Lots of kernel developers disagree

lp0 on fire

Not a typewriter

?

Not to mention the catch-all that I see from a lot of programs when anything at all goes slightly differently that the way the developer expected:

Segmentation violation (core dumped)

(Technically, it's the shell that prints that, not the program.)

On the flip side, when I worked at HP supporting HP-UX, I once saw a particular kernel error message. It was four lines long, and said very clearly, "so-and-so error has occurred. You probably need to increase the such-and-such parameter. You can do this by..."

I tracked down the guy that committed that message and promised to buy him a case of beer if he was ever in town.

1. There is a typo (unnecessary space) in your link.
2. I like marc.theaimsgroup.com much better.

So for the lazy among us: klicky.

It seemed promising.

= 9J =

Check this out, the awesome, scalable FreeBSD 5 can scale to *1* CPU on this simple MySQL test. Wooooaaaah!

I guess this would be a good time to puth forth Rasmus Lerdorf's excellent explanation for this issue. In short, due to there being many many different packages and applications and libs on Linux, and not ALL of them being threadsafe, I don't see anytime soon that Apache 2 will be "stable".

FreeBSD 5-CURRENT is steadily approaching a good level of stability

Apart from being a few years late, and looking like being at least another year, they still have serious scalability problems (see for example the recent thread about MySQL not even improving performance when going from 1 to 2 Opteron CPUs), their threading models and scheduler are still in the air, and not stable. Their "tier 1" amd64 architecture is pretty unstable.

after which it will be a Linux-killer for most desktop and some server applications.

Why would it be a Linux-killer for most desktop applications? Both kernels (and computers in general) are past the point where performance really matters for most desktop situations. The main things that matter are device drivers and what userspace programs can be run. You could argue that they are about equal in terms of programs, but Linux has far more device drivers at the moment.

As far as servers go, yeah it is possible and even probable that FreeBSD would be a better choice than Linux for some things. In what areas would it be a Linux killer though? (Please spare me the leet netcraft uptime or other template zealot bullshit).

NetBSD has been and always will be the best operating system for portability, and the 2 branch is making admirable progress into modern standards and functionality while retaining amazing stability and cleanliness.

Although the Linux kernel has more supported CPU architectures than NetBSD's. I grant that NetBSD exceeds all Linux distros that I know of, with only Debian coming close. I have heard that some NetBSD ports are pretty low quality though.

OpenBSD had some scalability issues which are resolved, and now is making way into modern SMP and other useful applications.

OpenBSD is still squarely at the the bottom of the performance heap, and if you think a completely serialised kernel is "modern SMP"... well... please don't bother replying.

DragonFlyBSD is making astonishing progress given its currently small (but talented and enthusiastic) developer base, and is already very close to being a viable alternative to FreeBSD for those who want something different.

No it isn't. Even the core developers acknowledge it is nowhere near close at this stage. The recent developer release trashed your hard drive, for example. No big deal of course, because it is a development release.

Also, have a look at this. DFBSD is 20% slower than FreeBSD 4.10 on this MySQL test. Trust me, they have a long way to go.

None of the BSDs are 'dead'. Their developer bases are largely comprised of people who focus on their Operating System (yes, technical note, all BSDs are entire Operating Systems, unlike Linux which is a toy kernel often accompanied by a user space tool chain you can run anywhere, and some hackish utilities for interfacing with the kernel

I'll interrupt you in this parenthesis... but you are wrong, Linux is a kernel, nothing more, nothing less. Its developer base is comprised of kernel developers. Sun, SGI, IBM, Intel, Dell, HP, Veritas, Toshiba, Sony, NEC, Google come to mind as they all have staff on Linux kernel development.

), not on how many file systems they can add barely-working support for, how many undocumented kernel options they can hack on without anyone's understanding, and how many tshirts they can sell for market saturation. Linux developers lost their goal as well, what began as a valiant and successful (even if more via media coverage than technical merit, as benchmarks of even 2.4 will show) development effort of a kernel from scratch, has become an orgy of random features,

What makes you think that? It is as much an orgy of random features as the FreeBSD kernel, for example. With

My god, you have a real bad attitude. And a big chip on your shoulder as well, by the sounds. Let's go through and dismantle some of your FUD.

FreeBSD 5-CURRENT is steadily approaching a good level of stability

Apart from being a few years late, and looking like being at least another year, they still have serious scalability problems (see for example the recent thread about MySQL not even improving performance when going from 1 to 2 Opteron CPUs), their threading models and scheduler are still in the air, and not stable. Their "tier 1" amd64 architecture is pretty unstable.

after which it will be a Linux-killer for most desktop and some server applications.

Why would it be a Linux-killer for most desktop applications? Both kernels (and computers in general) are past the point where performance really matters for most desktop situations. The main things that matter are device drivers and what userspace programs can be run. You could argue that they are about equal in terms of programs, but Linux has far more device drivers at the moment.

As far as servers go, yeah it is possible and even probable that FreeBSD would be a better choice than Linux for some things. In what areas would it be a Linux killer though? (Please spare me the leet netcraft uptime or other template zealot bullshit).

NetBSD has been and always will be the best operating system for portability, and the 2 branch is making admirable progress into modern standards and functionality while retaining amazing stability and cleanliness.

Although the Linux kernel has more supported CPU architectures than NetBSD's. I grant that NetBSD exceeds all Linux distros that I know of, with only Debian coming close. I have heard that some NetBSD ports are pretty low quality though.

OpenBSD had some scalability issues which are resolved, and now is making way into modern SMP and other useful applications.

OpenBSD is still squarely at the the bottom of the performance heap, and if you think a completely serialised kernel is "modern SMP"... well... please don't bother replying.

DragonFlyBSD is making astonishing progress given its currently small (but talented and enthusiasatic) developer base, and is already very close to being a viable alternative to FreeBSD for those who want something different.

No it isn't. Even the core developers acknowledge it is nowhere near close at this stage. The recent developer release trashed your hard drive, for example. No big deal of course, because it is a development release.

Also, have a look at this. DFBSD is 20% slower than FreeBSD 4.10 on this MySQL test. Trust me, they have a long way to go.

None of the BSDs are 'dead'. Their developer bases are largely comprised of people who focus on their Operating System (yes, technical note, all BSDs are entire Operating Systems, unlike Linux which is a toy kernel often accompanied by a user space tool chain you can run anywhere, and some hackish utilities for interfacing with the kernel

I'll interrupt you in this parenthesis... but you are wrong, Linux is a kernel, nothing more, nothing less. Its developer base is comprised of kernel developers. Sun, SGI, IBM, Intel, Dell, HP, Veritas, Toshiba, Sony, NEC, Google come to mind as they all have staff on Linux kernel development.

), not on how many file systems they can add barely-working support for, how many undocumented kernel options they can hack on without anyone's understanding, and how many tshirts they can sell for market saturation. Linux developers lost their goal as well, what began as a valiant and successful (even if more via media coverage than technical merit, as benchmarks of even 2.4 will show) development effort of a kernel from scratch, has become an orgy of random features,

What makes you think that? It is as much an orgy of random features as the Fr

Log message:
do not do the stratum guessing dance.
stratum is pretty much pointless anyway these days, and we certainly
do not want to send out illegal packets (stratum=0) until synced...

Actual Quote

Linux _DOES_ run in those machines with vanilla kernels. I guess throw their own patches but there's no doubt vanilla kernel is good enought: http://marc.theaimsgroup.com/?l=linux-kernel&m=108 341362028320&w=2

I've been following the PHP developers mailing list. The comments I've made have come up in discussion in that list quite a few times, with many ensuing flame-wars. Maybe some of that got quietly dropped, but that would be odd. Here are a couple links that illustrate what I've been watching over the past few months:

I didn't make any of this up, nobody could. Maybe it was finally decided off list to drop these things, but some pretty big developers were involved in these conversations. I'm just stating what I last knew to be the direction they were going with certain decisions and giving people warning that things may not be as compatible as they think.

I've been following the PHP developers mailing list. The comments I've made have come up in discussion in that list quite a few times, with many ensuing flame-wars. Maybe some of that got quietly dropped, but that would be odd. Here are a couple links that illustrate what I've been watching over the past few months:

I didn't make any of this up, nobody could. Maybe it was finally decided off list to drop these things, but some pretty big developers were involved in these conversations. I'm just stating what I last knew to be the direction they were going with certain decisions and giving people warning that things may not be as compatible as they think.

Mandrake is an excellent choice for MySQL. It works great out of the box. MySQL on Mandrake is actually twice as fast as FreeBSD, Mandrake wins MySQL benchmarks

And anyone who has better get them to update again: firefox/mozilla holes and no, this isn't the shell: bug from last week.

FreeBSD on AMD64 is not ready for primetime. Threading is is still broken. It would not be fair to benchmark FreeBSD on AMD64 until all the problems are figured out. FreeBSD's KSE on AMD64 is the show stopper. There has been some talk of reverting to Linuxthreads of FreeBSD in order to improve performance.

Here are the MySQL Benchmarks.

Isn't LTSP exactly what you want then? I remember reading a lot of discussion about the iOpener on the mailing list when they first came out.