There is not as yet an automated procedure for upgrading installed packages. Leaving the question of "why would you want one?" aside... pkg_version will at least give you the information necessary to determine if you have old versions of installed packages.
Recent changes to the Ports format (from which pre-built packages are actually made) are paving the way for such an automated procedure.
Myself, I wouldn't ever use such a feature because of errata or security problems inherent in unattended version changes. Perhaps for minor programs...certainly nothing that provides network services or on production servers. If you could make a list of packages that were auto-upgraded and leave everything else alone that might be alright, but such programs are probably so insignificant that I wouldn't care if I was a few releases behind.
If you're using the non RFC1918 address of 123.123.123.123 and you try to contact the real 123.123.123.123, the packet's going to go to Localhost. In fact, that entire subnet (whatever it may be) will be a black hole to you, as packets are sent to your local network instead of out your default gateway. Nothing Cisco can do will change that.
Unless that's not what you meant.
If you meant that this lets you translate for non RFC1918 addresses, then you can do that with most any NAT implementation I've seen.
You can create your own access point using a machine with a wavelan and a ethernet card. Then you'd have the full capabilities of the OS you ran on it and would not be limited by whatever Apple/Lucent/3Com/Cisco puts in their access points.
An old laptop or even an old 486 would work for this (You can get ISA adapters for the wavelan cards and they just slide into the back of the machine.)
1.How does the coverage of the two compare? Are the wireless transmitters
essentially the same? (Both seem to use Orinoco Silver cards, though the
RG-1000's card isn't removable.)
Yes, they are essentially the same. As you alluded to, you can replace the Silver card in the AirPort with a Gold for 128bit encryption. (As a hack previously mentioned on Slashdot, not supported by Apple.) With Line-of-Sight I get probably close to the 300 feet mark. I got much less when cutting a corner down the hall in my apartment building, but you're talking 10 walls and 5 apartment's worth of radio interference. I walked around the parking lot with no problems.
2.I've seen the stories about extending coverage by hooking an external antenna
to the Apple Airports. Can an external antenna be attached to the RG-1000? If
so, with or without hacking?
The AirPort antenna hack used an Orinoco antenna, so I sould assume the antenna's intended use is for with other Orinoco products. Check to be sure.
3.The Orinoco FAQ says that about 30 clients can be supported by a single
RG-1000. Apple's specs suggests 10 clients max. Has anyone used more then
10 clients with an Apple Airport and if so how well did it work?
Who knows if this is a licensing thing or what. I would assume you can support whatever 802.11b under these cards support, but if it's limited by the software then I can't say. I only have one wireless device myself. If it's a problem, buy three AirPorts.:) You'd pay the same price and could extend the coverage using what Apple calls Roaming (each base station must be wired to the ethernet though.)
4.Both products can do NAT. Can you configure filters or open up ports with the
utilities provided with either?
The AirPort does provide port mapping (redirecting ports on the external public IP to internal machines) but does not do packet filtering. It does have access control but this is for controlling which wireless devices may use the network (Using MAC addresses.) You should be doing packet filtering on your router (You run OpenBSD right?:) anyway.
Now for my own notes. I got an AirPort because my wife got an iBook for college (Those biologists tend to use Macs so she wanted to be compatible.) It's easier to get our LAN into her office using wireless than it is for me to string CAT5 up all over (It's an apartment so I can't go through the walls.) I also intend to get my own laptop soon and working (I work at home) from the balcony just sounds sweet.
At the time, the only way to configure the AirPort base station was to use Apple's configurator. At the heart of it though, it's just an SNMP device, and so of course someone has written a Java configurator that'll let you config it from anywhere. It works wonderfully. Grab it here. (It's also in the FreeBSD Ports collection if you happen to run that.:) One thing that I'm not sure of is if you can configure the AirPort from scratch using this. A quick note to the author could determine that.
I couldn't be happier with the thing, especially considering that it's some $500 cheaper than everything else out there. You can't beat that. V.90 modem and Ethernet. NAT or Bridge. It'll even do NAT for your ethernet if you connnect using it's modem. It's damned cute too. I think the only problem I have with it is lack of diagnostics when connecting using the modem.
Linux doesn't "come" with emacs either. Nothing "comes" with emacs. It's in OpenBSD's ports collection surely, and if it's not, I hear there's this thing called Open Source. You should try it some time.
routing...duh
NAT: Yes, and damn well too.
firewalling: packet filtering via access lists that run rings around ipfwadm and ipchains
MASQ: the layman's term for NAT, which is covered above
And in response to the other comments in this thread...userland routing daemons that provide dynamic routing protocols can't compare to the speed of the algorithms in the IOS kernel.
It's true that Unix on Intel can out compute a dedicated router..but they've got the code.
The server end of the tunnel MUST be authoritative for the domain which will be used to send the encapsulated IP packets. You can't choose any arbitrary server that just happens to be running the hacked BIND. (And it should be a hacked BIND unless you don't care about actually resolving hosts for the domain. Best way to do it would be to have a normal BIND running for mydomain.com, and have it delegate requests for *.tunnel.mydomain.com to the machine that's running the fake tunnel NS.)
I probably rambled there... it's like this
You dialup one of these MS numbers, and all that works is DNS requests. You start the tunnel. Your IP packet is encapsulated into a ns lookup and encoded as someencodedstring.domain.com. The request goes to some MS name server. The MS name server will check the root servers for the IP of the nameserver that is authoritative for domain.com (as registered.) The request is recieved, decoded, connections made, results received and reencapsulated and sent back to you.
I would assume that one would want normal DNS services for domain.com to be unaffected. So this hacked name server would either be a hacked version of BIND, or you would have to either setup a delegation scheme as above (which wouldn't require registration) or register a bogus domain that you never plan on using. I guess the fake name server could determine if a request was a tunnel or a real ns lookup and return a resource record if it was a real lookup. But I don't imagine they took it that far.
Not hardly. ISPs an support several hundred simultaenous dialup users with only a T1. All the traffic is bursty, so no one's using all 33.6 (or even 53K) of their connection at the same time.
Also, the majority of Quake (and so I assume other online FPS's) traffic is upstream, not down. That T1 is syncronous, so there's plenty of upstream bandwidth available. I run MRTG on my home network, and I've seen it when I play Quake.
This also means that a 56K modem doesn't help Quake games at all, since you're still only uploading at 33.6. V.92 will help that however.
And another thing, what does your post have to do with your actual title?
The consensus around my chapter of the ACM is that Linux makes a sufficient desktop OS, but for server boxen, you
want a flavour of BSD. As for upgrading the h/w now, why? Wring every last minute of uptime from the old hardware and
then take the same amount of money you'd spend on a Pentium4 now and wait to get an Itanium for the same price. Or
hell, an SMP G4/G5. But there's no use in decommissioning perfectly good hardware.
You hang a frame with any old nail and hammer.
You CAN'T write QT software without the QT toolkit. Otherwise it wouldn't be QT! The T in
QT is for toolkit for crissakes! If you're talking about IDE software for creating those applications, then that's different.
I admit I know nothing about QT on Windows and whether or not Troll Tech requires you to use their IDE software, if one exists.
That would indeed be different. However, it wouldn't be hypocrisy, because you don't know how CmdrTaco feels about it.
You're talking a full OS..not just a kernel. That's a major difference between a system like *BSD and any Linux distribution. They're talking the kernel and all of the userland including libc, and all tools and utilities that make up the base system. Linux distribution on the other hand are the kernel and whatever third party packages the Distributor decides to include. It's lack of an integrated source tree makes it not only smaller (less source) but less secure (with various authors behind each of the various packages.)
And it's about time too. Do you have any idea how often good, general Unix info is masqueraded as Linux info? And the worst part is, everyone buys into it, so that they think what they're learning is specific to Linux. It's evil I tell ya!
</SOUR GRAPES>
The ES1370 and 1371 have been supported for a GOOD long time. I also have the Ensoniq Audio PCI (the Ensoniq branded version, the 1370.) I've been using mine since at least last summer, probably longer.
The 1370 was first supported in Dec 98, and the 1371/73 was Nov 99.
The centralized documentation for sound card setup is and always has been in the handbook.
And when it comes to searching, nothing beats the mailing list archives. Specifically -questions and -media.
-STABLE is a constantly moving target. Starting with 4.0-RELEASE, it was known as 4.0-STABLE. At any given point in time, you can get the latest sources via CVS (CVSup being the best way) and make world and get a *newer* 4.0-STABLE. They in fact take daily (or near enough) snapshots and make them available via FTP (releng4.freebsd.org.)
This much you know already. If you don't, you do now.
When it's decided that it's time for a -RELEASE, the minor version number is bumped and (in this case) 4.1-RELEASE is born. About 5 minutes later (check the CVS logs) 4.1-STABLE is born. There's no such thing as having 4.1-STABLE before 4.1-RELEASE. The official announcement of 4.1-RELEASE just came a few days after it's creation. (In reality, for a few days before a -RELEASE there are a few -RC [Release Candidates].)
So if by last little while you mean 3 days, yeah, but you're already beyond 4.1-RELEASE.
Slashdot Mirror
There is not as yet an automated procedure for upgrading installed packages. Leaving the question of "why would you want one?" aside... pkg_version will at least give you the information necessary to determine if you have old versions of installed packages.
Recent changes to the Ports format (from which pre-built packages are actually made) are paving the way for such an automated procedure.
Myself, I wouldn't ever use such a feature because of errata or security problems inherent in unattended version changes. Perhaps for minor programs...certainly nothing that provides network services or on production servers. If you could make a list of packages that were auto-upgraded and leave everything else alone that might be alright, but such programs are probably so insignificant that I wouldn't care if I was a few releases behind.
Why is X on the server at all?
The algorithm was made public as part of Rivest's paper at MIT before the patent was applied for, much less granted.
If you're using the non RFC1918 address of 123.123.123.123 and you try to contact the real 123.123.123.123, the packet's going to go to Localhost. In fact, that entire subnet (whatever it may be) will be a black hole to you, as packets are sent to your local network instead of out your default gateway. Nothing Cisco can do will change that.
Unless that's not what you meant.
If you meant that this lets you translate for non RFC1918 addresses, then you can do that with most any NAT implementation I've seen.
You can create your own access point using a machine with a wavelan and a ethernet card. Then you'd have the full capabilities of the OS you ran on it and would not be limited by whatever Apple/Lucent/3Com/Cisco puts in their access points.
An old laptop or even an old 486 would work for this (You can get ISA adapters for the wavelan cards and they just slide into the back of the machine.)
Much cheaper than the already cheap AirPort.
The Lucent/Orinoco cards are supported under FreeBSD as well using the wi(4) driver.
You won't have a problem connecting any access point do an existing ethernet. I think they all support wireless->ethernet bridging.
1.How does the coverage of the two compare? Are the wireless transmitters essentially the same? (Both seem to use Orinoco Silver cards, though the RG-1000's card isn't removable.)
:) You'd pay the same price and could extend the coverage using what Apple calls Roaming (each base station must be wired to the ethernet though.)
:) anyway.
:) One thing that I'm not sure of is if you can configure the AirPort from scratch using this. A quick note to the author could determine that.
Yes, they are essentially the same. As you alluded to, you can replace the Silver card in the AirPort with a Gold for 128bit encryption. (As a hack previously mentioned on Slashdot, not supported by Apple.) With Line-of-Sight I get probably close to the 300 feet mark. I got much less when cutting a corner down the hall in my apartment building, but you're talking 10 walls and 5 apartment's worth of radio interference. I walked around the parking lot with no problems.
2.I've seen the stories about extending coverage by hooking an external antenna to the Apple Airports. Can an external antenna be attached to the RG-1000? If so, with or without hacking?
The AirPort antenna hack used an Orinoco antenna, so I sould assume the antenna's intended use is for with other Orinoco products. Check to be sure.
3.The Orinoco FAQ says that about 30 clients can be supported by a single RG-1000. Apple's specs suggests 10 clients max. Has anyone used more then 10 clients with an Apple Airport and if so how well did it work?
Who knows if this is a licensing thing or what. I would assume you can support whatever 802.11b under these cards support, but if it's limited by the software then I can't say. I only have one wireless device myself. If it's a problem, buy three AirPorts.
4.Both products can do NAT. Can you configure filters or open up ports with the utilities provided with either?
The AirPort does provide port mapping (redirecting ports on the external public IP to internal machines) but does not do packet filtering. It does have access control but this is for controlling which wireless devices may use the network (Using MAC addresses.) You should be doing packet filtering on your router (You run OpenBSD right?
Now for my own notes. I got an AirPort because my wife got an iBook for college (Those biologists tend to use Macs so she wanted to be compatible.) It's easier to get our LAN into her office using wireless than it is for me to string CAT5 up all over (It's an apartment so I can't go through the walls.) I also intend to get my own laptop soon and working (I work at home) from the balcony just sounds sweet.
At the time, the only way to configure the AirPort base station was to use Apple's configurator. At the heart of it though, it's just an SNMP device, and so of course someone has written a Java configurator that'll let you config it from anywhere. It works wonderfully. Grab it here. (It's also in the FreeBSD Ports collection if you happen to run that.
I couldn't be happier with the thing, especially considering that it's some $500 cheaper than everything else out there. You can't beat that. V.90 modem and Ethernet. NAT or Bridge. It'll even do NAT for your ethernet if you connnect using it's modem. It's damned cute too. I think the only problem I have with it is lack of diagnostics when connecting using the modem.
Linux doesn't "come" with emacs either. Nothing "comes" with emacs. It's in OpenBSD's ports collection surely, and if it's not, I hear there's this thing called Open Source. You should try it some time.
Ciscos provide all of those "normal" features:
routing...duh
NAT: Yes, and damn well too.
firewalling: packet filtering via access lists that run rings around ipfwadm and ipchains
MASQ: the layman's term for NAT, which is covered above
And in response to the other comments in this thread...userland routing daemons that provide dynamic routing protocols can't compare to the speed of the algorithms in the IOS kernel.
It's true that Unix on Intel can out compute a dedicated router..but they've got the code.
Also..it's really more of a tunnel to a proxy.
The server end of the tunnel MUST be authoritative for the domain which will be used to send the encapsulated IP packets. You can't choose any arbitrary server that just happens to be running the hacked BIND. (And it should be a hacked BIND unless you don't care about actually resolving hosts for the domain. Best way to do it would be to have a normal BIND running for mydomain.com, and have it delegate requests for *.tunnel.mydomain.com to the machine that's running the fake tunnel NS.)
I probably rambled there... it's like this
You dialup one of these MS numbers, and all that works is DNS requests. You start the tunnel. Your IP packet is encapsulated into a ns lookup and encoded as someencodedstring.domain.com. The request goes to some MS name server. The MS name server will check the root servers for the IP of the nameserver that is authoritative for domain.com (as registered.) The request is recieved, decoded, connections made, results received and reencapsulated and sent back to you.
I would assume that one would want normal DNS services for domain.com to be unaffected. So this hacked name server would either be a hacked version of BIND, or you would have to either setup a delegation scheme as above (which wouldn't require registration) or register a bogus domain that you never plan on using. I guess the fake name server could determine if a request was a tunnel or a real ns lookup and return a resource record if it was a real lookup. But I don't imagine they took it that far.
Only the server side of the tunnel runs a fake nameserver. (actually, it's a real nameserver, otherwise the request will be never get to foobar.com.)
The client side runs a hacked resolver. This doesn't require a static IP.
Not hardly. ISPs an support several hundred simultaenous dialup users with only a T1. All the traffic is bursty, so no one's using all 33.6 (or even 53K) of their connection at the same time.
Also, the majority of Quake (and so I assume other online FPS's) traffic is upstream, not down. That T1 is syncronous, so there's plenty of upstream bandwidth available. I run MRTG on my home network, and I've seen it when I play Quake.
This also means that a 56K modem doesn't help Quake games at all, since you're still only uploading at 33.6. V.92 will help that however.
And another thing, what does your post have to do with your actual title?
How is:
....flamebait?
The consensus around my chapter of the ACM is that Linux makes a sufficient desktop OS, but for server boxen, you want a flavour of BSD. As for upgrading the h/w now, why? Wring every last minute of uptime from the old hardware and then take the same amount of money you'd spend on a Pentium4 now and wait to get an Itanium for the same price. Or hell, an SMP G4/G5. But there's no use in decommissioning perfectly good hardware.
You still can't use RSAREF without a license.
This just means you can now use a home grown implemenation of the algorithm.
"The defend it or lose it" deal is for *trademarks*. It doesn't apply in this situation.
You hang a frame with any old nail and hammer.
You CAN'T write QT software without the QT toolkit. Otherwise it wouldn't be QT! The T in
QT is for toolkit for crissakes! If you're talking about IDE software for creating those applications, then that's different.
I admit I know nothing about QT on Windows and whether or not Troll Tech requires you to use their IDE software, if one exists.
That would indeed be different. However, it wouldn't be hypocrisy, because you don't know how CmdrTaco feels about it.
FYI
It's either an installer or a SEA. Just get the DM2 file from it and you can play it in
Quake2 under Linux just fine.
You're talking a full OS..not just a kernel. That's a major difference between a system like *BSD and any Linux distribution. They're talking the kernel and all of the userland including libc, and all tools and utilities that make up the base system. Linux distribution on the other hand are the kernel and whatever third party packages the Distributor decides to include. It's lack of an integrated source tree makes it not only smaller (less source) but less secure (with various authors behind each of the various packages.)
And it's about time too. Do you have any idea how often good, general Unix info is masqueraded as Linux info? And the worst part is, everyone buys into it, so that they think what they're learning is specific to Linux. It's evil I tell ya!
</SOUR GRAPES>
Isn't mirroring accomplished via cvsup? Just cron it.
And if it isn't, don't you watch the -stable list?
The ES1370 and 1371 have been supported for a GOOD long time. I also have the Ensoniq Audio PCI (the Ensoniq branded version, the 1370.) I've been using mine since at least last summer, probably longer.
The 1370 was first supported in Dec 98, and the 1371/73 was Nov 99.
The centralized documentation for sound card setup is and always has been in the handbook.
And when it comes to searching, nothing beats the mailing list archives. Specifically -questions and -media.
No, the servers don't run FreeBSD, it's the firewall. Don't you people remember anything?
-STABLE is a constantly moving target. Starting with 4.0-RELEASE, it was known as 4.0-STABLE. At any given point in time, you can get the latest sources via CVS (CVSup being the best way) and make world and get a *newer* 4.0-STABLE. They in fact take daily (or near enough) snapshots and make them available via FTP (releng4.freebsd.org.)
This much you know already. If you don't, you do now.
When it's decided that it's time for a -RELEASE, the minor version number is bumped and (in this case) 4.1-RELEASE is born. About 5 minutes later (check the CVS logs) 4.1-STABLE is born. There's no such thing as having 4.1-STABLE before 4.1-RELEASE. The official announcement of 4.1-RELEASE just came a few days after it's creation. (In reality, for a few days before a -RELEASE there are a few -RC [Release Candidates].)
So if by last little while you mean 3 days, yeah, but you're already beyond 4.1-RELEASE.