FreeSWAN barely talks to anything but itself, yet I can get FreeBSD's IPSec to talk to Cisco routers and do other things. Other things that are well-documented too, and there are no physical tussles over the code and where it goes.
I have had no trouble getting the KAME IPsec implementation (the one in {Net,Free}BSD) to talk to FreeS/WAN. Using either pre-shared keys or X509 certificates. In fact, I use exactly such a setup to keep my home network on a VPN with my colocated server. It works flawlessly.
Yes, I had to patch Linux to make it work, but the Debian FreeS/WAN packages make this really easy.
I've written some documentation
describing how I got KAME to talk to FreeS/WAN. Most of the docs really relate to X509 certificate authentication, but there's some discussion of the various IKE parameters that need to be changed. Different implementations choose different defaults for things like key lifetime and stuff, and you need to know how to get them to agree in order to get them to communicate happily.
If you had followed the entire debate, you know
that these "relaxations" are declarations (yes,
those like a King makes), and can be withdrawn by Bush at any time, without any democratic process.
Yes, but it was exactly the same kind of executive decree that made crypto illegal to export to begin with. There is no law in the US that states that crypto is a munition or that it can't be exported.
At this point, it really just doesn't make sense to hold off on adopting crytpo out of fear that the US is going to surprise everybody and yank our crypto rights out from under us. The cat, as they say, is out of the bag. It won't go back in. The government is welcome to try to re-regulate crypto export, but it won't work. (They actually tried this briefly after 9/11, and the proposals died silently.)
This news about crypto in the Linux kernel is wonderful. The more crypto is out there, integrated into our daily lives, the harder it will be for somebody to try to take it away from us.
The are some problems, for some reason LSB specifies a standard package, ie RPM
I do not know why, I see no reason for it, but obvious this is a problem for Debian, which has its own (imo superior) package (debs).
Grr, I'm so tired of people not getting this. The LSB usage of RPM is simply not a problem for Debian. We have no problems handling.rpm packages. See the rpm and alien packages (particularly alien) to see how we do it. The RPM thing is a non-issue regarding Debian's LSB compliance.
To see how seriously Debian takes LSB compliance, go have a look at the archives of the various LSB related Debian mailing lists
If you take a look at www.internet2.edu you'll see that they've just (as of August 5) announced native support for IPv6. That certainly is cool, as it's a major step towards getting IPv6 some more mainstream use. Provided that the sites on I2 have the ability to route IPv6, this means that users at the sites will be able to get real IPv6 connectivity to other I2 sites without tunneling. Way cool.
What would make me happiest is if they would turn off IPv4 on the damn thing, and force everyone to use IPv6, or not be able to connect.
I don't see much point in that. Most people today are (or should be!) writing address family independent code (note1, note2). Applications should be able to speak IPv4 and v6 natively with little trouble. So you should be able to speak IPv4 or v6 over I2; there's no reason that you need to prefer one over the other.
Also, I2 access is completely transparent for most sites. All it really involves is a new interface on a router and the software configuration to send I2-destined bits over it. This makes it really really easy for researchers to use I2. Since IPv6 is still an experimental protocol, it wouldn't really make sense to force research not directly related to IPv6 to use it.
Uhh, ipv6 is kinda the point of it anyway. The "Internet2" (also known as the "6Bone") _is_ the global ipv6 test network, after all. IPv6 is all it runs. Around my neck of the woods, its implemented as a mesh of SIT and GRE tunnels, but the backbone runs native.
No, that is simply untrue. There is no connection between the 6bone and Internet2. They are certainly not the same thing. It's perfectly normal to speak IPv4 on Internet2. I do it all the time, as do most people who send packets between major.edu sites. Internet2 is the testbed for not only new software networking technologies, but new hardware technologies as well. There is no hardware involved in the 6bone.
Here is a traceroute that goes over Internet2:
traceroute to infopath.ucsd.edu (132.239.50.184), 30 hops max, 38 byte packets 1 anacreon (18.24.4.1) 0.854 ms 0.510 ms 0.506 ms 2 radole (18.24.10.3) 1.505 ms 1.167 ms 1.547 ms 3 B24-RTR-1-LCS-LINK.MIT.EDU (18.201.1.1) 1.997 ms 1.409 ms 2.448 ms 4 EXTERNAL-RTR-2-BACKBONE.MIT.EDU (18.168.0.27) 1.140 ms 1.274 ms 1.366 ms 5 192.5.89.89 (192.5.89.89) 1.768 ms 1.718 ms 1.191 ms 6 ABILENE-GIGAPOPNE.NOX.ORG (192.5.89.102) 7.337 ms 6.181 ms 6.647 ms 7 clev-nycm.abilene.ucaid.edu (198.32.8.29) 20.210 ms 18.777 ms 19.306 ms 8 ipls-clev.abilene.ucaid.edu (198.32.8.25) 26.019 ms 24.682 ms 26.679 ms 9 kscy-ipls.abilene.ucaid.edu (198.32.8.5) 34.042 ms 35.163 ms 34.527 ms 10 dnvr-kscy.abilene.ucaid.edu (198.32.8.13) 46.358 ms 45.230 ms 44.955 ms 11 snva-dnvr.abilene.ucaid.edu (198.32.8.1) 69.201 ms 70.373 ms 69.657 ms 12 losa-snva.abilene.ucaid.edu (198.32.8.18) 77.485 ms 78.125 ms 77.248 ms 13 USC--abilene.ATM.calren2.net (198.32.248.85) 78.248 ms 77.353 ms 79.467 ms 14 UCSD--USC.POS.calren2.net (198.32.248.34) 81.871 ms 81.249 ms 81.188 ms 15 198.32.248.186 (198.32.248.186) 80.856 ms 81.965 ms 81.400 ms 16 node-b-msfc--ucsd-gw.ucsd.edu (132.239.255.141) 83.473 ms 82.277 ms 80.897 ms 17 muir-rsm--node-b-msfc.ucsd.edu (132.239.255.161) 82.902 ms 82.777 ms 81.225 ms 18 infopath-1.ucsd.edu (132.239.50.182) 83.200 ms * 84.386 ms
Hop 6 is where my packets enter Internet2, and hop 15 is where it leaves it. There is no IPv6 spoken along the way. Now here, just for fun, is an IPv6 traceroute going over the 6bone:
traceroute to 6bone.net (3ffe:b00:c18:1::10) from 2002:121a:12:1804:2a0:ccff:fe57:ccd9, 30 hops max, 16 byte packets 1 3ffe:1ce1:2:1804::2 (3ffe:1ce1:2:1804::2) 1.697 ms 0.391 ms 0.36 ms 2 sipbv6-rtr-sipb-ether.ipv6.mit.edu (3ffe:1ce1:0:b5::1) 509.888 ms 304.953 ms 305.882 ms 3 6bone.merit.edu (3ffe:1c00::3) 306.205 ms 305.879 ms 305.286 ms 4 rap.ipv6.viagenie.qc.ca (3ffe:b00:c18:1:290:27ff:fe17:fc0f) 306.464 ms 306.109 ms 304.732 ms 5 www.6bone.net (3ffe:b00:c18:1::10) 306.389 ms 308.274 ms 307.396 ms
Let me repeat that: Internet2 and 6bone are unrelated!
You have no right to complain about the MPAA and DVD CCA's war against fair use if you're willing to fund them. I for one will never buy a DVD that gives money to the MPAA. It is not worth it. My rights are more important than my entertainment. It's unfortunate that so many of the Slashdot crowd does not practice what it preaches.
Oh, that nasty low-res boot screen was supposed to be clouds. Christ, I never could make that out.;^)
But I don't recall there being a flying saucer. We at Debian put a lot of thought into the value that the flying saucer brings. It's how we differentiate from the other products on the market.
Can any of the Debian insiders comment on what the future of Debian looks like?
The whole point of Debian is that everything is done in the open. There's very little to be an "insider" on. Just subscribe to the mailing lists or read the archives and you'll be an insider.
Having said that, the future of Debian looks like a blue sky, with fluffy white clouds here and there. And a little flying saucer off in the distance.
Almost everything humans know is based on past experience. If we had to ask permission to use our experiences, then what would be the point of listing previous jobs on our resume? Companies could never fill "senior" positions because they all assume the person has passed through the junior version of the same position (gaining experience along the way, on would hope).
If drawing on past experience constitutes IP theft then the IP system as we know it is more fucked than I thought.
What the XMMS folks need to do is make XMMS into a client/server setup - the "server" which plays the MP3s, and a client that talks to the server via a socket for control.
Absolutely. I wrote a client/server jukebox program a while back to get me this functionality. The server stores the playlist internally and uses mpg321 (mpg123 gave me some problems) to play the music. Any number of clients can connect and modify the playlist, and then disconnect without disrupting the playlist. It would be very nice to be able to use XMMS as a client for my server.
The code is not particularly great, but it works well on our mp3 archive, which is stored on a headless machine with only 32 MB RAM and a 200MHz processor.
I never released it to the public before, but if anybody wants to check it out, it's at
http://locust.lcs.mit.edu/cgi-bin/viewcvs.cgi/flyn n/. It is written in Perl.
Before trying to make XMMS able to talk to it, it would probably make sense to change it to use TCP instead of Unix domain sockets. Right now the client has to run on the same machine as the server.
Just out of curiousity, could you expand? Why do you consider tunnelling bad? Is it the bandwidth loss due to protocol overhead or something else?
A talk was given at the USENIX conference last week in California in which the throughput performance of SSL/TLS was compared to that of IPsec. IPsec won easily in all cases.
Personally, I prefer IPsec since it can be used to encrypt and authenticate all IP layer traffic. If you're tunneling services over SSL, you're still leaking information to an eavesdropper (i.e. "I know you transferred 200 kB of mail via your tunneled pop3 connection"). With IPsec, it becomes difficult to differentiate between higher level protocols. UDP over IPsec doesn't look any different than TCP.
IPsec is also nice because it's starting to gain widespread industry acceptance. Setting it up on the free Unixes is very easy. Windows 2000 and XP come with it as a standard feature. I don't know if MacOS X 10.1 comes with it, but the forthcoming 10.2 release (Jaguar) includes it.
Mine? 18.24.6.206? Yeah, I only have one wireless card, and I needed it elsewhere. In fact it is now plugged in to the laptop on which I'm typing this post.
The iPaq handled the load well. It served up about 6000 pages during the day, and the load average was just about 0 the whole time. That makes sense, really, since thttpd only runs serially and was able to keep the single HTML doc cached most of the time.
Maybe I'll plug it back in tomorrow to see if people keep trying to hit it.
Is this MIT funded box, or are you so hardcore you spent all this $$$ just for the debian cause? Either way you rule.
It was paid for out of the budget for the group that I work for within the Lab for Computer Science. There are quite a few good mirrors here. Check out xyz.lcs.mit.edu for a bunch more.
Is this really just a protocol I can compile into my kernel, configure a few things and just punch in a ipv6 link? Or is it much more complicated than that, requiring special network hardware and access. I'd love to play around with it, I'm sure we'll all make the switch one day, I'd like to be ready.
You don't need to do anything special at all to be on Internet2, except be in the right place. You don't need to speak IPv6, either. Most I2 traffic is IPv4 generated by people who don't even know they're going over I2. The only thing is, you pretty much have no choice but to be at a US university in order to access I2. Chances are, if you're at one, and communicating with another, you're going over I2 without even needing to know about it.
On the other hand, if you want to play with globally routable IPv6, there are tons of resources for that and you don't need anything that you can't download. I posted some links in a recent Ask Slashdot article on IPv6. Check them out. You will be able to speak IPv6 on the Internet using 6-to-4 translation, which Linux and *BSD can do just fine. Or you can get a free tunnel via Freenet6, though I've not played with that at all.
This thing hauls ass! You should consider adding the kde debs from kde.tdyc.com. Deb heads would love a spry kde apt source.
Yeah, the box is a 1 GHz P3 with a gig of RAM and a fibre-channel RAID array for storage (no internal disks at all...way cool). It does nothing but mirror debian.
I don't have the disk space for extra stuff, but I'll happily add kde.tdyc.com once the new disks come. Maybe then I'll also be able to put up ISO images if they're helpful. I've already contacted the vendor and will probably install them by the end of the month. (and if you think SCSI disks are expensive, check out fibre-channel)
And of course, it's on Internet2, so you'll get very good connectivity if you are on it too.
The point is to do something like this to demonstrate that it can be done, because it'll find a use eventually.
Err, yeah, except that it was demonstrated ages ago and is just not news in any way at all. thttpd is included as a part of Familiar, the iPaq Linux distribution. What "research" did this guy do to find that it had been ported to the ARM? 'ipkg list'. Then 'ipkg install' and he's suddenly got a web server running on an iPaq. Wow, that's some 31337 h4X0r1ng there. If this was something new and different, it might be worth mentioning on slashdot. But it is not new or different.
We will continue to monitor this host for a few days, to get enough values to plot a graph. After this time the host will not be monitored again unless it's requested again, or it is one of the most frequently requested hosts."
Well, I do plan on going home tonight, and I have better uses for my wireless card than to sit and accumulate uptime for my little web server. So netcraft is going to end up plotting a flatline for this guy.
So for those that are intersted, keep checking this on Netcraft to see on the sitability of the wireless iPac as a hosting platform, you could even compare it to slashdot's uptime
Now that would be interesting. I wish I had a microdrive so we could install slash on the iPaq and see how it would handle dynamic sites and databases. It's not having any trouble with the load from Slashdot. It's served over 3000 pages and it's load average is consistantly around 0. It hasn't had any trouble with the kids out there who keep clicking reload rapidly in an attempt to make it fall over.
I do wonder how many pages the original story submitter's iPaq managed to serve.
Well, there's nothing wrong with trying to do something just to see if you can do it, especially if it's somehow novel. But when it's a simple matter of running 'ipkg install thttpd' to get a web server up and running, there's nothing newsworthy about it. Hell, the mere fact that thttpd is already packaged with familiar should have been an indication to the guy that there's nothing new about the idea of a web server on an iPaq.
Honestly, what's the big deal here? There's a Linux box running a web server. Is that a big deal anymore, even if it runs on "exotic" hardware? I'm sure this isn't the first web server run on a handheld. It's definitely not the first web server run on a Linux handheld. And it's not the first web server run on a Linux handheld over 802.11b.
I've got to agree with you on this. There is no need for a web server to be running anything other than Apache.
I suspect that meanings are being mixed. I don't think they are complaining that the server wasn't running bind, fingerd, NFS, etc etc. I suspect it was more that the web server software itself was unreasonably minimal. You won't likely see a real-world web site run on thttpd or something. I imagine the web server didn't support things like CGI and stuff, so the only way to get in would be to exploit a known buffer overflow or to exploit something on the OS level. There was no searching for insecure form handlers or things like that.
But I could be wrong. There are lots of idiots out there, after all.
noah
Re:I'd like a tutorial on
on
Learning IPv6?
·
· Score: 2
Apparently the Kernel 2.4 IPv6 isn't very good, so you use the usagi one.
I've been using the standard Linux 2.4 IPv6 with no problems at all for over a year (since about the time 2.4.0 came out). I've used USAGI a bit, but it actually introduced a bit of instability, causing my machine to lock up completely on a couple of occasions. I know there are some things that USAGI supposedly gets right that the kernel gets wrong, but I haven't run in to any of them. One thing that is supposed to make a difference, though, whether you're using USAGI or not, is building IPv6 statically into your kernel image. I've never managed to get a host using IPv6 as a module to autoconfigure at all.
Note also that USAGI includes important modifications to libc. Having good support in libc is as important as having kernel support.
Maybe I should check out USAGI again...
noah
what about IPv6 do you want to learn?
on
Learning IPv6?
·
· Score: 4, Informative
You didn't make it clear if you wanted to learn how to set up IPv6 on your network, or if you wanted to learn to program IPv6-enabled apps. You also didn't indicate what OS you are using, which means you can really only get general answers.
Programming IPv6 apps is actually quite easy, and actually involves programming protocol family independent code if you want to do it right. On the client end, this basically involves using a function (getaddrinfo(3)) to get a linked list of all addresses associated with a given hostname in any protocol family (IPv4, v6, or even something fun like AppleTalk) and walking along the list until you get a good connection. This has the added advantage that if you are trying to connect to a host that has multiple IP addresses, and some of them are non-responsive (i.e. a round-robin DNS situation), your client will try connecting to each IP address until it succeeds.
If you're trying to learn how to configure and use IPv6 on your hosts, try some of these:
Re:I'd like a tutorial on
on
Learning IPv6?
·
· Score: 3, Informative
Only IPv6? Most of these machines won't be able to do it. At this point, it's far more common to run both IPv6 and IPv4 on a host simultaneously. For whatever reason it seems that OSs hosts are unable to use IPv6 DNS hosts. I've gotten Linux to work IPv6-only (kernel 2.4.x, Debian unstable). I have heard from one of the FreeBSD network coders that FreeBSD can't do it, though that might not be current information. I don't think there's any way to get Windows to use IPv6 hosts for DNS servers.
WinXP can do dual-stack (IPv6 and IPv4) just fine. Just run 'ipv6 install' from a command prompt and you'll have a working autoconfiguring IPv6 host. Their docs are quite helpful.
I don't know anything about IPv6 on Macs, though I'd love to try it. Apparently OS X can do it, though all the pages I've found to describe it are in Japanese.
Sounds like they'll be only working with Linux from an interoperability perspective.
First of all, Linux is not Unix. Second of all, you missed at least a couple other references to their plans for Linux support within the company. They will not be doing any less Linux work than they have been, I suspect, and will likely end up working for a higher profile in the Linux community.
The new HP talks about following open standards. Where the hell is that in this roadmap?
Why the hell should it be there? This is their plan for the merging of the two companies' product lines. If either of the companies owns it, it's not an open standard, now, is it?
Slashdot Mirror
I have had no trouble getting the KAME IPsec implementation (the one in {Net,Free}BSD) to talk to FreeS/WAN. Using either pre-shared keys or X509 certificates. In fact, I use exactly such a setup to keep my home network on a VPN with my colocated server. It works flawlessly.
Yes, I had to patch Linux to make it work, but the Debian FreeS/WAN packages make this really easy.
I've written some documentation describing how I got KAME to talk to FreeS/WAN. Most of the docs really relate to X509 certificate authentication, but there's some discussion of the various IKE parameters that need to be changed. Different implementations choose different defaults for things like key lifetime and stuff, and you need to know how to get them to agree in order to get them to communicate happily.
noah
Yes, but it was exactly the same kind of executive decree that made crypto illegal to export to begin with. There is no law in the US that states that crypto is a munition or that it can't be exported.
At this point, it really just doesn't make sense to hold off on adopting crytpo out of fear that the US is going to surprise everybody and yank our crypto rights out from under us. The cat, as they say, is out of the bag. It won't go back in. The government is welcome to try to re-regulate crypto export, but it won't work. (They actually tried this briefly after 9/11, and the proposals died silently.)
This news about crypto in the Linux kernel is wonderful. The more crypto is out there, integrated into our daily lives, the harder it will be for somebody to try to take it away from us.
noah
Grr, I'm so tired of people not getting this. The LSB usage of RPM is simply not a problem for Debian. We have no problems handling .rpm packages. See the rpm and alien packages (particularly alien) to see how we do it. The RPM thing is a non-issue regarding Debian's LSB compliance.
To see how seriously Debian takes LSB compliance, go have a look at the archives of the various LSB related Debian mailing lists
noah
If you take a look at www.internet2.edu you'll see that they've just (as of August 5) announced native support for IPv6. That certainly is cool, as it's a major step towards getting IPv6 some more mainstream use. Provided that the sites on I2 have the ability to route IPv6, this means that users at the sites will be able to get real IPv6 connectivity to other I2 sites without tunneling. Way cool.
(Of course, anybody can get IPv6 Internet access using tunnels. See freenet6.net and some 6-to-4 information.)
But I2 still isn't the 6bone. ;^)
noah
I don't see much point in that. Most people today are (or should be!) writing address family independent code (note1, note2). Applications should be able to speak IPv4 and v6 natively with little trouble. So you should be able to speak IPv4 or v6 over I2; there's no reason that you need to prefer one over the other.
Also, I2 access is completely transparent for most sites. All it really involves is a new interface on a router and the software configuration to send I2-destined bits over it. This makes it really really easy for researchers to use I2. Since IPv6 is still an experimental protocol, it wouldn't really make sense to force research not directly related to IPv6 to use it.
noah
No, that is simply untrue. There is no connection between the 6bone and Internet2. They are certainly not the same thing. It's perfectly normal to speak IPv4 on Internet2. I do it all the time, as do most people who send packets between major .edu sites. Internet2 is the testbed for not only new software networking technologies, but new hardware technologies as well. There is no hardware involved in the 6bone.
Here is a traceroute that goes over Internet2:
Hop 6 is where my packets enter Internet2, and hop 15 is where it leaves it. There is no IPv6 spoken along the way. Now here, just for fun, is an IPv6 traceroute going over the 6bone:
Let me repeat that: Internet2 and 6bone are unrelated!
noah
noah
Oh, that nasty low-res boot screen was supposed to be clouds. Christ, I never could make that out. ;^)
But I don't recall there being a flying saucer. We at Debian put a lot of thought into the value that the flying saucer brings. It's how we differentiate from the other products on the market.
Why I just posted this I'll never know...
noah
The whole point of Debian is that everything is done in the open. There's very little to be an "insider" on. Just subscribe to the mailing lists or read the archives and you'll be an insider.
Having said that, the future of Debian looks like a blue sky, with fluffy white clouds here and there. And a little flying saucer off in the distance.
noah
Uhh, we did tell them. In the announcement.
It is official, woody is released.
If drawing on past experience constitutes IP theft then the IP system as we know it is more fucked than I thought.
noah
Absolutely. I wrote a client/server jukebox program a while back to get me this functionality. The server stores the playlist internally and uses mpg321 (mpg123 gave me some problems) to play the music. Any number of clients can connect and modify the playlist, and then disconnect without disrupting the playlist. It would be very nice to be able to use XMMS as a client for my server.
The code is not particularly great, but it works well on our mp3 archive, which is stored on a headless machine with only 32 MB RAM and a 200MHz processor. I never released it to the public before, but if anybody wants to check it out, it's at http://locust.lcs.mit.edu/cgi-bin/viewcvs.cgi/flyn n/. It is written in Perl.
Before trying to make XMMS able to talk to it, it would probably make sense to change it to use TCP instead of Unix domain sockets. Right now the client has to run on the same machine as the server.
noah
A talk was given at the USENIX conference last week in California in which the throughput performance of SSL/TLS was compared to that of IPsec. IPsec won easily in all cases.
Personally, I prefer IPsec since it can be used to encrypt and authenticate all IP layer traffic. If you're tunneling services over SSL, you're still leaking information to an eavesdropper (i.e. "I know you transferred 200 kB of mail via your tunneled pop3 connection"). With IPsec, it becomes difficult to differentiate between higher level protocols. UDP over IPsec doesn't look any different than TCP.
IPsec is also nice because it's starting to gain widespread industry acceptance. Setting it up on the free Unixes is very easy. Windows 2000 and XP come with it as a standard feature. I don't know if MacOS X 10.1 comes with it, but the forthcoming 10.2 release (Jaguar) includes it.
noah
Mine? 18.24.6.206? Yeah, I only have one wireless card, and I needed it elsewhere. In fact it is now plugged in to the laptop on which I'm typing this post.
The iPaq handled the load well. It served up about 6000 pages during the day, and the load average was just about 0 the whole time. That makes sense, really, since thttpd only runs serially and was able to keep the single HTML doc cached most of the time.
Maybe I'll plug it back in tomorrow to see if people keep trying to hit it.
noah
It was paid for out of the budget for the group that I work for within the Lab for Computer Science. There are quite a few good mirrors here. Check out xyz.lcs.mit.edu for a bunch more.
Is this really just a protocol I can compile into my kernel, configure a few things and just punch in a ipv6 link? Or is it much more complicated than that, requiring special network hardware and access. I'd love to play around with it, I'm sure we'll all make the switch one day, I'd like to be ready.
You don't need to do anything special at all to be on Internet2, except be in the right place. You don't need to speak IPv6, either. Most I2 traffic is IPv4 generated by people who don't even know they're going over I2. The only thing is, you pretty much have no choice but to be at a US university in order to access I2. Chances are, if you're at one, and communicating with another, you're going over I2 without even needing to know about it.
On the other hand, if you want to play with globally routable IPv6, there are tons of resources for that and you don't need anything that you can't download. I posted some links in a recent Ask Slashdot article on IPv6. Check them out. You will be able to speak IPv6 on the Internet using 6-to-4 translation, which Linux and *BSD can do just fine. Or you can get a free tunnel via Freenet6, though I've not played with that at all.
Have fun.
noah
Yeah, the box is a 1 GHz P3 with a gig of RAM and a fibre-channel RAID array for storage (no internal disks at all...way cool). It does nothing but mirror debian.
I don't have the disk space for extra stuff, but I'll happily add kde.tdyc.com once the new disks come. Maybe then I'll also be able to put up ISO images if they're helpful. I've already contacted the vendor and will probably install them by the end of the month. (and if you think SCSI disks are expensive, check out fibre-channel)
And of course, it's on Internet2, so you'll get very good connectivity if you are on it too.
noah
Err, yeah, except that it was demonstrated ages ago and is just not news in any way at all. thttpd is included as a part of Familiar, the iPaq Linux distribution. What "research" did this guy do to find that it had been ported to the ARM? 'ipkg list'. Then 'ipkg install' and he's suddenly got a web server running on an iPaq. Wow, that's some 31337 h4X0r1ng there. If this was something new and different, it might be worth mentioning on slashdot. But it is not new or different.
noah
Well, I do plan on going home tonight, and I have better uses for my wireless card than to sit and accumulate uptime for my little web server. So netcraft is going to end up plotting a flatline for this guy.
So for those that are intersted, keep checking this on Netcraft to see on the sitability of the wireless iPac as a hosting platform, you could even compare it to slashdot's uptime
Now that would be interesting. I wish I had a microdrive so we could install slash on the iPaq and see how it would handle dynamic sites and databases. It's not having any trouble with the load from Slashdot. It's served over 3000 pages and it's load average is consistantly around 0. It hasn't had any trouble with the kids out there who keep clicking reload rapidly in an attempt to make it fall over.
I do wonder how many pages the original story submitter's iPaq managed to serve.
noah
Well, there's nothing wrong with trying to do something just to see if you can do it, especially if it's somehow novel. But when it's a simple matter of running 'ipkg install thttpd' to get a web server up and running, there's nothing newsworthy about it. Hell, the mere fact that thttpd is already packaged with familiar should have been an indication to the guy that there's nothing new about the idea of a web server on an iPaq.
noah
Here, just for fun, is a link to my iPaq running thttpd over a wireless link. It's really nothing spectacular.
noah
I suspect that meanings are being mixed. I don't think they are complaining that the server wasn't running bind, fingerd, NFS, etc etc. I suspect it was more that the web server software itself was unreasonably minimal. You won't likely see a real-world web site run on thttpd or something. I imagine the web server didn't support things like CGI and stuff, so the only way to get in would be to exploit a known buffer overflow or to exploit something on the OS level. There was no searching for insecure form handlers or things like that.
But I could be wrong. There are lots of idiots out there, after all.
noah
I've been using the standard Linux 2.4 IPv6 with no problems at all for over a year (since about the time 2.4.0 came out). I've used USAGI a bit, but it actually introduced a bit of instability, causing my machine to lock up completely on a couple of occasions. I know there are some things that USAGI supposedly gets right that the kernel gets wrong, but I haven't run in to any of them. One thing that is supposed to make a difference, though, whether you're using USAGI or not, is building IPv6 statically into your kernel image. I've never managed to get a host using IPv6 as a module to autoconfigure at all.
Note also that USAGI includes important modifications to libc. Having good support in libc is as important as having kernel support.
Maybe I should check out USAGI again...
noah
Programming IPv6 apps is actually quite easy, and actually involves programming protocol family independent code if you want to do it right. On the client end, this basically involves using a function (getaddrinfo(3)) to get a linked list of all addresses associated with a given hostname in any protocol family (IPv4, v6, or even something fun like AppleTalk) and walking along the list until you get a good connection. This has the added advantage that if you are trying to connect to a host that has multiple IP addresses, and some of them are non-responsive (i.e. a round-robin DNS situation), your client will try connecting to each IP address until it succeeds.
If you're trying to learn how to configure and use IPv6 on your hosts, try some of these:
WinXP can do dual-stack (IPv6 and IPv4) just fine. Just run 'ipv6 install' from a command prompt and you'll have a working autoconfiguring IPv6 host. Their docs are quite helpful.
I don't know anything about IPv6 on Macs, though I'd love to try it. Apparently OS X can do it, though all the pages I've found to describe it are in Japanese.
noah
First of all, Linux is not Unix. Second of all, you missed at least a couple other references to their plans for Linux support within the company. They will not be doing any less Linux work than they have been, I suspect, and will likely end up working for a higher profile in the Linux community.
The new HP talks about following open standards. Where the hell is that in this roadmap?
Why the hell should it be there? This is their plan for the merging of the two companies' product lines. If either of the companies owns it, it's not an open standard, now, is it?
noah