Since there were *no* examples of writing a hardware driver using an LKM on OpenBSD, and there are plenty of examples of new ones being added to the static kernel, I don't think this in any way makes adding hardware drivers more difficult. To my knowledge over the last 16 years or so, the only real uses for LKMs have been kqemu (discontinued upstream) and dellflash (perhaps it works on laptops but it never worked on any poweredge which I tried it on). Note that neither of these are hardware drivers.
Some of the less-helpful "community" members could do with a kick up the arse though, better to not post than to post an RTFM without at least pointing out which bit of TFM to R. I'm sure that often they don't know the answer themselves. (Not to be mistaken with mails from time-starved people that are equally short but do actually point people in the right direction...)
Besides the "what if someone fucks with/dev/random" issues, there are problems like "what if the sysadmin forgets to create/dev/random in chroot" (ok, sysadmin failure but it can be protected against - and better to fail hard than fallback to a bad entropy source) and especially "what if an attacker holds open a bunch of FDs so opening/dev/random fails". This last one is perhaps the most worrying.
Re:Funny how similar the free Unices are
on
FreeBSD 8.0 Released
·
· Score: 2, Informative
If you run FreeBSD, having PF ported gives you a more sane choice of firewall there, but if you're setting out specifically to run PF, OpenBSD gives some major benefits. The code is several years ahead of FreeBSD's port. Watch some of the recent presentations to see what's changed - see links to a couple of related videos at http://spacehopper.org/pfvids/
You can't take a single email from a single developer of a single BSD-derived OS and extrapolate that to "the *BSD side" (if there even is such a thing)...
hah. You're seriously underestimating the work involved. An OpenBSD release covers around a dozen machine architectures: one donated Pentium won't cut it. And besides the machines, also needed would be additional power, cooling, another rack, *space to put all of this*, before you even start on the non-trivial amounts of time (necessarily that of a trusted developer) to prepare and test things out.
Unfortunately, a lot of people seem to be mistaken about the facts.
The open-source HAL, the work of Reyk Floeter, was *never* dual licensed; he has only released it under the ISC license.
There *are* some dual-licensed files in the driver, but that is not what the OpenBSD people have a problem with.
The code *has* been published with the GPL fully replacing the ISC license; for example, see the madwifi repository. It was also published elsewhere, but since removed. For sure, not just a diff proposed on a mailing list.
It is still being published (madwifi again) with GPL wrapped around the ISC license and with added copyright authors
It is still being published, now under the ISC license and with added copyright authors
The changes in these versions which are still published are mostly for adaptation, there doesn't seem enough original work to claim joint copyright (I guess, unless the original author agrees)
Funnily enough, a lot of this is covered right here.
This wouldn't help much anyway: the packets would still come in, whether or not they're dropped. The most efficient and lowest-cost way to drop the packets is probably to move the server to a prefix that's announced only to DIX members.
You don't have to post a (cheque|check), there's a perfectly good ordering system which includes the options to send donations, and a simple bank transfer system in Europe which avoids credit-card handling fees (there's no charge for inter-country bank transfers between Eurozone countries).
There's equipment costs (some gets donated, some doesn't: some of the vendors who use OpenSSH produce equipment which isn't well-supported by OpenBSD - this could probably be turned around by some judicious hardware donations and maybe a bit of assistance with docs). Around $5000/year goes on electricity. More goes on hackathons. This is all easily publically-available information, and is good enough for the many many individuals and small businesses who donate. Why should larger users who stand to make much more from the software be any less-trusting than the individuals who probably donate a much higher % of their income than the larger users would donate anyway?
Sure donation's not *required*...but where's the future cool stuff these companies can bundle for free going to come from if potential developers see how the large companies treat people whose open-source work they already profit from?
I thought the, "so fix it yourself newbie!" attitude was mostly confined to actual coding.
nope, it definitely includes anything that detract the developers from coding. Obtaining hardware samples and docs, lobbying for funding, arranging beverages, buying CDs, you can probably think of more...
2458 [helios ~]% ls -l `which {vi,mg,ed}` -r-xr-xr-x 1 root bin 162400 Jun 2 00:58/bin/ed -r-xr-xr-x 1 root bin 101988 Jun 2 00:58/usr/bin/mg -r-xr-xr-x 3 root bin 277724 Jun 2 00:58/usr/bin/vi
- and that's *with* 9k of theo.c.
Anyway, to drag it back on-topic, my index finger hurts if I try and use a mouse. Trackball fixed it for a month or so, then was 10x worse on my thumb. Smallish Wacom pad is the only pointer for me... Keyboard's a lot better though (Dvorak layout is working pretty well, sub-optimal for some software but not too annoying - took a few months to learn how to switch between pyfgcrl and qwerty without needing a different type of keyboard for each though..!)
The whole point of the HAL (e.g. as needed for Atheros prior to Reyk's great work, and different to the BIOS needed on cards including CPUs e.g. ipi, ipw, Prism54) is that a HAL runs on the *host processor*, as part of the kernel, not on the device, and it's a lot more difficult to audit...
The BIOS-redistribution-restrictions are pretty stupid, though not always unexpected: for example, if you try to use an Intel Ethernet card under Windows, drivers are often not included in the OS, so Intel get to make you to agree to a click-through license when you download or install from CD, so I think they're probably trying to apply the same logic here.
There are loads of Ralink-based devices around... In.uk, of the PCI cards, you'll probably have most luck finding MSI PC54G2 and Gigabyte GN-WPKG. Double-check the chipset if that's possible, since it seems quite a few manufacturers are now switching to Marvell.
When it says "max 15W" on the Soekris product page for the 4801, that's the maximum (I think it's the power available from the DC-DC converter), not a typical figure. They're more like 5W in use (more with a HD of course). There are PCMCIA Soekris boxes too, but if it's wireless you want it for, MiniPCI is often a better idea.
Here in.uk, it's generally quite a bit cheaper to use a discount telco (e.g. call18866) from a normal phone than it is to use voip. I imagine they may well be voip from the point they take the call, however it's presumably a lot cheaper to run it centrally with good economies of scale and greatly reduced support costs (e.g. no supporting individual users of varying competence with their own voip kit).
If you use cloth diapers, you can be pretty much assured that your child will let you know when they are wet.
Line them with a piece of fleece and they'll go much longer - since fleece is nonabsorbent it keeps the wetness away from the skin unless the cloth is utterly soaked - solids pretty much rinse right off when held under the flush.
VNC doesn't require an installed client, a Java one is served automatically. I was surprised at how well ultravnc works for webcam images, even over ISDN. There are much better solutions, but considering how simple the installation is, there is a place for it as a quick fix.
MRT and Zebra are now fast-decaying abandoned project, as far as I can tell. The only Open Source software router I can find is Click, and whilst it's good, it doesn't have the developer- or user-base to be confident that it can really do more than be a nice experimental project.
OpenBSD is coming up to the second release with BGP support: "partial support for multiprotocol (only IPv4-unicast is announced)" for now, but it's certainly an active project.
Seconded... Since I have static IP but don't really want lookups being done over DSL, I've been using their secondary-only service, not listing my primary in the gtld-servers or NS records. Secondary is reasonably priced and working very nicely (support for bind notify or web-based reloads) - and of course in this case, as they're just doing a zone-transfer you can have whatever records you like. I used to use their more expensive web-based service which I was happy with too - I'd highly recommend easydns.
You'll find some tips on a small install of FreeBSD here (and something packaged here). It's mostly aimed at embedded router-type systems, so as-is it would probably suit your gateway/dns/web box quite well. You should be able to easily fit that into a 16mb flashcard, the smaller systems would have it running in 5-6. Expect to have more work to do for a desktop system.
You might also find it interesting to read about other efforts for making small systems on other OS, amongst others flashboot, flashdist, MeshBox, Pebble Linux. You'll probably also learn a lot about this by examining how 'live-cd' software is prepared (e.g. livecd.sf.net, knoppix).
A lot of these techniques are aiming at small single-task embedded systems (often on minimal hardware, e.g. net4501/net4801), but the techniques are generally applicable, and can be used to make all types of system on various OS.
This isn't how it would work. When a client resolves a domain name, it would provide a domain name and "use ID" and would get, in return, an IP address and port and would go directly to the IP/port.
We've already got one of those: rfc2782... It's in use already, but mainly in-site as part of DNS service discovery (rendezvous/zeroconf) and ActiveDirectory - it's not supported by e.g. standard web browsers, email clients etc.
There are problems with using site-variable port numbers: it makes identifying traffic types a little tricky, having implications for e.g. traffic prioritisation, blocking malicious/unwanted traffic. As such it's probably more useful on a network within one administrative domain than on the internet.
There's no corresponding method for looking up service types given a port number and IP address (e.g. additional records to in-addr.arpa) to help out, possibly because it would be rather difficult to place any degree of trust in that data anyway: you can't really have an unknown DNS server controlling your firewall policy. This is a bit of a different thing than MX records, where port numbers can't be defined.
It wouldn't be any more difficult than what all mail clients have to do right now to determine the MX record for a domain name. All software would have to provide that "use ID" and then connect to an IP/port, rather than how things are done now where there is no "use ID" and the port is assumed. It wouldn't burden anyone very much.
For protocols already in common use, it would add delays and/or place more load on DNS in the changeover period (which is likely to be protracted). Other problems too. Someone types in example.com - what do you need to lookup? www.example.com A, example.com A, example.com SRV? What about sites where these are different - which address do you connect to? Then, do you send them off all at once (reduces delays in the common instance but has a tendency to increase delays overall)? How long do you wait for replies? - they could come back out of order. Or do you send them serially, which will add some delay to the majority of lookups, but is on-the-whole friendlier to the networks and DNS servers.
A web browser vendor is unlikely to be particularly happy to add and default-enable a feature that adds to the time taken to resolve the majority of names - but realistically, you won't have very high takeup on the server side until most clients threaten not to connect unless it's done. For newer protocols it's simpler, since there often need be no fallback to A record, and indeed SRV records are being used on some newer protocols. Still, the traffic identification problem is still there.
Adding this to HTTP is a bit different than the case with adding MX to email: many more people will notice the increased time to resolve the name. With email, the delay is in the background, after the message has left the end-user's mail client and enters the transport system: it's almost invisible. With interactive requests such as HTTP, any delay is immediately obvious.
Since it doesn't really buy you anything you don't get from an address-translating device on the IP address of example.com, and given the complexities and problems it adds, who's going to use it?
Should be fairly easy to retrain: Ctrl-Tab to switch pages, Alt-Tab to switch programs... So much quicker than alt-tab-tab-tab-tab-tab-tab-tab past all the browser windows to reach other apps.
Slashdot Mirror
Some of the less-helpful "community" members could do with a kick up the arse though, better to not post than to post an RTFM without at least pointing out which bit of TFM to R. I'm sure that often they don't know the answer themselves. (Not to be mistaken with mails from time-starved people that are equally short but do actually point people in the right direction...)
Besides the "what if someone fucks with /dev/random" issues, there are problems like "what if the sysadmin forgets to create /dev/random in chroot" (ok, sysadmin failure but it can be protected against - and better to fail hard than fallback to a bad entropy source) and especially "what if an attacker holds open a bunch of FDs so opening /dev/random fails". This last one is perhaps the most worrying.
A bit ungainly, but that's necessary. Redhat tried to make it look neater and ended up with https://bugzilla.redhat.com/sh...
There is refutation from Jason; http://marc.info/?l=openbsd-tech&m=129244045916861&w=2
If you run FreeBSD, having PF ported gives you a more sane choice of firewall there, but if you're setting out specifically to run PF, OpenBSD gives some major benefits. The code is several years ahead of FreeBSD's port. Watch some of the recent presentations to see what's changed - see links to a couple of related videos at http://spacehopper.org/pfvids/
"promptly shot down by someone on the *BSD side"
You can't take a single email from a single developer of a single BSD-derived OS and extrapolate that to "the *BSD side" (if there even is such a thing)...
- The open-source HAL, the work of Reyk Floeter, was *never* dual licensed; he has only released it under the ISC license.
- There *are* some dual-licensed files in the driver, but that is not what the OpenBSD people have a problem with.
- The code *has* been published with the GPL fully replacing the ISC license; for example, see the madwifi repository. It was also published elsewhere, but since removed. For sure, not just a diff proposed on a mailing list.
- It is still being published (madwifi again) with GPL wrapped around the ISC license and with added copyright authors
- It is still being published, now under the ISC license and with added copyright authors
- The changes in these versions which are still published are mostly for adaptation, there doesn't seem enough original work to claim joint copyright (I guess, unless the original author agrees)
Funnily enough, a lot of this is covered right here.This wouldn't help much anyway: the packets would still come in, whether or not they're dropped. The most efficient and lowest-cost way to drop the packets is probably to move the server to a prefix that's announced only to DIX members.
There's equipment costs (some gets donated, some doesn't: some of the vendors who use OpenSSH produce equipment which isn't well-supported by OpenBSD - this could probably be turned around by some judicious hardware donations and maybe a bit of assistance with docs). Around $5000/year goes on electricity. More goes on hackathons. This is all easily publically-available information, and is good enough for the many many individuals and small businesses who donate. Why should larger users who stand to make much more from the software be any less-trusting than the individuals who probably donate a much higher % of their income than the larger users would donate anyway?
Sure donation's not *required*...but where's the future cool stuff these companies can bundle for free going to come from if potential developers see how the large companies treat people whose open-source work they already profit from?
Anyway, to drag it back on-topic, my index finger hurts if I try and use a mouse. Trackball fixed it for a month or so, then was 10x worse on my thumb. Smallish Wacom pad is the only pointer for me... Keyboard's a lot better though (Dvorak layout is working pretty well, sub-optimal for some software but not too annoying - took a few months to learn how to switch between pyfgcrl and qwerty without needing a different type of keyboard for each though..!)
The whole point of the HAL (e.g. as needed for Atheros prior to Reyk's great work, and different to the BIOS needed on cards including CPUs e.g. ipi, ipw, Prism54) is that a HAL runs on the *host processor*, as part of the kernel, not on the device, and it's a lot more difficult to audit...
The BIOS-redistribution-restrictions are pretty stupid, though not always unexpected: for example, if you try to use an Intel Ethernet card under Windows, drivers are often not included in the OS, so Intel get to make you to agree to a click-through license when you download or install from CD, so I think they're probably trying to apply the same logic here.
There are loads of Ralink-based devices around... In .uk, of the PCI cards, you'll probably have most luck finding MSI PC54G2 and Gigabyte GN-WPKG. Double-check the chipset if that's possible, since it seems quite a few manufacturers are now switching to Marvell.
When it says "max 15W" on the Soekris product page for the 4801, that's the maximum (I think it's the power available from the DC-DC converter), not a typical figure. They're more like 5W in use (more with a HD of course). There are PCMCIA Soekris boxes too, but if it's wireless you want it for, MiniPCI is often a better idea.
Here in .uk, it's generally quite a bit cheaper to use a discount telco (e.g. call18866) from a normal phone than it is to use voip. I imagine they may well be voip from the point they take the call, however it's presumably a lot cheaper to run it centrally with good economies of scale and greatly reduced support costs (e.g. no supporting individual users of varying competence with their own voip kit).
VNC doesn't require an installed client, a Java one is served automatically. I was surprised at how well ultravnc works for webcam images, even over ISDN. There are much better solutions, but considering how simple the installation is, there is a place for it as a quick fix.
OpenBSD is coming up to the second release with BGP support: "partial support for multiprotocol (only IPv4-unicast is announced)" for now, but it's certainly an active project.
Seconded... Since I have static IP but don't really want lookups being done over DSL, I've been using their secondary-only service, not listing my primary in the gtld-servers or NS records. Secondary is reasonably priced and working very nicely (support for bind notify or web-based reloads) - and of course in this case, as they're just doing a zone-transfer you can have whatever records you like. I used to use their more expensive web-based service which I was happy with too - I'd highly recommend easydns.
You might also find it interesting to read about other efforts for making small systems on other OS, amongst others flashboot, flashdist, MeshBox, Pebble Linux. You'll probably also learn a lot about this by examining how 'live-cd' software is prepared (e.g. livecd.sf.net, knoppix).
A lot of these techniques are aiming at small single-task embedded systems (often on minimal hardware, e.g. net4501/net4801), but the techniques are generally applicable, and can be used to make all types of system on various OS.
There are problems with using site-variable port numbers: it makes identifying traffic types a little tricky, having implications for e.g. traffic prioritisation, blocking malicious/unwanted traffic. As such it's probably more useful on a network within one administrative domain than on the internet. There's no corresponding method for looking up service types given a port number and IP address (e.g. additional records to in-addr.arpa) to help out, possibly because it would be rather difficult to place any degree of trust in that data anyway: you can't really have an unknown DNS server controlling your firewall policy. This is a bit of a different thing than MX records, where port numbers can't be defined.
For protocols already in common use, it would add delays and/or place more load on DNS in the changeover period (which is likely to be protracted). Other problems too. Someone types in example.com - what do you need to lookup? www.example.com A, example.com A, example.com SRV? What about sites where these are different - which address do you connect to? Then, do you send them off all at once (reduces delays in the common instance but has a tendency to increase delays overall)? How long do you wait for replies? - they could come back out of order. Or do you send them serially, which will add some delay to the majority of lookups, but is on-the-whole friendlier to the networks and DNS servers.A web browser vendor is unlikely to be particularly happy to add and default-enable a feature that adds to the time taken to resolve the majority of names - but realistically, you won't have very high takeup on the server side until most clients threaten not to connect unless it's done. For newer protocols it's simpler, since there often need be no fallback to A record, and indeed SRV records are being used on some newer protocols. Still, the traffic identification problem is still there.
Adding this to HTTP is a bit different than the case with adding MX to email: many more people will notice the increased time to resolve the name. With email, the delay is in the background, after the message has left the end-user's mail client and enters the transport system: it's almost invisible. With interactive requests such as HTTP, any delay is immediately obvious.
Since it doesn't really buy you anything you don't get from an address-translating device on the IP address of example.com, and given the complexities and problems it adds, who's going to use it?