Re: Calomel.org
On Thu, 2012-07-26 at 10:54 -0700, Eric Oyen wrote: well, I am wondering what packages I can use to edit man pages. The pages themselves are marked-up text; just use a text editor. Note that OpenBSD doesn't use groff anymore to render them. Look at mandoc(1) mdoc(7) (the suggested format) man(7) (the legacy format; you may run across it in older pages you're editing) As an example, here's mdoc(7) in its text format, via cvsweb: http://www.openbsd.org/cgi-bin/cvsweb/src/share/man/man7/mdoc.7?rev=1.93;content-type=text%2Fplain That's what you would be editing. Weldon Weldon
Re: Upgrading OpenBSD
On Mon, 2012-05-21 at 20:46 -0700, Richards, Toby wrote: With BSD I must rely on the package system. Funny, all this time I thought OpenBSD came with a compiler... WMG
Re: Openbsd 5.1 Review on Distrowatch
On Mon, 2012-05-14 at 16:48 -0400, Ralph Ellis wrote: You are quite right. I meant that the i386 version could access flash via linux emulation through Opera. This is no longer true. http://www.openbsd.org/cgi-bin/cvsweb/ports/www/opera-flashplugin/Attic/Makefile NB Kill it with fire. Newer versions of Flash run into thread-local storage problems (at least that's what they complain about when they crash). There are still various packages that provide some aspects of Flash (gecko-mediaplayer for movies, gnash for animations, etc.) and do not require emulation. Weldon
Re: a live cd/dvd?
On Fri, 2012-05-11 at 18:47 -0700, Eric Oyen wrote: hello everyone. I was thinking that if we had a live image (A full running system) with an installer, we could have easier installations for the blind (and others as well). Like this one? http://livecd-openbsd.sourceforge.net/ Or, if you want a USB stick, http://liveusb-openbsd.sourceforge.net/ He hasn't released a 5.1 version yet (it's usually a month or so behind the release), but there are instructions for doing so if you want one and have a 5.1 installation somewhere. Weldon
Re: OT: SSH not secure?
On Wed, 2012-05-09 at 11:53 -0400, S. Scott wrote: Good luck with your malicious administrator and the other 999,999 things you really need to be concerned about. It's more of the DAC silliness: you're not secure because you trust your systems administrator; I don't have to do that... (I just have to trust the person who administers the DAC rules). Note the money sentence at the end of the case study: Currently, the only secure way to use ssh or sftp on a UNIX/Linux machine to connect with mission critical server is using our AutoSSH and/or AutoSFTP: only our AutoSSH and AutoSFTP can detect truss/tusc/strace and dtrace attack, and detect Trojan Horse attack. Using AutoSSH and/or AutoSFTP with public/private key pair with pass phrase protection for the private key is the most secure way of connecting with mission critical servers Right... because AutoSFTP and AutoSSH do not allow an administrator to tamper with *them* at all? Weldon
Re: fw_update
On Wed, 2012-05-09 at 21:33 +0200, mark sullivan wrote: Hi everybody, I was coming to OpenBSD 5.1 looking for reasonable privacy and when I install it (amd64 flavour), I see that fw_update automatically installs propietary firmware without my permission. Actually even worse, it updates it automatically from the net! The parts affected are quite meaningful: the network card and the video card... I mean.. Should I request that you install propietary firmware for my sound card too so that everybody can record my voice too? I would like to hear your arguments on this and if there is a simple way to disable fw_update and uninstall in general everything propietary affecting the network card that I have not been warned about. I read on the FAQ that I should have been asked about this firmware but I wasnB4t! (amd64 cd installer). Thanks much, Mark This surprised me too, having been used to being asked when 5.1 was still -current. Note that if you don't set up a network interface during the install (or more to the point, don't initially boot with an /etc/hostname.$INTERFACE file), fw_update won't try to run. Weldon
Re: fw_update
On Wed, 2012-05-09 at 23:39 +0200, David Coppa wrote: What's the purpose of having a non-working wifi card? If you have concerns with firmwares, swap your card with, for example, an atheros or another card that doesn't need a firmware. And, btw, the other firmware is for a webcam (uvideo), not the video card... For me the issue was surprise (something I dislike in an installer); I was asked to confirm the download when 5.1 was -current and not asked when it was a release. I had assumed the reason for the confirmation was the license, but the note in the commit suggests it was because fw_update might be buggy. Also, while I recognize this is an edge case, I have in the past sold systems with OpenBSD installed on them to other people, and now that I come to think of it I have no idea whether that's legal to do with, say, iwn-firmware installed on it (it's probably not). Weldon
Re: kqemu in 5.1
On Mon, 2012-05-07 at 15:21 +0300, lilit-aibolit wrote: qemu-0.14.1p4.tgz and kqemu-1.3.0pre11p3.tgz in packages. is this not work? http://www.openbsd.org/cgi-bin/cvsweb/ports/emulators/kqemu/Attic/Makefile Also, it's not in packages for 5.1 (I think it got yanked after the freeze for 5.0, so it's still in 5.0, but doesn't work): ftp://ftp.openbsd.org/pub/OpenBSD/5.1/packages/i386/ kpoppassd-0.5p2.tgz kpovmodeller-3.5.10p6.tgz krb5-auth-dialog-3.2.1p1.tgz Qemu is still there, and still (slowly) works. Weldon
Re: acer aspire one D270
On Fri, 2012-05-04 at 19:26 -0400, Ted Unangst wrote: The only google hit for netbsd ignphy is... your email. ??? My mistake -- I was seeing igphy(4), which is for the ethernet, not the wireless. At any rate, the iwn(4) driver does not need Intel's firmware, and seems to work pretty well. Weldon
Re: kqemu in 5.1
On 05/04/12 06:12, Jes wrote: Hi all: I can't find kqemu between snapshots packages, ports, or even in 5.1 packages. I think I've read something about kqemu is deprecated in newer versions of qemu (1.0.1) Is this correct? Because performance without kqemu is horrible. Any solution? Yes, it was killed upstream since Linux now comes with its own hypervisor (KVM). AFAIK OpenBSD currently does not have a working hypervisor since it also can't be dom0 on xen until such time as xen stops randomly overwriting register contents at unpredictable times. So, as of now, any virtualization will have to be of the plain qemu or bochs variety. Sorry. Best, Weldon
Re: acer aspire one D270
On Fri, 2012-05-04 at 07:37 +0100, Laurence Rochfort wrote: I wouldn't recommend the iwn(4) devices. I've had a bad experience even with those in the man page. YMMV; I've had good results with the 4965 AGN. Of note: NetBSD 6 (in beta) has a new largely-non-Damien driver with its own PHY (ignphy(4), IIRC) and no need for Intel's firmware. Might be worth looking at. Weldon
Re: Why so old firefox in 5.1?
On Fri, 2012-05-04 at 11:43 -0300, Jeronimo Baldino wrote: Is the development cycle the cause of older firefox in packages? But firefox isn't shipped with core OS. No, but binary packages are built against the core OS as shipped, so the ports people try to approach something like stability every six months. Firefox in particular has had -current a few versions ahead of -release for, I don't know, several years now at least. And, as mentioned before, we have more architectures than i386 to think about here. If you just want a more recent browser, Chromium is at 18.0.1025.162, which is ahead of Debian Testing, even (go team!). Weldon
Re: acer aspire one D270
On Fri, 2012-05-04 at 19:26 -0400, Ted Unangst wrote: The only google hit for netbsd ignphy is... your email. ??? I may have misremembered the name of the PHY, but iwn(4) in NetBSD 6.0-BETA does produce a PHY named something and doesn't require Intel's firmware to run. Though this may also be NetBSD's frustrating slowness to actually document Beta releases. I'll boot up again when I get home and let you know the PHY name. Weldon
Re: kqemu in 5.1
On Sat, 2012-05-05 at 14:02 +1000, Peter Ericson wrote: Could there be a KVM for OpenBSD? I have been wondering for a while if the answer is an absolute no because it could never be trustworthy enough, not likely to happen because of lack of interest, or somewhere in between. There certainly could be, but someone would have to program it. WMG
Re: Please send email directly to misc@openBSD.org (no cc please)
On Fri, 2007-11-16 at 00:28 -0500, Piet Slaghekke wrote: I like to filter my openBSD emails and the only way I can do it is if everyone send their email with misc@openBSD.org in the To field. Please send email To misc@openBSD.org and do not CC it to this address. Thanks! If only there were mail clients that allowed one to filter on To: or Cc:...
Re: bcw(4) is gone
Would it be wrong to develop software using existing GPL'ed code as a starting point. And bit by bit rewrite the code until you have rewritten all of it. Then releasing the final code under an BSD license? *shrug* Personally I consider that a derivative work and try to avoid it, though practically if your rewrite is different enough nobody would ever know. Maybe this is the other side of the blob fight; we should be just as eager to make sure there is no improperly-copied GPL (or APL or MPL or...) code in the tree as we are to make sure there are no mysterious hunks of binary code (why exactly these issues always seem to come to a head about wireless drivers as opposed to other parts of the tree is beyond me -- Intel never requires its sound or ethernet controllers to have non-freely-redistributable firmware). IMO this is a vindication of the principle that being a jerk doesn't necessarily make you wrong: Michael should have handled this differently (especially given the state of the driver at the time), but he does have a responsibility to protect his license. It seems to be a big concern to him that the hardware vendor not be able to use his software, so the GPL is the correct license for his work. I have trouble imagining a situation where I wouldn't want a hardware vendor to use my code if it worked better, but he's the author so it's his decision to make. Weldon [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Re: bcw(4) is gone
On Fri, 2007-04-06 at 10:22 -0400, [EMAIL PROTECTED] wrote: They stated that they don't want Broadcom to take their work and close it. Why do they care? What possible difference does it make? Broadcom will get a driver that actually works well? What do you care if that's what they care about? Don't forget that the desire to keep proprietary vendors from forking and re-closing code was precisely and explicitly the reason the GPL was written; someone who values that is probably going to choose the GPL to release their work under. Complaining that Developer X chooses to use the GPL is as useless as complaining that Vendor Y chooses not to release source code at all. In both cases it's a license that is at odds with the purpose and principles of OpenBSD, and in both cases it's a violation of those authors' rights to copy their code in a manner they have not licensed you to. I'm not trying to come across as some sort of GPL cheerleader. I don't use it except when contracts stipulate it (and more do than you might think, given your they can't make money statement) and I think this situation is a good example of why the GPL bad for code trees with multiple authors (which is going to be any code tree of significant complexity that accepts patches). If one guy writes something and chooses to place it under the GPL, he can then relicense in a situation like this; if there end up being 40 authors of a module it's impractical to track every one of them down if they haven't handed their copyright over to a primary maintainer, especially if all you really know about somebody is their public key and email address 3 years ago when they committed last. But all those complaints don't mean anything at all: I wasn't an author for the Linux driver so I don't get a say in how the Linux driver is licensed. The people who did the work to write it get to decide under what terms it can be redistributed, and once they have decided that they have a responsibility to see it is enforced. They don't have to CC hundreds of people on their first mailing like this guy did, but then again they have a right to do so if they want to. Just like I have a right to think they're jerks for doing that. Weldon [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
General question about intl and iconv
(This might belong on ports, but it's not specific really) There are quite a few software packages not in the ports tree that I've managed to wrestle into running on my system, and I keep noticing the same thing: they all have trouble with libintl and libiconv. But it's always different things: some are missing certain symbols, some just can't seem to find the version, some (even with the include and link paths double-checked) can't find iconv.h or libintl.h, or libiconv and libintl, without editing the source file to look for the absolute path. What's going on here? Are OpenBSD's i18n libraries that radically different? I could understand if it was just the missing symbols (ie, obsd didn't implement all the functions) or just the version problems (ie, obsd used a different versioning scheme), but I can't fathom why applications can't find those headers, of all the rest that they use, and why all three happen, and have kept happening for me across 3.7, 3.8, and 3.9. Is there a system configuration I've missed somewhere, like sysctl usr.i18n.play_well_with_others 1 or something? And then it strikes me that my joke is even dumber than it sounds, since intl and iconv (via gettext) are ports. It's curious to me that gettext isn't included with the rest of the GNU toolchain in the system, but then I guess it's not necessary for all users. Anyways, if somebody knows a magic bullet to make iconv and intl play well with others, or can just enlighten me on what's so different with OpenBSD's versions as opposed to everyone else's, I'd really appreciate it. Thanks! Weldon Goree
Re: sensorsd configuration
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Daniel A. Ramaley wrote:
The lines in sensorsd.conf start with hw.sensors.N (where N is a small
natural number). How do i determine N for each sensor? Is there a list
somewhere that tells what is what? Or is there a command i can run to
generate a list?
`sysctl hw.sensors` will show you the list of all the sensors and their
appropriate number (and current value). As I found out a couple of days
ago, sysctl(8) does this by just trying all possible N's for 1 to 256
and then checks what each sensor is. AFAICT, that's the only facility
the kernel offers to find them.
Secondly, is it possible to read the current values of sensors? For
example, say i have configured a sensor to monitor the CPU temperature.
Is there a way to find out what the current temperature is?
sysctl(8), again. If CPU temp is hw.sensors.4, then sysctl hw.sensors.4
will tell you. Sensorsd is more for watching for threshholds and
boundary readings, rather than a real-time display of the current reading.
If you're programming, you can also use sysctl(3); it would be something
like sysctl({CTL_HW, HW_SENSORS, 4}, 3, some_allocated_buffer,
length_of_that_buffer, NULL, 0);
some_allocated_buffer will then hold the struct sensor containing its
current state.
Weldon Goree
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFEtnuvixcispFzVm8RAttkAJ95eFTvJaaqn4R1Tkf1Kpo9c1KtuwCfS5aG
0ET6NQe4/KoC6iUw2w6qipk=
=PTNG
-END PGP SIGNATURE-
Re: No Java in OpenBSD
Karel Kulhavy wrote: I appreciate there is no Java in OpenBSD. I searched for java, jre, jdk, j2se, sun, blackdown and ibm in the packages and didn't find anything. /usr/ports/devel/jdk subpackages are 1.3-linux (requires linux emulation; this one is needed to boot strap the others), 1.3, 1.4, and 1.5. Flavors do include native_bootstrap, but to be honest I have no idea what that does because building that flavor still required 1.3-linux. Building it is something of a pain because Sun won't let 3rd parties like the ports system fetch the files. You have to grab the Linux binary, then the SCSL source, then a patchset for it (whose maintainer, apparently, also doesn't let 3rd parties fetch it), then the SCSL binaries, all of which involve separate license agreements *and* an account on Sun's website whose password I can never seem to remember. And you have to grab the correct version of the binaries, sources, and patchsets, which are not at this moment the latest versions of them. This, incidentally, is why non-free software is a PITA. At any rate, it works fine for me; applets run in the native mozilla, aqua data studio runs great, etc. So, yes, unfortunately, OpenBSD can run horribly-written, slow, and buggy Java applications like any other OS. I guess file a bug report to have it removed... Weldon
Re: sysctl(3) and iteration over HW_SENSORS
Constantine A. Murenin wrote: You can't get them all at once with one sysctl(3) call, as the memory they occupy is not allocated continuously -- a linked list is used, and each driver does sensor allocation on its own, and it's not a sysctl(3) job to merge this linked list together into an array. Ah, thanks. From that perspective I can see that the use of the term array in the sysctl(3) man page under HW_SENSORS doesn't necessarily mean a literal array being written in the *oldp buffer; I hope the confusion was at least understandable, though. According to the source, `/sbin/sysctl hw.sensors` calls its own main parsing routine 256 times to check each of the 256 possible sensors and allocates its own list from the results. Eek. Since I'm just writing a voltage monitor I suppose I could have it do that once on init and then just monitor the specific sensors it finds relevant, assuming I can convince myself that the numbers are assigned once at bootup (or at least do not change once assigned). Thanks again, Weldon
sysctl(3) and iteration over HW_SENSORS
sysctl(3) says that sysctl({CTL_HW, HW_SENSORS}, 2, NULL, some_size_t,
NULL, 0) should give me the size of the array of struct sensor's that
sysctl({CTL_HW, HW_SENSORS}, 2, some_buffer, length_thereof, NULL, 0)
will put into some_buffer.
Or so I thought. In fact, it returns -1 and sets errno to ENOTDIR, which
it then diagnoses as my specifying a non-terminal MIB. sysctl(1) shows
me that I have 7 hw.sensors, but obviously that is a variable among
systems; how am I supposed to find the number of struct sensor's that
the buffer must hold? And how do I get all of them at once like (I
think) sysctl(3) says I can? Should I just run sysctl({CTL_HW,
HW_SENSORS, i}, 3 ...) for increasing values of i until it returns -1?
TIA,
Weldon
