Solid State Disk
Many thanks to all, I try to upgrade my system, also because if I increase block size with dd tool, the performances worsen further :-( Bye!!!
Re: Why Perl for pkg_* tools ?
On Fri, May 23, 2008 at 08:20:50PM -0400, Hugo Villeneuve wrote: perl offers faster software development. perl is not fast. Just saying. Althought, I think that's what you meant too. # sysctl hw.model hw.physmem hw.model=SUNW,SPARCclassic, TMS390S10 @ 50 MHz, on-chip FPU hw.physmem=24801280 # time pkg_info gettext-0.16.1 GNU gettext libiconv-1.9.2p5character set conversion library lrzsz-0.12.20p0 receive/send files via X/Y/ZMODEM protocol mutt-1.4.2.3tty-based e-mail client stunnel-4.20SSL encryption wrapper for standard network daemons uucp-1.07p2 UUCP suite 0m22.57s real 0m13.05s user 0m6.44s system 22 seconds to list one folder and open 6 files :) I doubt it took 1 seconds before the move to perl on that computer. You're partly confusing start-up time and speed. In less trivial tasks than pkg_info, for instance actual use of pkg_add, the new tools are faster. Most run-times are dominated by IO. The old tools were using external tar(1) to a temporary area, then copying over to the final destination. That makes for double IO, and thus very slow. Replacing that in the old tools would not have been feasible. Likewise, the new tools do not spend all their time re-discovering the world. If you pkg_add *.tgz, you run one instance of pkg_add which keeps every info it needs in memory (and I spent some time specifically improving that so that, even with all the checks being done, pkg_add can handle 1000s of packages before overflowing 64M). pkg_info time was similarly improved when we finally merged +COMMENT into +CONTENT, so that less files got opened and read. pkg_info on an installation with few packages installed is the odd case where it is noticeably slower. Seriously, the advantages far outweigh the problem. It's been my experience that a language such as perl allows you to deploy much faster algorithms in the same amount of time it will take to code the same problem in C. The rapid application development facilities by themselves are tremendous. It's ways simpler to tune things so that they run circle around their C counterparts. Happened with pkg_add, happened with makewhatis. And I ran the benches to check it. Of course you won't be able to run old pkg_* with our new pkg tools, the new ones do so much more. But on sheer pkg extraction, the new tools win by a factor or 2.
Re: Issues with OpenBSD 3.7 and ftp-proxy
Eric LeBlanc [EMAIL PROTECTED] writes: # uname -aOpenBSD boo.org 3.7 GENERIC#50 i386== I would not be surprised if you're the only one left out there running that particular version. If you upgrade to something more recent, ie OpenBSD 4.3, you will get a lot more useful responses simply because it will be a lot easier for others to reproduce your configuration. Don't forget either that the modern ftp-proxy is a completely different animal from the one in OpenBSD 3.7. That said, I vaguely remember having a similar problem (LIST failing on some, but not all ftp servers) around 3.7-time. It's very likely that was a bug that has now been fixed. - P -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: Issues with OpenBSD 3.7 and ftp-proxy
On 2008-05-24, Eric LeBlanc [EMAIL PROTECTED] wrote: # uname -aOpenBSD boo.org 3.7 GENERIC#50 i386== ftp-proxy is dealt with in the faq, but you need an old version for your outdated OS version: http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/www/faq/pf/ftp.html?rev=1.18content-type=text/html However, there have been enough DoS and security fixes since 3.7 that you shouldn't be running it any more. Please upgrade.
Re: Why Perl for pkg_* tools ?
Hi, What about python? I think that it's license is better (but i might be wrong). Cheers.
Re: Why Perl for pkg_* tools ?
comfooc ha scritto: Hi, What about python? I think that it's license is better (but i might be wrong). Cheers. Please... Read all threads before writing Developers make choices... Marc choice perl stop. Perl is in base and he know perl, so for a silly sillogism, Marc use perl for pkg_* It's clear now? Holy shit!
Re: Why Perl for pkg_* tools ?
2008/5/24 comfooc [EMAIL PROTECTED]: Hi, What about python? I think that it's license is better (but i might be wrong). What about reading the entire thread? http://marc.info/?l=openbsd-miscm=121155084515533w=2 -- We spend the first twelve months of our children's lives teaching them to walk and talk and the next twelve telling them to sit down and shut up.
Re: [OT] developers running -current on laptops
On Fri, May 23, 2008 at 1:29 PM, Jacob Yocom-Piatt [EMAIL PROTECTED] wrote: Chris wrote: I can see from the recent undeadly posts and pictures that most developers are using laptops and I know you have to run -current to do development work. I was just wondering if these laptops are for development use only or development+personal use? I know -current can break sometimes and am just curious to know if developers risk putting personal stuff on a laptop that is being used for active development. a more general rule for information on computers: if it is important, it should be backed up a good test to see if changes in -current 'break' your system is to boot the new kernel with the old userland to check if it works. this assumes you're going from one snapshot to another, and is by no means a foolproof technique. [...] I have been running -current since I started OpenBSD on my laptop about an year ago. And not a single time I faced any instability/failure. I also build the kernel, userland, and X once a week. Though I don't actively develop OpenBSD, I do have my entire official work on it. Which pretty much means I am hosed if things go wrong. But hey, I do also take nightly backups on my critical data - /etc, /home (though reading the thread I understood that I also need to backup /var. Thanks Chris), and religiously follow http://www.openbsd.org/faq/current.html -Amarendra -- Pune, INDIA.
intermediate email host setup help
Hi, I would like some help to setup an environment which could be used in most xDSL clients. These clients normally host their real DNS and email at some place like dreamhost. I would like to bring via pop3 these emails (for each user) and then do some filtering (spam, virus, etc.) and host them locally. A user in the client's network would then point to my host to retrieve his email messages. Has anyone worked on a setup like this before? Is it at all doable? What tools would be suited for this task? Thanks for any help. Regards, Jose -- See Exclusive Video: 10th Annual Young Hollywood Awards http://www.hollywoodlife.net/younghollywoodawards2008/
OpenBSD and VIA VT6105M RhineIII
hello, we have huge problems with the new soekris and pcengines boards vith the VIA VT6105M RhineIII network chipset and OpenBSD. no machine is able to establish a tunnel to another IPsec peer. we worked for years with the pcengines WRAP boards - the had no problem. below is a trace of the tunnel establishment with a normal pc hardware with fxp interfaces - everything works fine. the other picture shows a trace of a board with VIA chipset with vr interfaces and the exacty same configuration (isakmpd.conf and IP adresses) - you can see that there must be a problem with the tunnel establishment - it is definitely NOT caused by packet loss. unfortunately the phase I and phase II communication is completely encrypted, so there is only low chance to discover a bug but at least the headers and all checksums are correct ... has anyone discovered similar problems with OpenBSD and the VIA chipset or other possible positive experiences ? thanks in advance for a feedback regards arno hechenberger citydata trace: machine with vr interfaces No. TimeSourceDestination Protocol Info 1 0.00194.208.37.21 194.208.33.217ISAKMP Identity Protection (Main Mode) 2 0.058193194.208.33.217194.208.37.21 ISAKMP Identity Protection (Main Mode) 3 0.150492194.208.37.21 194.208.33.217ISAKMP Identity Protection (Main Mode) 4 0.208460194.208.33.217194.208.37.21 ISAKMP Identity Protection (Main Mode) 5 0.304038194.208.37.21 194.208.33.217ISAKMP Identity Protection (Main Mode) 6 0.358672194.208.33.217194.208.37.21 ISAKMP Identity Protection (Main Mode) 7 0.437001194.208.37.21 194.208.33.217ISAKMP Quick Mode 8 0.469804194.208.33.217194.208.37.21 ISAKMP Identity Protection (Main Mode) 9 0.483476194.208.33.217194.208.37.21 ISAKMP Quick Mode 10 0.494387194.208.37.21 194.208.33.217ISAKMP Quick Mode trace: machine with fxp interfaces No. TimeSourceDestination Protocol Info 1 0.00194.208.37.21 194.208.33.217ISAKMP Identity Protection (Main Mode) 2 0.055112194.208.33.217194.208.37.21 ISAKMP Identity Protection (Main Mode) 3 0.089738194.208.37.21 194.208.33.217ISAKMP Identity Protection (Main Mode) 4 0.135278194.208.33.217194.208.37.21 ISAKMP Identity Protection (Main Mode) 5 0.147892194.208.37.21 194.208.33.217ISAKMP Identity Protection (Main Mode) 6 0.199866194.208.33.217194.208.37.21 ISAKMP Identity Protection (Main Mode) 7 0.211054194.208.37.21 194.208.33.217ISAKMP Quick Mode 8 0.285228194.208.33.217194.208.37.21 ISAKMP Quick Mode 9 0.286238194.208.37.21 194.208.33.217ISAKMP Quick Mode 10 26.826381 194.208.37.21 194.208.33.217ESP ESP (SPI=0xfb95abfa) 11 26.906322 194.208.33.217194.208.37.21 ESP ESP (SPI=0x0f34b701) 12 27.836780 194.208.37.21 194.208.33.217ESP ESP (SPI=0xfb95abfa) 13 27.876157 194.208.33.217194.208.37.21 ESP ESP (SPI=0x0f34b701) 14 28.840978 194.208.37.21 194.208.33.217ESP ESP (SPI=0xfb95abfa) 15 28.886188 194.208.33.217194.208.37.21 ESP ESP (SPI=0x0f34b701) 16 29.857408 194.208.37.21 194.208.33.217ESP ESP (SPI=0xfb95abfa) 17 29.901540 194.208.33.217194.208.37.21 ESP ESP (SPI=0x0f34b701) demesg: OpenBSD 4.3 (GENERIC) #698: Wed Mar 12 11:07:05 MDT 2008 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC RTC BIOS diagnostic error 80clock_battery cpu0: Geode(TM) Integrated Processor by AMD PCS (AuthenticAMD 586-class) 432 MHz cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX real mem = 133791744 (127MB) avail mem = 121331712 (115MB) RTC BIOS diagnostic error 80clock_battery mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 12/10/07, BIOS32 rev. 0 @ 0xfceb2 pcibios0 at bios0: rev 2.1 @ 0xf/0x1 pcibios0: pcibios_get_intr_routing - function not supported pcibios0: PCI IRQ Routing information unavailable. pcibios0: PCI bus #0 is the last bus bios0: ROM list: 0xe/0xa800 cpu0 at mainbus0 pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 1 function 0 AMD Geode LX rev 0x33 glxsb0 at pci0 dev 1 function 2 AMD Geode LX Crypto rev 0x00: RNG AES vr0 at pci0 dev 9 function 0 VIA VT6105M RhineIII rev 0x96: irq 10, address 00:0d:b9:14:09:a0 ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 vr1 at pci0 dev 10 function 0 VIA VT6105M
Re: E450 stuff
Johan SANCHEZ wrote: On Fri, 23 May 2008 11:08:32 -0400 Christopher Sean Hilton [EMAIL PROTECTED] wrote: On May 23, 2008, at 11:06 AM, Christopher Sean Hilton wrote: Hi, I inherited an E450 from my old job. It booted Solaris just fine but I was never able to get any of (Free|Net|Open)BSD to install on it. I feel that this is probably more do to me than anything else. As time has passed it's become pretty obvious between the problems with the install and the cost for power to run, my chances of running this machine in my environment are NULL. I'd like to make just one more attempt at getting the machine running. But ultimately I will have it carted away. This is what I have: Sun E450 4 x 400 MHz UltraSparc II processors (Sun P/N 501-5446) 4 x DC power regulator boards (Sun P/N 300-1322) 4GB of RAM (16 x Sun P/N 501-4743) Spare E450 Mainboard 2 x 300 MHz UltraSparc II processors (Sun P/N 501-4849) 2 x DC power regulator boards (Sun P/N 300-1322) 4GB of RAM (16 x Sun P/N 501-4743) I'm going to spend an hour today working on this to see if I can get a working install but even if I do the whole things going to have to go away. If anyone is interested in any of this equipment please feel free to email or xmpp me ([EMAIL PROTECTED]) Can i ask what is the problem you are experiencing with this ? what version of OBP are you using and what OBSD version did you tried ? Johan I do believe you will find OpenBSD will Just Work, and bsd.mp should spin up all four processors. I seem to recall there was some work done relatively recently on the sensors on an E450, and one usually has to be fully functional on a system before you worry much about the sensors. :) HOWEVER... IF you have only worked with PCs, Sun systems are different. Also, the average E450 has sucked a lot of dust through its CDROM drive, and functional SCSI CDROM drives are relatively rare in most people's spare parts pile. Fortunately, Suns offer a lot of other options for bootstrapping the system, but none of the rest are something the average PC user has ever done before. But man, E450s are big. But I'm sure you have noticed that. :) Nick.
is it possible to install matlab2008 on openbsd ?
hi all: i've installed the fedora_base and turned on linux emulation in the sysclt.conf and i've mounted my matlab disk but when i run install i get: Sorry ! We could not determine the machine architecture for your host You may be attempting to install on an unsupported OS Is there anything we could do ? Thanks
SPARC64-V support
As of yesterday, OpenBSD/sparc64 has full support for Fujitsu's SPARC64-V processor. As far as I know OpenBSD is the first free operating system that supports this processor. These processors are found in Fujitsu's PRIMEPOWER machines. The work was done on a PRIMEPOWER 250, so that model is known to work. This almost certainly means the PRIMEPOWER 450 works fine too. And there is no real reason why other models shouldn't work too. So if you have one of these machines, it would be great if you could try booting OpenBSD and send a dmesg. Make sure you grab a snapshot dated May 23 or later. Even if you have no opportunity to boot OpenBSD on your PRIMEPOWER there still is a way to help. I'm looking for the output of the 'prtconf -pv' command for these machines. I'd also love to receive that information for the SPARC Enterprise M4000/M5000/M8000/M9000 as well as any older Fujitsu SPARC64-based machines. Thanks, Mark
Re: is it possible to install matlab2008 on openbsd ?
On Sat, 24 May 2008, elflord woods wrote: hi all: i've installed the fedora_base and turned on linux emulation in the sysclt.conf and i've mounted my matlab disk but when i run install i get: Sorry ! We could not determine the machine architecture for your host You may be attempting to install on an unsupported OS Is there anything we could do ? Try this: http://www.csl.cornell.edu/~rajit/fbsd/matlab.html Thanks -- Floor Terra [EMAIL PROTECTED] www: http://brobding.mine.nu/ Netiquette Guidelines: http://www.apps.ietf.org/rfc/rfc1855.html
Re: SPARC64-V support
here Sun SPARC Enterprise M9000 's prtconf -pv infomation. http://www.sun.com/bigadmin/hcl/data/systems/prtconf/2541.txt Sun's Sparc Server's information site is the http://www.sun.com/bigadmin/hcl/data/sol/systems/views/sun_systems_sparc.page1.html yet, couldn't find a PRIMEPOWER machines prtconf information. thanks - Jung
Re: Why Perl for pkg_* tools ?
Sorry, but I've clearly misphrased my question and might be a little offtopic. I should ask if python has better license than perl from OpenBSD perspective. Once again sorry. Cheers.
Re: E450 stuff
On Sat, May 24, 2008 at 8:03 AM, Nick Holland [EMAIL PROTECTED] wrote: But man, E450s are big. But I'm sure you have noticed that. :) With lots of NON-LOAD-BEARING stickers all over the power supply handles. As a friend of a friend found out. When I moved last year, I tossed it out. 1KW power... man, that sucked a lot of juice. Other than because I can, I'm not really sure what use is a e450, it's a what, 8-10 year old box now. I went through and thought about what I wanted/needed, and threw away the sgi, the hpux, the decstation 3k and 5k, every box under 400Mhz, with one exception, my Apple ][gs. 15 computers, trashed. -- http://www.glumbert.com/media/shift http://www.youtube.com/watch?v=tGvHNNOLnCk This officer's men seem to follow him merely out of idle curiosity. -- Sandhurst officer cadet evaluation. Securing an environment of Windows platforms from abuse - external or internal - is akin to trying to install sprinklers in a fireworks factory where smoking on the job is permitted. -- Gene Spafford learn french: http://www.youtube.com/watch?v=j1G-3laJJP0feature=related
Re: Why Perl for pkg_* tools ?
comfooc == comfooc [EMAIL PROTECTED] writes: comfooc Sorry, but I've clearly misphrased my question and might be a little comfooc offtopic. I should ask if python has better license than perl from comfooc OpenBSD perspective. If you're serious, the answer is no. They're roughly equivalent. But your question is moot, since that's not what pkg_* is written in. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
[OT] Python License [WAS: Re: Why Perl for pkg_* tools ?]
Hello, How about the python license? Not that I'm really capable of rewriting and/or patching the pkg_* tools but from a license point of view I think that the license under which python is distributed is quite similiar to a BSD license. Especiall this: GPL-compatible doesn't mean that we're distributing Python under the GPL. All Python licenses, unlike the GPL, let you distribute a modified version without making your changes open source. The GPL-compatible licenses make it possible to combine Python with other software that is released under the GPL; the others don't. as a footnote in the license makes me think that way. Given that is there any chance realistic chance that python will be part of the obsd default at some point in the forseeable future? In any case is it missing auditing, general interest (or any other point I can't think of right now). Personally I'd really like to see python being included in obsd base License is here: http://www.python.org/download/releases/2.5/license/ http://www.python.org/download/releases/version/license/ It's probably, as with all languages, just personal favor, but mine goes in the direction of python :) /martin On Thu, May 22, 2008 at 5:23 PM, hyjial [EMAIL PROTECTED] wrote: Hi list ! Reading through OpenBSD's codebase, I have noticed that the code living under src/usr.sbin/pkg_add is written in Perl. Perl is distributed under the Artistic license, though. The latter is not as permissive as the BSD license under which monst of OpenBSD is released. No doubt that is the reason why Perl lives in src/gnu. Why have such a tool using a non-BSD package when there was choice not to do so ? What technical reasons have lead the developers to elect this language ? I am just curious about the fact and didn't manage to find information in tech@ and mis@ archives. Thanks in advance. Hyjial. -- http://www.xing.com/profile/Martin_Marcher You are not free to read this message, by doing so, you have violated my licence and are required to urinate publicly. Thank you.
Re: [OT] Python License [WAS: Re: Why Perl for pkg_* tools ?]
Martin Marcher wrote: License is here: http://www.python.org/download/releases/2.5/license/ http://www.python.org/download/releases/version/license/ Yeah, that's exactly like the BSD license, elegant and simple.
Re: [OT] Python License
Martin == Martin Marcher [EMAIL PROTECTED] writes: Martin How about the python license? Not that I'm really capable of rewriting Martin and/or patching the pkg_* tools but from a license point of view I Martin think that the license under which python is distributed is quite Martin similiar to a BSD license. Especiall this: And what makes you think that is *closer* to the BSD license than Perl's Artistic 2.0 license, which says essentially the same thing? Or even the classic Artistic 1 license, which was even more do nearly whatever you want, with less legalese? -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
Re: is it possible to install matlab2008 on openbsd ?
Floor Terra wrote: On Sat, 24 May 2008, elflord woods wrote: hi all: i've installed the fedora_base and turned on linux emulation in the sysclt.conf and i've mounted my matlab disk but when i run install i get: Sorry ! We could not determine the machine architecture for your host You may be attempting to install on an unsupported OS Is there anything we could do ? Try this: http://www.csl.cornell.edu/~rajit/fbsd/matlab.html Those instructions are for FreeBSD not for OpenBSD. There is a whole chapter in FreeBSD Handbook http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/linuxemu.html about installing Maple, MatLab, and Mathematica. I do not believe that those instructions work any more even for FreeBSD 7.0 and the newest versions of above programs. There were couple of threads (I think two) recently on misc about installing Maple on OpenBSD. I am not sure if they can help you install MatLab but is worth of trying. Best, Predrag Thanks
how to fire up an intel wireless card ipw0 on lenovo thinkpad x31?
hi all my tp x31 is well supported by the beloved openbsd according to http://www.openbsd.org/i386-laptop.html and in my dmesg i see that my card is recognized but the light indicator for wireless connection can not be turned on I've tried dhclient ipw0 no luck neither do i need some kind of firmware to get it working ? what does it mean by firmware and how do i go about to install it? btw; what are the usual commands for configuring a wireless card ? can someone kindly type some examples please ? for example: what commands give a list of available wireless connections ? and what command let me choose one of these ? etc my school offers a wireless connection without any passwords and stuff so all i need is the most basic config many thanks in advance
Re: [OT] Python License [WAS: Re: Why Perl for pkg_* tools ?]
On Sat, May 24, 2008 at 06:23:23PM +0200, Martin Marcher wrote: Hello, How about the python license? Not that I'm really capable of rewriting and/or patching the pkg_* tools but from a license point of view I think that the license under which python is distributed is quite similiar to a BSD license. Especiall this: So is Perl's artistic licence. gnu/ is a historic accident. It's actually a shorthand for `not bsd' in our tree. Read the Artistic licence, there's nothing that conflicts with the overall goals of OpenBSD. Technically, the Artistic Licence gives you the same rights as a BSD licence. The only thing it prevents you to do is to misrepresent the original software: if you change it, you have to display it prominently, and you can't use the exact same name. Wooo, big infringement on your liberty. Now, compare to the obnoxious GPLv2, or the even more stinky GPLv3. Not the same ballpark. It's a bit like comparing Jimmy Carter to Adolf Hitler. So, let's invoke Godwin's law and close that useless discussion.
Re: how to fire up an intel wireless card ipw0 on lenovo thinkpad x31?
On Sat, May 24, 2008 at 06:51:13PM +0200, elflord woods wrote: hi all my tp x31 is well supported by the beloved openbsd according to http://www.openbsd.org/i386-laptop.html and in my dmesg i see that my card is recognized but the light indicator for wireless connection can not be turned on I've tried dhclient ipw0 no luck neither do i need some kind of firmware to get it working ? what does it mean by firmware and how do i go about to install it? btw; what are the usual commands for configuring a wireless card ? can someone kindly type some examples please ? for example: what commands give a list of available wireless connections ? and what command let me choose one of these ? etc my school offers a wireless connection without any passwords and stuff so all i need is the most basic config many thanks in advance If you look in the man page for ipw you will see a link to the firmware you need to install, you can simple run pkg_add http://... and reboot, in this man page there will also be examples on how to connect to an access point as well. -- James Turner BSD Group Consulting http://www.bsdgroup.org
Re: Why Perl for pkg_* tools ?
A final word. For all you backseat drivers: this is OpenBSD. Those who do the work get to call the shots. I did get permission from my fellow developers to switch our pkg_* to perl once I made a strong enough argument. A huge part of the argument was the actual code. I did write tools that work. I did write an infrastructure that still grows, stays coherent, and is still fairly easy to manage. These pkg_* are the first in the BSD world to actually support safe updates, without needing to back up most of your system first. Everything-in-perl was a deliberate design decision. What do you think ? that we grow code in a vat with eyes closed ? I've looked very closely at the neighbors, and at our distant cousins. The neighbors manage to live on a weird mix of awk/ruby/perl/python/sh/C. From a distance, it looks like everyone in NetBSD/FreeBSD has their own favorite language, and is happy to reinvent a square wheel to handle packages in their own language. Well, my tools were written specifically to squash that, to give people a cool enough interface that they would not need to reinvent the world. You prefer python ? tough cookies. Perl and python are more or less equivalent. If you know one, you can write code in the other. Or you're less elite than you think (as a sidenote, I loathe php, yet I run a drupal site, and I have written numerous patches for drupal). The only important difference, for me, was that perl comes with the base install in OpenBSD. And we made a conscious decision to keep it so. That gives us *one* decent high-level script language. OS and distributions are all about editorial choices. Some have given up, and let the user wadle through hundreds of inane choice and a bazaar of half-finished toys. OpenBSD takes some strong stances. We wanted pkg_* that work, we got them. You don't like that they're in perl ? you can always go elsewhere, or, if you have some real balls, write something better in whatever language you want. Have fun, good luck.
Re: Ethernet card or PCI Express x8 slot
On Fri, May 16, 2008 at 05:40:10PM -0700, David Newman wrote: Any recommendations for an Ethernet card that fits into a PCI Express x8 slot? I didn't see anything specific on the hardware page or in the archives. This is for a Dell CR100 OEM server. The spec sheet mentions the usual two Broadcom gigabit Ethernet interfaces, plus a PCI Express x8 (1-lane) slot. I'm not familiar with this slot, but it's much shorter than other PCI slots I've seen, around 50 mm long. If I'm reading the riser card correctly, the slot has 98 pins. None of the relatively old Ethernet NICs I have lying around will fit in this slot. Speed is unimportant; this is just for carp and pfsync between a pair of these boxes. This slot is a PCI Express bus and is different than a PCI bus. Look on Wikipedia for a good comparision. PCI is a paralell bus while PCI-e is a serial point-to-point bus. Or is this a PCI-X bus? Different again. I don't know what card to suggest for you. Doug.
Re: E450 stuff
On Sat, May 24, 2008 at 12:17 PM, Steve Shockley [EMAIL PROTECTED] wrote: bofh wrote: every box under 400Mhz, with one exception, my Apple ][gs. Man, what speed was that IIgs? I had put an accelerator in the box, so it's a speedy 7Mhz, as opposed to the standard 2.8Mhz or the slow - selectable for compatibility with //e and //c software - 1Mhz. I even had unix on it - GNO/ME. Unfortunately I couldn't win a DSW, GNO/ME didn't have /dev/zero. There was a DSW seeing how long it'll take your slowest system to do something along the lines of % time dd if=/dev/zero of=/dev/null count=100 -- http://www.glumbert.com/media/shift http://www.youtube.com/watch?v=tGvHNNOLnCk This officer's men seem to follow him merely out of idle curiosity. -- Sandhurst officer cadet evaluation. Securing an environment of Windows platforms from abuse - external or internal - is akin to trying to install sprinklers in a fireworks factory where smoking on the job is permitted. -- Gene Spafford learn french: http://www.youtube.com/watch?v=j1G-3laJJP0feature=related
Re: [OT] Python License [WAS: Re: Why Perl for pkg_* tools ?]
* Martin Marcher wrote: Hello, How about the python license? Not that I'm really capable of rewriting and/or patching the pkg_* tools but from a license point of view I think that the license under which python is distributed is quite similiar to a BSD license. Especiall this: do you really think anybody will rewrite the pg_tools using any other language? get a break, get a kit-kat. GPL-compatible doesn't mean that we're distributing Python under the GPL. All Python licenses, unlike the GPL, let you distribute a modified version without making your changes open source. The GPL-compatible licenses make it possible to combine Python with other software that is released under the GPL; the others don't. as a footnote in the license makes me think that way. Given that is there any chance realistic chance that python will be part of the obsd default at some point in the forseeable future? In any case is it missing auditing, general interest (or any other point I can't think of right now). Personally I'd really like to see python being included in obsd base License is here: http://www.python.org/download/releases/2.5/license/ http://www.python.org/download/releases/version/license/ It's probably, as with all languages, just personal favor, but mine goes in the direction of python :) /martin On Thu, May 22, 2008 at 5:23 PM, hyjial [EMAIL PROTECTED] wrote: Hi list ! Reading through OpenBSD's codebase, I have noticed that the code living under src/usr.sbin/pkg_add is written in Perl. Perl is distributed under the Artistic license, though. The latter is not as permissive as the BSD license under which monst of OpenBSD is released. No doubt that is the reason why Perl lives in src/gnu. Why have such a tool using a non-BSD package when there was choice not to do so ? What technical reasons have lead the developers to elect this language ? I am just curious about the fact and didn't manage to find information in tech@ and mis@ archives. Thanks in advance. Hyjial. -- http://www.xing.com/profile/Martin_Marcher You are not free to read this message, by doing so, you have violated my licence and are required to urinate publicly. Thank you.
Realtek 8185 wireless card
I saw on OpenBSD site that Realtek 8185 pci/cardbus chips are supported as of OBSD 3.8. Just bought an airlink101 card but get 'not configured' in dmesg. Which driver is supposed to support 8185 chips? I couldn't find any other references to these chips. It was a very cheap card for my dad who will only be using it for about a month and a half anyway, but I am curious if its a problem with this particular card, or with some 8185's in general Chris Bennett
Re: Realtek 8185 wireless card
On Sat, May 24, 2008 at 04:33:40PM -0700, [EMAIL PROTECTED] wrote: I saw on OpenBSD site that Realtek 8185 pci/cardbus chips are supported as of OBSD 3.8. where did you see that? Just bought an airlink101 card but get 'not configured' in dmesg. Which driver is supposed to support 8185 chips? I couldn't find any other references to these chips. It was a very cheap card for my dad who will only be using it for about a month and a half anyway, but I am curious if its a problem with this particular card, or with some 8185's in general These cards aren't supported. see rtw(4) for the list of Realtek wifi cards supported in OpenBSD.
Re: E450 stuff
On Sat, May 24, 2008 at 10:36:13AM -0400, bofh wrote: On Sat, May 24, 2008 at 8:03 AM, Nick Holland [EMAIL PROTECTED] wrote: But man, E450s are big. But I'm sure you have noticed that. :) With lots of NON-LOAD-BEARING stickers all over the power supply handles. As a friend of a friend found out. When I moved last year, I tossed it out. 1KW power... man, that sucked a lot of juice. Other than because I can, I'm not really sure what use is a e450, it's a what, 8-10 year old box now. I went through and thought about what I wanted/needed, and threw away the sgi, the hpux, the decstation 3k and 5k, every box under 400Mhz, with one exception, my Apple ][gs. 15 computers, trashed. too bad shipping on those big old boxes is so expensive. I'm of the low-MHz CPU thread. I still have to get a steel case for my dual P-133 Tyan board and try a modern PATA drive on it, but in general it works just fine. Doug.
Re: Why Perl for pkg_* tools ?
On Fri, May 23, 2008 at 08:06:59AM +0200, Paul de Weerd wrote: On Thu, May 22, 2008 at 07:55:48PM -0500, Adam Patterson wrote: Paul de Weerd wrote: On Thu, May 22, 2008 at 03:23:17PM +, hyjial wrote: Anyway, perl is distributed under the artistic license, yet the pkg-tools are licensed under an ISC-style license. Compare, if you will, with most other tools in OpenBSD. They're C programs with an ISC or BSD-style license. However, GCC is distributed under the GPL. Boo-freakidy-hoo .. why make a problem of the perl license now, is bashing GCC's license not fun anymore ? You know, if you want, you could write an ISC-licensed perl interpreter. Go right ahead and feel free to send patches when you're done. I'll suggest a name for you : 'hurl'. If you're done, could you please write an ISC-licensed C-compiler in perl so I can finally shut up all the idiots that claim that a system without a compiler is more secure ? Don't worry, I can wait. I don't know. If you come here I'd expect informed questions. What's the use of discussing the license of the interpreter of the software when talking about the software ? What technical reasons have lead the developers to elect this language ? Since when is that a question provoking sarcasm and anger? Its curiosity. Same thing that got most of us here at some point or another. Everyone is so quick to be the first with a nasty response. The useless discussion on licenses beyond the control of the developers coupled with the poor formatting provoked some sarcasm, yes. Marc Espie, who wrote most of the code, gave us the pkg-tools under an ISC license. The reasons for his choice of language have been documented on the OpenBSD mailinglists. I was not 'quick' or 'trying to be the first' (a useless effort when you're replying to a mail that has already been replied to, by the way), just pointing out (in a sarcastic way, I will grant you that) that it's mostly a fruitless discussion. There's a difference between : What technical reasons have lead the developers to elect this language ? and [Perl is not BSD licensed] What technical reasons have lead the developers to elect this language ? The first is asking a technical question, the second is bringing politics into your techincal question. What do you want, a technical discussion or a political discussion ? As had been pointed out, the technical question had already been answered, the political discussion (I think) merits a sarcastic answer, as this has definitely been discussed over and over and over again. If you don't like the license on perl, you are free to implement the language on your own and license the result any way you like. I just don't see how its license is of any relevance to the software you write in it. OpenBSD comes with perl. It's not going away. Why not use it ? How is it different to using GPL'd GCC to compile ISC'd code ? In the latter case, everybody seems to understand that the license of the compiler has little to do with the license of the code it compiles. The political discussion about using GPL'd GCC and the technical discussion about using C for the base OS have so far been completely separate. The intent of my sarcastic mail was to point out that these two are best kept separate. I think that there's a fundmental difference over worrying about the license on a compiler vs on an interpreter. If your application requires distribution and the license is an issue, you can forgo shipping the compiler and stuff will still work but you can't forgo shipping an interpreter. Of course, without an actual here's-my-problem issue to discuss, its philosophical and hypothetical which allows us to argue over the periphery instead of the core issue. Is there any scenario where one could not easily ship a product that uses OpenBSD with its perl interpreter intact? Doug.
Re: Why Perl for pkg_* tools ?
On Sat, May 24, 2008 at 07:39:34PM +0200, Marc Espie wrote: A final word. For all you backseat drivers: this is OpenBSD. Those who do the work get to call the shots. In reading the thread, I don't get the impression that anyone is second-guessing just that people thought it an interesting decision and couldn't find the relevant discussion in the archives to learn how that decision was made. I did get permission from my fellow developers to switch our pkg_* to perl once I made a strong enough argument. It is this argument in which I think the OP was interested. A huge part of the argument was the actual code. I did write tools that work. I did write an infrastructure that still grows, stays coherent, and is still fairly easy to manage. These pkg_* are the first in the BSD world to actually support safe updates, without needing to back up most of your system first. Everything-in-perl was a deliberate design decision. What do you think ? that we grow code in a vat with eyes closed ? I've looked very closely at the neighbors, and at our distant cousins. The neighbors manage to live on a weird mix of awk/ruby/perl/python/sh/C. From a distance, it looks like everyone in NetBSD/FreeBSD has their own favorite language, and is happy to reinvent a square wheel to handle packages in their own language. Well, my tools were written specifically to squash that, to give people a cool enough interface that they would not need to reinvent the world. It certainly fills up a disk (or it did before disks were insanely huge) to have 5 (?) apps that you really want and they all depend on a different language interpreter. You prefer python ? tough cookies. Perl and python are more or less equivalent. If you know one, you can write code in the other. Or you're less elite than you think (as a sidenote, I loathe php, yet I run a drupal site, and I have written numerous patches for drupal). The only important difference, for me, was that perl comes with the base install in OpenBSD. And we made a conscious decision to keep it so. That gives us *one* decent high-level script language. OS and distributions are all about editorial choices. Some have given up, and let the user wadle through hundreds of inane choice and a bazaar of half-finished toys. OpenBSD takes some strong stances. We wanted pkg_* that work, we got them. You don't like that they're in perl ? you can always go elsewhere, or, if you have some real balls, write something better in whatever language you want. Have fun, good luck. I like that OpenBSD takes some strong stances. If I have a problem to solve, I'll look around to see if its already been solved. If there's a similar but not portable solution in OpenBSD, I like to look at why OpenBSD did something in some way that may be applicable. Doug.
Re: Why Perl for pkg_* tools ?
On Fri, May 23, 2008 at 04:40:05PM -0400, Jeremy Huiskamp wrote: On 23/05/08 04:21 PM, Han Boetes wrote: Yes but C is written in gcc which is GNU licensed and pkg_utils are written in perl which is a much more libaral language. I really start wondering why the whole of OpenBSD is not rewritten in perl! Ah, but perl is compiled with gcc, so that doesn't really help. ;) Well it could. If the only compiled stuff was the kernel and an interpretive language (e.g. perl but not necessarily), then you wouldn't have to distribute anything that was gpl'd. You would use the OpenBSD'ed gcc to create the perl binaries and just ship those binaries and their source (ok, the gcc source too with a link to where to get the gcc version binaries to compile it). Security updates could then conceivably be manageable with binary updates for the kernel and perl, and everything else is already source-ish anyway. I learned Python when I couldn't figure out how to read the perl docs to learn perl. I'm sure somewhere in perldoc is how to read perldoc... Python was easy. As a side effect, it is fairly easy to port python to Ada if I need something to run faster. Now we can all review the why isn't OpenBSD coded in Ada thread. :) Doug.
Intel D201GLY2 and OpenBSD 4.3
Hi, After upgrade to OpenBSD 4.3 from 4.2 my Intel D201GLY2 based gateway go to reboot on kernel initializing. Intel D201GLY2 bios was upgrated to latest but problem was not fixed. Any ideas? -- Sergey Aikinkulov [EMAIL PROTECTED] [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
