Re: Real men don't attack straw men
Is it April 2008 already, or what is happening on this mailing list ? I am about two weeks behind reading but out of curiosity I read a few emails in this thread and well, almost can't believe it. I better stop reading this list for a while and come back after doing something usefull, like installing my alphas and checking wether this damned AlphaBug is really gone gone... ;) Those are my computers and they will eat what I feed them, wether it's free, unfree, payed, unpayed, typed in, downloaded, zigzagged or whatever. I'm free they are not . That simple. n8, sm.
Re: : rouge IPs / user
knitti wrote: you tell me that there is some correlation between HTTP keep alives and a socket ending up in CLOSE_WAIT for some time. That is the practical observation. But I'm interested in whether this is by design or not. RFC 2616 doesn't mention implementation details, and I can't see why the socket implementation (OS) would want to keep a socket in CLOSE_WAIT for some time (not sending a final ACK). One more thing I also forgot to add, or may be didn't come across as clear as it should. If you put of in front of it and use it to proxy the connections, it will only pass the real connection to httpd that are real and as such save you socket that httpd would have to manage and that would end up in CLOSE_WAIT. Why? Let say someone doesn't like your site and send you a bunch of fake connections to (initiate connections) occupy all your sockets and as such making your site totally useless. You can increase the number of connection httpd can support, recompile it and sue it, or a much more logical and practical ways is to use pf to actually filter these connections and avoid the problem in the first place that the limit of httpd have in the default. If you try to establish a connection to httpd directly then it will use a socket even if it can't reply to the source as fake and as such use your resources and I guess end up in CLOSE_WAIT state and waiting to get the final ACK that will never come as it is a fake source. However putting PF in front of it, your httpd wouldn't suffer this part anyway of the depletion of the sockets it can use. Now adjusting the tcp stack value would/could then improve on the time sockets stay in this CLOSE_WAIT state. So, all are connected in any way or angle you try to look at it. Keep alive, max_spare_connections, etc, for speed and time delay for the httpd application to release that socket to the OS. PF to handle these fake/forged TCP connections that would otherwise occupy your httpd sockets available and as such needs to do the full cycle of open, wait and close based on the delay preset and may keep it open for way more time that you may want as it will wait for ever on the ACK for the fake source. And TCP stack variable in making more or less of them (sockets) available sooner or later. So, that's how each one interact with each others in many ways. Hopefully I didn't make more of a mess then it was already and make it a little bit more clear. That's my intend anyway. Hope it help you anyhow. Best, Daniel
Re: Default Route Issues
Thank You all for the pointers I now have it up and running and only have a small persistent route problem. Bret Stuart Henderson wrote: >On 2007/12/11 08:40, Bret wrote: > > >>OK here is the update: >> >> > > > >>ral0: flags=8843 mtu 1500 >>ieee80211: nwid tri-statebroadband.com_2 chan 3 bssid >>inet 10.60.128.2 netmask 0xc000 broadcast 10.60.191.255 >>ral1: flags=8843 mtu 1500 >>ieee80211: nwid tri-statebroadband.com_2_1 chan 1 bssid >>inet 10.60.129.1 netmask 0xc000 broadcast 10.60.191.255 >>em0: flags=8843 mtu 1500 >>media: Ethernet autoselect (100baseTX full-duplex,rxpause,txpause) >>inet 10.60.130.1 netmask 0xc000 broadcast 10.60.191.255 >> >> > >As I suspected, these are all in the same network. > >$ ipcalc 10.60.130.1/0xc000 >address : 10.60.130.1 >netmask : 255.255.192.0 (0xc000) >network : 10.60.128.0 /18 >broadcast : 10.60.191.255 >host min : 10.60.128.1 >host max : 10.60.191.254 >hosts/net : 16382 > >Your chosen netmask makes the first 18 bits of the IP address be >the network address, so 10.60.128 [...] 10.60.191 are all in the >same network. This part of the address should be different between >interfaces.
Re: apm doesn't sleep/suspend desktop
On 12/11/07, Chris Zakelj <[EMAIL PROTECTED]> wrote: > Nick Guenther wrote: > > On Dec 11, 2007 12:30 AM, Chris Zakelj <[EMAIL PROTECTED]> wrote: > > > >> Curious problem here, though I'm probably missing something obvious. I > >> have apm enabled through /etc/rc.conf.local (apmd_flags=""), and when I > >> issue 'shutdown -h -p now', the system powers off correctly. However, > >> if I try to use sleep or suspend ('apm -S' or 'apm -z'), the system acts > >> like it's going to power down, blinks the monitor momentarily, then > >> wakes right back up like nothing ever happened. Where to look next? > >> > > Run apmd with -d? > > > > -Nick > No luck. Running apmd_flags="-d" results in > > === > starting local daemons: smbd nmbd mysqld. > standard daemons: apmdStarting mysqld daemon with databases from > /var/www/var/mysql > (things hang here...) > ^C cron. > Tue Dec 11 21:35:42 EST 2007 > > OpenBSD/i386 (imhotep.***.dyndns.org) (ttyC0) > === > > Worthy of note is that when I run apmd_flags="", I do not get the > "Starting mysql..." message in the boot messages, but the server does > start correctly, and the boot proceeds normally. > h, sorry. I thought you'd check the manpage before trying it. -d makes it run 'do not detach'|'debug'. I meant, don't start it at boot, but instead run it from a terminal, and watch it's debug messages. As for mysql... no clue. Seems like one thing is stepping on another thing. -Nick
Re: apm doesn't sleep/suspend desktop
Nick Guenther wrote: On Dec 11, 2007 12:30 AM, Chris Zakelj <[EMAIL PROTECTED]> wrote: Curious problem here, though I'm probably missing something obvious. I have apm enabled through /etc/rc.conf.local (apmd_flags=""), and when I issue 'shutdown -h -p now', the system powers off correctly. However, if I try to use sleep or suspend ('apm -S' or 'apm -z'), the system acts like it's going to power down, blinks the monitor momentarily, then wakes right back up like nothing ever happened. Where to look next? Run apmd with -d? -Nick No luck. Running apmd_flags="-d" results in === starting local daemons: smbd nmbd mysqld. standard daemons: apmdStarting mysqld daemon with databases from /var/www/var/mysql (things hang here...) ^C cron. Tue Dec 11 21:35:42 EST 2007 OpenBSD/i386 (imhotep.***.dyndns.org) (ttyC0) === Worthy of note is that when I run apmd_flags="", I do not get the "Starting mysql..." message in the boot messages, but the server does start correctly, and the boot proceeds normally.
Re: apm doesn't sleep/suspend desktop
Nick Guenther wrote: On 12/11/07, Chris Zakelj <[EMAIL PROTECTED]> wrote: Nick Guenther wrote: On Dec 11, 2007 12:30 AM, Chris Zakelj <[EMAIL PROTECTED]> wrote: Curious problem here, though I'm probably missing something obvious. I have apm enabled through /etc/rc.conf.local (apmd_flags=""), and when I issue 'shutdown -h -p now', the system powers off correctly. However, if I try to use sleep or suspend ('apm -S' or 'apm -z'), the system acts like it's going to power down, blinks the monitor momentarily, then wakes right back up like nothing ever happened. Where to look next? Run apmd with -d? -Nick No luck. Running apmd_flags="-d" results in === starting local daemons: smbd nmbd mysqld. standard daemons: apmdStarting mysqld daemon with databases from /var/www/var/mysql (things hang here...) ^C cron. Tue Dec 11 21:35:42 EST 2007 OpenBSD/i386 (imhotep.***.dyndns.org) (ttyC0) === Worthy of note is that when I run apmd_flags="", I do not get the "Starting mysql..." message in the boot messages, but the server does start correctly, and the boot proceeds normally. h, sorry. I thought you'd check the manpage before trying it. -d makes it run 'do not detach'|'debug'. I meant, don't start it at boot, but instead run it from a terminal, and watch it's debug messages. As for mysql... no clue. Seems like one thing is stepping on another thing. -Nick Did read, just wasn't expecting that behavior (noob thing on my part). Anyways, here's what I get now... (ttyC0) # tail -f /var/log/messages & (boot remnants) (ttyC1) # apmd -d (silence) (ttyC0) Dec 11 22:34:00 imhotep apmd: battery status: unknown. external power status: connected. estimated battery live 0% # apm -S System will enter standby mode momentarily. (blink) # Dec 11 22:35:02 imhotep apmd: system resumed from APM sleep apm -z System will enter suspend mode momentarily. (blink) # Dec 11 22:35:43 imhotep apmd: system resumed from APM sleep _ Seems to me like something is waking it up as soon as it goes into sleep mode. Could I have something in the BIOS messed up or otherwise causing a wake-up signal too early?
Re: Real men don't attack straw men
On Dec 11, 2007 3:48 PM, Siegbert Marschall <[EMAIL PROTECTED]> wrote: > Is it April 2008 already, or what is happening on this mailing list ? No, but it is about the time for the monthly "what is happening to misc" comments ;) -B
Re: Real men don't attack straw men
On Tue, Dec 11, 2007 at 05:11:25PM -0700, Jack J. Woehr wrote: > Jacob Meuser wrote: > >his absolutism also causes people to see BSD as a "problem", a > >"social failure". > > > In everything, there is light and dark, interwoven :-) > >recently we saw theft of BSD to GPL, and a large part of the > >GPL community thinks there's no problem with that, that the > >BSD community is being "petty" to make an issue out of it. > > > Well, sue 'em, if it's so. But no point in sulking. Like the ENTIRE > PROGRAMMING COMMUNITY, we're a bunch of cantankerous, > contentious, contumacious perfectionists. hmmm, I do/have done a fair amount of work adding/maintaining GPL software in the ports collection. I was working on a port for libcdio, an GNU project. there'a a file in NetBSD's pkgsrc that adds support for NetBSD/OpenBSD cd(4). that file is BSD licensed. the README.libcdio file in the libcdio sources mentions this file and says it can't be included because it's not GPL. I contacted the libcdio maintainer about this file, and he again said he could not include it because the BSD license is incompatible. whatever. so I contacted the author of said file, asking if he could change the license so it could be included upstream. he eventually agreed. I'm only posting this because I understand how easy it could be to look at my remarks and conclude I'm just another theo fan-boy BSD zealot. -- [EMAIL PROTECTED] SDF Public Access UNIX System - http://sdf.lonestar.org
Re: About non-free software in OpenBSD
Lars NoodC)n wrote: > >> Argh, the GPL is so ridiculously complex; nobody understands it. >> > > Many do, though. For me it's rather straight forward, as is the BSD > license. There are many ways to look at the positive goals of the GPL, > but they're not relevant here, since OpenBSD is already set on the BSD > license. > The principles represented by the GPL are fairly simple. The complexity arise because the GPL strives to acheive those principles in a legally enforceable manner. The BSD/ISC License aspires to acheive less, and presumes that a clear statement of principles, is the equivalent of legally enforceable. Yet despite its clarity and simplicity, It is still atleast as misrepresented and misunderstood as the GPL. > > -- -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. "Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction." Albert Einstein
Re: Real men don't attack straw men
I'd like to add two things I forgot earlier on, for Richards consideration: On 12/12/2007, ropers <[EMAIL PROTECTED]> wrote: > This is IMHO very similar to the way the OpenBSD ports system is > related to unfree software: > - The unfree software is not hosted by OpenBSD. The ports tree > effectively only contains metadata. > - The individual ports in the ports system are maintained by > (advanced) OpenBSD users. The inclusion of a port that users chose to > submit and maintain does not imply an endorsement of the (possibly > unfree) software that can be installed using the port metadata. > - The use of the ports system is officially *discouraged* for average > users. Average Joes are encouraged to *not* use ports but use OpenBSD > _packages_ instead, which are precompiled binaries which are hosted by > OpenBSD. ( See "IMPORTANT NOTE" here: > http://www.openbsd.org/faq/faq15.html#Ports ) There are no unfree > packages. See for yourself: (caution: very long page and long load) > http://www.openbsd.org/4.2_packages/i386.html > - Unlike the Pirate Bay, the OpenBSD ports system does itself > distinguish between free and unfree content. See this comment by Nick > Guenther: > > It may be relevant to point out: > > http://marc.info/?l=openbsd-misc&m=119731456628749&w=2 > > > Having a way to sift out the non-free stuff during a search of the ports > > > tree would be useful. > > > > PERMIT_*=(not Yes) - Here I'd like to add that the ports tree is *not* part of the OpenBSD operating system install. The ports tree is something the user has to actively look for and check out to their local system if they want it. This means that the OpenBSD OS and install CD are *completely free* of even the metadata repository that contains user-contributed metadata files, only a minority of which refer to unfree software. As far as I understand, the OpenBSD position appears to be that trying to police users by forbidding them to maintain and retrieve port metadata about unfree software via this adjunct service (that is not included in the OS) would be a restriction of the users' freedom. The Pirate Bay does not police torrents, or suppress certain torrents, and OpenBSD does likewise not police ports. If a user wants to be an ass and do something stupid and unethical, they can. They have the freedom to do that. But don't blame OpenBSD for that. It only has an adjunct facility that allows what is effectively the exchange of advanced semi-automated usage information, nothing more. And yes, it even allows users to exchange stupid usage information, such as how to install unfree-app-xyz. The choice whether to do something stupid is left up to the user, but the user is advised not to use ports in the first place, and hints that allow users to more easily distinguish halal from haram software are in place. > In addition, it is *considerably harder* to install unfree software on > OpenBSD than on gNewSense. This eg. is what installing Skype entails: > http://permalink.gmane.org/gmane.os.bsd.india/352 > On gNewSense, it is *much* easier to install Skype. Just add an unfree > repository to /etc/apt/sources.list and type a one-line command to > install. I don't know for sure, but I suspect that gNewSense will not > warn a user who does that that they are installing unfree software, so > why expect more from OpenBSD? Also, the installation of unfree software is *extremely* frowned upon by the OpenBSD user community. To stay with the Skype example: http://www.nabble.com/Skype-on-the-OpenBSD-td14113398.html http://www.nabble.com/Skype-on-the-OpenBSD-td14113398i20.html > Richard, I you wrote: > > If OpenBSD did not suggest non-free programs, I would > > recommend it along with the free GNU/Linux distros. > > I suspect that your skepticism of OpenBSD stems from yourself being > unfamiliar with the OpenBSD packages and ports system and not aware > that the OpenBSD project does not in fact host unfree packages (and > that ports for unfree programs such as users have submitted only > contain metadata). > > In summary, I strongly feel that OpenBSD in fact does *not* suggest > non-free programs. Despite the heated and sometimes personal nature of > this thread, I think the honorable thing to do would be to be the > bigger man and acknowledge the misunderstandings and make good on your > offer to recommend OpenBSD. > > Thanks and regards, > --ropers
Re: Can I specify the bios time offset utc?
Yesterday, after a long time, it give me a empty page. Today, It's OK. 2007/12/12, Nick Guenther <[EMAIL PROTECTED]>: > On Dec 11, 2007 11:26 AM, Nick Guenther <[EMAIL PROTECTED]> wrote: > > On Dec 11, 2007 12:58 AM, Dongsheng Song <[EMAIL PROTECTED]> wrote: > > > > > > 2007/12/11, Darren Spruell <[EMAIL PROTECTED]>: > > > > > > > On Dec 10, 2007 9:58 PM, Dongsheng Song <[EMAIL PROTECTED]> wrote: > > > > > OpenBSD assume bios time is utc, but it's PRC, can I tell OpenBSD the > > > > > bios time zone? > > > > > > > > http://marc.info/?l=openbsd-misc&m=111956694726618&w=2 > > > > > > > > > Thanks, but I can NOT open the page, could you excerpt for me ? > > > > Really? What's wrong? Are you in China? > > "it's PRC" so yes. > My real question, though, is: do you mean that the great firewall of > china is blocking marc.info? Does it give any message when it does, or > can you just not talk to it? Can you DNS it (`nslookup marc.info`)? > > -Nick
Re: Real men don't attack straw men
* ropers <[EMAIL PROTECTED]> [2007-12-12 01:17:32]: *snip* > > In addition, it is *considerably harder* to install unfree software on > OpenBSD than on gNewSense. This eg. is what installing Skype entails: > http://permalink.gmane.org/gmane.os.bsd.india/352 > On gNewSense, it is *much* easier to install Skype. Just add an unfree > repository to /etc/apt/sources.list and type a one-line command to > install. I don't know for sure, but I suspect that gNewSense will not > warn a user who does that that they are installing unfree software, so > why expect more from OpenBSD? > I agree, In the end, the only way to prevent users from running non GPL software is to basically only distribute binaries for say, atleast the kernel, and only allow cryptographically hashed binaries to run, or something of that sort. That would not stand up long, you could say, offline replace the kernel, or hell, just fork the distribution, or any other myriad of ways. The point is that is very difficult to force people to behave in certain ways, such as only using GPL software. However, if they _want_ to only use GPL software, then that's what they will do. You _can_ run OpenBSD without non GPL, non BSD licensed software. That's how it ships, (save for firmware which we have the rigths to distribute.) Just as you can also run it with something not open and not free. Attempts to force users to do otherwise would be futile. This is the exact same case with the 100% FSF-approved linux distributions Stallman suggested. People do not run non free software on these distributions. It's not because they can't, it's because they don't want to. An aside: The GPL does its job, but only if people put that license on their software. So remember--people's wills, not the license. -- Travers Buda
Re: no 4.2-stable package updates??
Wow. I didn't know this changed. So if there are security bugs in a package or port shipped with OpenBSD 4.2, there will be no updated package or updated port available? I'm in no position to ask someone to do this, so I won't. But this really bites. On Dec 11, 2007, at 8:09 AM, Antoine Jacoutot wrote: On Tue, 11 Dec 2007, Martin Schrvder wrote: Get -stable ports fixed? Lack of interest/man power. -- Antoine
Re: Real men don't attack straw men
Jacob Meuser wrote: the README.libcdio file in the libcdio sources mentions this file and says it can't be included because it's not GPL. I contacted the libcdio maintainer about this file, and he again said he could not include it because the BSD license is incompatible. Yes, our community of people who generally believe in free software and open source find many ways to roll bowling balls at each other's ankles. We're very silly sometimes. Idealists do tend towards intolerance, especially of other idealists. -- Jack J. Woehr Director of Development Absolute Performance, Inc. [EMAIL PROTECTED] 303-443-7000 ext. 527
Re: no 4.2-stable package updates??
On Tue, 11 Dec 2007, Joe wrote: Wow. I didn't know this changed. This was announced on ports@ IIRC. So if there are security bugs in a package or port shipped with OpenBSD 4.2, there will be no updated package or updated port available? That is correct. -- Antoine
4.2 i386 install fails on a HP Compaq dc7700
Greetings, Try to install OpenBSD 4.2 i386 on a new HP Compaq dc7700 Small Form Factor, but when it comes to install the software sets from the CD, the install fails: ... ... ... Password for root account? (will not echo) Password for root account? (again) Let's install the sets! Location of sets? (cd disk ftp or `done`) [cd] Available CD-ROMs are: cd0 Which one contains the install media? (or `done`) [cd0] - -- it stops here, blanks out! - -- During boot the cd0 works OK (is seems), and it is recognized as: cd0 at scsibus0 targ0 lun0: