Re: TP-Link TL-WN8200ND in 5.4
On Thu, Jan 16, 2014 at 08:09:00PM +, Bernte wrote:
> Hello,
>
> I was hoping that my TP-Link TL-WN8200ND works in 5.4, but it looks like
> it is only detected as an unsupported USB device.
>
> ugen0 at uhub0 port 2 "Realtek 802.11n WLAN Adapter" rev 2.00/2.00 addr 2
>
> While the documentation from the provider is not verbose about the
> chipset used, the following page claims that it is a Realtek RTL8192CU,
> which seems to be supported by urtwn(4).
>
> http://wikidevi.com/wiki/TP-LINK_TL-WN8200ND
>
> Assuming that the firmware was missing, I tried fw_update, but that did
> not download any firmware files.
>
> I would be thankful for any kind of help to get this adapter running.
>
> Bernd
A device attaching as ugen means no driver has claimed it.
Support for your device and many other urtwn devices was added
after 5.4.
Here is an untested patch against 5.4 that should work:
to apply:
cd /usr/src/sys/dev/usb
patch -p0 < /tmp/path/to/patch
make
then build and install a kernel as normal
Index: usbdevs
===
RCS file: /cvs/src/sys/dev/usb/usbdevs,v
retrieving revision 1.601
diff -u -p -r1.601 usbdevs
--- usbdevs 21 Jul 2013 15:19:41 - 1.601
+++ usbdevs 17 Jan 2014 06:25:21 -
@@ -600,6 +600,7 @@ vendor TRENDNET 0x20f4 TRENDnet
vendor RTSYSTEMS 0x2100 RT Systems
vendor DLINK3 0x2101 D-Link
vendor MOTOROLA2 0x22b8 Motorola
+vendor TPLINK 0x2357 TP-Link
vendor TRIPPLITE 0x2478 Tripp-Lite
vendor NHJ 0x2770 NHJ
vendor ASUSTEK 0x2821 ASUSTeK Computer
@@ -3980,6 +3981,9 @@ product TORADEX ORIENT0x0015 Toradex O
/* Toshiba Corp products */
product TOSHIBA RT3070 0x0a07 RT3070
product TOSHIBA HSDPA 0x1302 HSDPA
+
+/* TP-Link products */
+product TPLINK RTL8192CU 0x0100 RTL8192CU
/* Trek Technology products */
product TREK THUMBDRIVE0x ThumbDrive
Index: if_urtwn.c
===
RCS file: /cvs/src/sys/dev/usb/if_urtwn.c,v
retrieving revision 1.27
diff -u -p -r1.27 if_urtwn.c
--- if_urtwn.c 21 Jul 2013 15:19:52 - 1.27
+++ if_urtwn.c 17 Jan 2014 06:24:35 -
@@ -130,6 +130,7 @@ static const struct usb_devno urtwn_devs
{ USB_VENDOR_SITECOMEU, USB_PRODUCT_SITECOMEU_RTL8188CU },
{ USB_VENDOR_SITECOMEU, USB_PRODUCT_SITECOMEU_RTL8188CU_2 },
{ USB_VENDOR_SITECOMEU, USB_PRODUCT_SITECOMEU_RTL8192CU },
+ { USB_VENDOR_TPLINK,USB_PRODUCT_TPLINK_RTL8192CU },
{ USB_VENDOR_TRENDNET, USB_PRODUCT_TRENDNET_RTL8188CU },
{ USB_VENDOR_TRENDNET, USB_PRODUCT_TRENDNET_RTL8192CU },
{ USB_VENDOR_ZYXEL, USB_PRODUCT_ZYXEL_RTL8192CU }
Re: NIST-free crypto, autociphering, and libsodium (NaCl)
On Thu, Jan 16, 2014 at 7:12 PM, MJ wrote: > On 17 Jan 2014, at 00.54, Christian Weisgerber wrote: > >> MJ wrote: >> >>> I would like to inquire as to which OpenBSD RELEASE will offer the >>> possibility >>> to avoid NIST crypto for everything in Base (isakmpd, openssh, openssl, >>> https, >>> nginx being the key items in mind)? >> >> What is "NIST crypto"? > > Are you serious or just being facetious? He was serious, because "NIST crypto" has multiple definitions. > I basically used it as an umbrella term to include all of the crypto in which > the US government has had their hand involved in it’s specification, > implementation, approval, standardisation, etc and so forth. Ah, so if NIST looked at work done by someone completely unrelated to NIST and said "looks good, we'll standardize exactly what you did", you think that it's now contaminated by NISTs talking about it? For example, AES, which was designed by europeans and standardized after a massively public competitive process that even the losing competitors think was legit with no funny games, should be excluded by your clarified criteria. That sounds like you're interested in a political statement and not a security goal. As for your original question: let's imagine it could be done right now with just a trivial build switch. Poof, no more "NIST crypto" (haha) for everything. Sweet: you can no longer securely connect to or from almost any non-OpenBSD box! Practically no https:// website would work for you. Wow, that's so much more secure! What problem are you trying to solve? A transition to new ciphers is like an API change: you have you get mind share and acceptance, show people that new stuff still solves their problem and that the change isn't insurmountable in time or effort. You push, but not so hard that you lose traction with the larger community, because we're not just trying to make our own systems more secure, but also everyone else's system. Go listen (again) to Theo's talk at yandex, where he talks about address space mititgations including the ones that were too aggressive and had to be backed out... http://tech.yandex.com/events/ruBSD/2013/talks/103/ Philip Guenther
Re: NIST-free crypto, autociphering, and libsodium (NaCl)
On 17 Jan 2014, at 00.54, Christian Weisgerber wrote: > MJ wrote: > >> I would like to inquire as to which OpenBSD RELEASE will offer the >> possibility >> to avoid NIST crypto for everything in Base (isakmpd, openssh, openssl, >> https, >> nginx being the key items in mind)? > > What is "NIST crypto"? Are you serious or just being facetious? I basically used it as an umbrella term to include all of the crypto in which the US government has had their hand involved in it’s specification, implementation, approval, standardisation, etc and so forth. http://csrc.nist.gov/groups/ST/toolkit/index.html
Re: Request for Funding our Electricity
I have a suggestion for every one of us that has mailed in an idea in response to a solicitaion for money... Send money. Just do it right now, write a cheque. Send it, send it now. Do that a couple of times a year. Buy a cd twice a year, get at least one t-shirt with each order. Were we told how much the monthly electron bill is? I can step up my contribution a bit. Could we save money by converting to steam, maybe we could remove support for coff binary's cause they are , you know, bad or old or something. Or perhaps running the build farm on raspberry pi's. I understand Linux has a cross compiler and that way we could all just shut up and chip in some dough. Steven Chamberlain wrote: I've set up a small recurring donation for now. I'd like to throw out some ideas and questions if I may: * Anyone selling an OpenBSD-based solution to business customers might want to imagine the OS has some sort of 'license fee', increase the quote for their work accordingly, and pass along the sum in donations. * Please could we get a newer picture than rack2009.jpg? I assume much has already changed; I don't see a loongson build machine for example. Would the picture be anywhere near representative of where the CAN$20k electricity costs arise? * Is there any easy means on-hand to measure power consumption, maybe reading stats from the UPSes, or using plug-in meters such as those made by CurrentCost; would anything like that be worth putting on the hardware wishlist? * Could potential energy savings be roughly worked out, and maybe mentioned in the hardware wishlist somehow? Would a Sun Fire T1000 be able to replace some number of older sparc boxes for example? And as SSDs become larger, would a pair of them be able to replace some number of power-hungry 10k RPM disks? Such things are all the more valuable as donations if they have a lower operating cost than what they replaced. Regards,
Re: Is my 5.4 CD ok?
>On 2014-01-16, Matt M wrote: >> There isn't any reason all the packages couldn't fit on a cd. Most are just >> a few bytes to a few kb, and a small number are into a few MB. Browsing the >> package list (for i386), it looks like the largest one might be 4mb. > >Unfortunately we can only include a *very* small part of the package >collection on the release CDs. > >The set of packages for 5.4 on the ftp site is nearly 40GB just for i386 >and amd64 (and as usual, -current and so the next release 5.5 will be >bigger). For packages, you're talking one layer of a bluray disk per >arch, there's no way they will fit on a CD or even DVD. (a) if you study past release CDs, you will see different space saving policies have been done in different generations. For the last one, we decided to shine a bit by introducing more architectures, rather than more packages. (we == naddy and I; there's a pile of reasons for the decision) (b) we are moving towards signed packages...
Re: NIST-free crypto, autociphering, and libsodium (NaCl)
On 16 Jan 2014, at 23.55, Chris Cappuccio wrote: > > All until we learn from the newest Snowden slide that Dan Bernstein is > actually on the NSA payroll :) > All your DJBs belong to us!
Re: NIST-free crypto, autociphering, and libsodium (NaCl)
On 16 Jan 2014, at 20.49, Nicolai wrote: > > Things are moving in the right direction! The last six months have seen > MAJOR improvements in crypto. If you want to be a part of it, pick up > DNSCrypt or DNSCurve. Get a recent Chromium and play with QUIC. Read > about MinimaLT. Strong, fast encryption is coming. And I think OpenBSD > 5.5 will be light years ahead when it's released in May. DNSCurve, I was already trying to compile it yesterday. Wonderful: # ./configure.nacl Took a long, long time to complete and didnt produce any output at all. # ./configure.curvedns Finished configuring CurveDNS, ready for compiling. Chosen/picked ABI: x86 Chosen/picked compiler: gcc Chosen/picked compiler options: -m32 -O3 -fomit-frame-pointer -funroll-loops We are now ready to compile, run 'make' to do so. # make gcc -m32 -O3 -fomit-frame-pointer -funroll-loops -Wall -fno-strict-aliasing -O3 -Inacl/build/include/x86 -c curvedns-keygen.c In file included from misc.h:49, from curvedns-keygen.c:46: ip.h:54:31: error: ev.h: No such file or directory In file included from misc.h:49, from curvedns-keygen.c:46: ip.h:78: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'global_ip_internal_timeout' ip.h:79: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'global_ip_tcp_external_timeout' *** Error code 1 Stop in /usr/local/src/curvedns-0.87 (line 79 of Makefile). Seems that it cant even find headers in /usr/local/include, which is where the OpenBSD pack for libev installs the header, so I had to add that: # vim Makefile # If you have libev at a non-standard place, specify that here: EV=/usr/local EVCFLAGS=-I$(EV)/include EVLDFLAGS=-L$(EV)/lib And then we get a bit further: # make gcc -m32 -O3 -fomit-frame-pointer -funroll-loops -Wall -fno-strict-aliasing -O3 -Inacl/build/include/x86 -I/usr/local/include -c curvedns-keygen.c gcc -m32 -O3 -fomit-frame-pointer -funroll-loops -Wall -fno-strict-aliasing -O3 -Inacl/build/include/x86 -I/usr/local/include -c debug.c gcc -m32 -O3 -fomit-frame-pointer -funroll-loops -Wall -fno-strict-aliasing -O3 -Inacl/build/include/x86 -I/usr/local/include -c ip.c gcc -m32 -O3 -fomit-frame-pointer -funroll-loops -Wall -fno-strict-aliasing -O3 -Inacl/build/include/x86 -I/usr/local/include -c misc.c misc.c: In function 'misc_base32_decode': misc.c:291: error: 'EPROTO' undeclared (first use in this function) misc.c:291: error: (Each undeclared identifier is reported only once misc.c:291: error: for each function it appears in.) *** Error code 1 Stop in /usr/local/src/curvedns-0.87 (line 76 of Makefile). Whats this EPROTO and do I really need to care? I commented it out in misc.c, dnscurve.c and dns.c: PROTO: //errno = EPROTO; return 0; } And then: # make gcc -m32 -O3 -fomit-frame-pointer -funroll-loops -Wall -fno-strict-aliasing -O3 -Inacl/build/include/x86 -I/usr/local/include -c dns.c gcc -m32 -O3 -fomit-frame-pointer -funroll-loops -Wall -fno-strict-aliasing -O3 -Inacl/build/include/x86 -I/usr/local/include -c curvedns.c In file included from curvedns.c:37: /usr/include/sys/socket.h:162: error: expected specifier-qualifier-list before 'u_int8_t' /usr/include/sys/socket.h:180: error: expected specifier-qualifier-list before 'u_int8_t' /usr/include/sys/socket.h:378: error: expected specifier-qualifier-list before 'socklen_t' /usr/include/sys/socket.h:405: error: expected specifier-qualifier-list before 'socklen_t' In file included from curvedns.c:37: /usr/include/sys/socket.h:462: error: expected declaration specifiers or '...' before 'socklen_t' /usr/include/sys/socket.h:463: error: expected declaration specifiers or '...' before 'socklen_t' /usr/include/sys/socket.h:464: error: expected declaration specifiers or '...' before 'socklen_t' /usr/include/sys/socket.h:465: error: expected declaration specifiers or '...' before 'uid_t' /usr/include/sys/socket.h:465: error: expected declaration specifiers or '...' before 'gid_t' /usr/include/sys/socket.h:466: error: expected declaration specifiers or '...' before 'socklen_t' /usr/include/sys/socket.h:467: error: expected declaration specifiers or '...' before 'socklen_t' /usr/include/sys/socket.h:468: error: expected declaration specifiers or '...' before 'socklen_t' /usr/include/sys/socket.h:470: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'recv' /usr/include/sys/socket.h:471: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'recvfrom' /usr/include/sys/socket.h:472: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'recvmsg' /usr/include/sys/socket.h:473: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'send' /usr/include/sys/socket.h:474: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'sendto' /usr/include/sys/socket.h:476: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'sendmsg' /usr/include/sys/socket.h:477: error: expected declaration spec
Re: unreliable connections
On 2014-01-16, Chris Smith wrote: > This issue is still with me. Sporadically the connection will fail, > and a connection attempt immediately after the failure will (so far) > always work. Again the problem is only with this one remote firewall, > all of the others are fine. the hardware is virtually identical, > similar versions of the Supermicro 5015A boxes. Also note that said > problem box was used in another location with an older version of > OpenBSD without said issues. This could be an MTU or RWIN-related issue. One common problem is if the firewall state is created from an already-established connection rather than a SYN packet, in this case the firewall can't keep track of the RWIN value which is set by many modern OS, and needed in order for a stateful firewall to track the conection To avoid the risk of this I usually start pf rulesets with "block log" (*not* 'block in log', etc) just to make sure that no packets are passed by the implicit default rule (which is basically "pass all flags any no state") which takes effect if no other rules match. Posting the firewall ruleset may possibly help people diagnose this in more detail.
Re: Request for Funding our Electricity
On 2014-01-16, Sia Lang wrote: > Virtual machines/emus and canadian cross builds should be able to reduce > the amount of iron, no? Try following http://www.openbsd.org/vax-simh.html. Then observe your cpu usage figures and, if you are able to measure it, the power consumption. If you make it as far as installing the OS and checking out source, xenocara and ports trees over CVS without getting bored and doing something more interesting instead, I'll be surprised...
Re: Is my 5.4 CD ok?
On 2014-01-16, Matt M wrote: > There isn't any reason all the packages couldn't fit on a cd. Most are just > a few bytes to a few kb, and a small number are into a few MB. Browsing the > package list (for i386), it looks like the largest one might be 4mb. Unfortunately we can only include a *very* small part of the package collection on the release CDs. The set of packages for 5.4 on the ftp site is nearly 40GB just for i386 and amd64 (and as usual, -current and so the next release 5.5 will be bigger). For packages, you're talking one layer of a bluray disk per arch, there's no way they will fit on a CD or even DVD. > On Thu, Jan 16, 2014 at 7:28 PM, Mario wrote: >> I guess the question is are all the binaries supposed to be on CD because >> if I follow instructions as per booklet: >> >> % su >> Password : >> # mount /dev/cd0a /mnt >> # /mnt/5.4/packages/amd64 >> # pkg_add emacs-21.4p23.tgz these instructions may need a tweak for the next release...
Re: Request for Funding our Electricity
I've set up a small recurring donation for now. I'd like to throw out some ideas and questions if I may: * Anyone selling an OpenBSD-based solution to business customers might want to imagine the OS has some sort of 'license fee', increase the quote for their work accordingly, and pass along the sum in donations. * Please could we get a newer picture than rack2009.jpg? I assume much has already changed; I don't see a loongson build machine for example. Would the picture be anywhere near representative of where the CAN$20k electricity costs arise? * Is there any easy means on-hand to measure power consumption, maybe reading stats from the UPSes, or using plug-in meters such as those made by CurrentCost; would anything like that be worth putting on the hardware wishlist? * Could potential energy savings be roughly worked out, and maybe mentioned in the hardware wishlist somehow? Would a Sun Fire T1000 be able to replace some number of older sparc boxes for example? And as SSDs become larger, would a pair of them be able to replace some number of power-hungry 10k RPM disks? Such things are all the more valuable as donations if they have a lower operating cost than what they replaced. Regards, -- Steven Chamberlain ste...@pyro.eu.org
Re: Request for Funding our Electricity
Gregor Best wrote:
On Wed, Jan 15, 2014 at 09:55:04PM +, Franchini Fabien wrote:
[...]
I suggest to write a letter to theses companies who are known to using OpenBSD
or other product-related like OpenSSH. In this letter we can explain (as the
first
post from Theo) our issue. I'm sure they can give us an hand if they know our
problem. And in my opinion, ONLY a company can give us a long-term solution.
[...]
Maybe to inject a further point into this discussion... One of these
companies is Apple. They replaced ipfw with pf in recent releases of
Darwin (see [0]).
Since, with Darwin being Open Source, they seem not entirely against
spending resources on Open Source Software, and they profit in no small
margin from the OpenBSD project and its "satellites" like OpenSSH, they
might be a good recipient for a polite letter in request of help. Not
the least because they could use their assistance in their marketing
("Look how cool we are, we are paying them their electricity!").
Any large company will want something in return, mostly more money than
they gave you, whether direct or indirectly. OpenBSD staying alive
doesn't affect their bottom line, if we disappear they could always just
use one of the (albeit far less secure) alternatives. If we start asking
money for our code, that is what they'll do. I, for one, would rather
allow corporations to use my code for free without credit than to spend
long nights protecting my systems from the malware spewing from their
compromised machines.
If something like this is to survive, we'll need to provide a carrot,
rather than a stick. What I mean by this is that we need to give them a
reason why giving us money will be in their best interests, like
pointing out that by using our code, they are saving money by having to
produce and distribute less patches. Or perhaps offer to improve our
code in their favor, eg make it more efficient on their hardware in
exchange for hardware, money or both. To take the Apple example, we
could offer to make pf more OS-X friendly in exchange for a small
consideration, saving them money because it would require less time on
their part to adapt it.
Re: NIST-free crypto, autociphering, and libsodium (NaCl)
MJ wrote: > I would like to inquire as to which OpenBSD RELEASE will offer the possibility > to avoid NIST crypto for everything in Base (isakmpd, openssh, openssl, https, > nginx being the key items in mind)? What is "NIST crypto"? > As it stands, there is currently cipher-suite negotiation / configuration > coded into every single crypto-enabled tool / daemon and it's a bit of a mess > and a headache to manage it all. Yeah, well, they all need to interoperate independently and speak different protocols. > Would it be good to start to think about having a single, system-wide > cipher-suite negotiation configuration and socket? Wäre es gut, wenn die ganze Welt eine Sprache sprechen würde? -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: Request for Funding our Electricity
On Thu, Jan 16, 2014 at 01:10:05PM +0100, Sia Lang wrote: > Virtual machines/emus and canadian cross builds should be able to reduce > the amount of iron, no? Just a side note to the people talking about emulators. Obviously, you're not tried to install OpenBSD on emulators. Basically, everything is broken except amd64 and i386. Feel free to create guides to teaching us how to install each platform supported on some emulator. > > > On Thu, Jan 16, 2014 at 12:53 PM, Theo de Raadt > wrote: > > > >Through the history of openbsd there have been architectures in which > > more bugs have been found and some in which fewer bugs have appeared. > > > > That is not true. > > > > >Then maybe the number of bugs for an architecture can be matched to the > > power-on-time for the machines for that architecture. > > > > Maybe. Probably need them on to prove or disprove the point. > > > > >For example, if 1% of the total number of bugs in the history of openbsd > > have appeared on architecture x, then it's likely that it will continue to > > be so, then all the machines for that architecture should be powered on > > just 1% of the time. > > > > Another great advantage here is that all the pesky developers who love > > those machines will go away, and we'll only need to run on the best > > architectures (which of course, are big endian). > > > > >Then perform that analysis on all architectures to make a more better use > > of energy. And that's it. > > > > It's so simple. Why didn't I think of it. > -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: NIST-free crypto, autociphering, and libsodium (NaCl)
On Thu, Jan 16, 2014 at 9:01 AM, MJ wrote: > So bear with me, but would it be possible to switch /dev/crypto to be an > interface to an autocipher engine where both OpenSSL and NaCl ciphers could > be supported via e.g. /etc/autocipher.conf and then change all crypto-enabled > apps to use /dev/crypto and only /dev/crypto as the interface? Moving to stronger safer crypto is a good goal, but framing the issue as OpenSSL vs NaCl suggests you don't actually understand what either of these libraries do. I've also never heard of an "autocipher engine" (Googling it only brings me back to this thread) and standardizing on /dev/crypto as the interface would be terrible for security, because it would force users to use type-unsafe ioctl() or read()/write() commands.
Re: Request for Funding our Electricity
Just my $0.02 worth. OpenBSD asked for help. Why everything we see is change this, change that, etc. Like they don't know what they are doing for the last 20 years! Either we can help or we can't. But please stop trying to tell everyone how to do what they do best for the last 20 years like they have no clue what they do... If you sadly really think a bake sale will help. Then do it yourself and then send the profit to the project. Or do what ever else you can to help and so be it. I fell so sad at the reaction of the community when the project is asking for help and that's what they get. And more shameful in between these sad emails I still see some asking when this or that will be supported by the project as well... What a shame... Do what you can to help and stop telling others what to do please. Talk to your company, friends, what ever for trying to help as well, or come with an original idea and just do it. If you think company should get letters from the project to help the project, then write them yourself and try to make the case as I am sure they all use something that came form OpenBSD in one way or an other, but please stop telling the guys there what they should do! They do plenty already! Best regards, Daniel
Re: NIST-free crypto, autociphering, and libsodium (NaCl)
Nicolai [nicolai-om...@chocolatine.org] wrote: > > As for your point, there's a lot of interest in and support for NaCl. > For example, Curve25519 is now in a bunch of stuff like OpenSSH, Tor, > Chromium and DNSCurve. Salsa20 and ChaCha20 are getting big. It's > happening. Now that people are more focused on using crypto that > actually protects them and their data/privacy, I think there may be a > "choice" looming where the IETF either adopts strong crypto, or people > move beyond such standards groups in favor of a bottom-up approach. > (This is already beginning to happen.) I think certain standards groups > have become way too comfortable and don't serve a common good. All until we learn from the newest Snowden slide that Dan Bernstein is actually on the NSA payroll :)
TP-Link TL-WN8200ND in 5.4
Hello, I was hoping that my TP-Link TL-WN8200ND works in 5.4, but it looks like it is only detected as an unsupported USB device. ugen0 at uhub0 port 2 "Realtek 802.11n WLAN Adapter" rev 2.00/2.00 addr 2 While the documentation from the provider is not verbose about the chipset used, the following page claims that it is a Realtek RTL8192CU, which seems to be supported by urtwn(4). http://wikidevi.com/wiki/TP-LINK_TL-WN8200ND Assuming that the firmware was missing, I tried fw_update, but that did not download any firmware files. I would be thankful for any kind of help to get this adapter running. Bernd # usbdevs -v Controller /dev/usb0: addr 1: high speed, self powered, config 1, EHCI root hub(0x), RDC(0x17f3), rev 1.00 port 1 powered port 2 addr 2: high speed, power 500 mA, config 1, 802.11n WLAN Adapter(0x0100), Realtek(0x2357), rev 2.00, iSerialNumber 00e04c01 Controller /dev/usb1: addr 1: high speed, self powered, config 1, EHCI root hub(0x), RDC(0x17f3), rev 1.00 port 1 powered port 2 powered Controller /dev/usb2: addr 1: full speed, self powered, config 1, OHCI root hub(0x), RDC(0x17f3), rev 1.00 port 1 powered port 2 powered Controller /dev/usb3: addr 1: full speed, self powered, config 1, OHCI root hub(0x), RDC(0x17f3), rev 1.00 port 1 powered port 2 powered # dmesg OpenBSD 5.4 (GENERIC) #37: Tue Jul 30 12:05:01 MDT 2013 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Vortex86 SoC (586-class) 934 MHz cpu0: FPU,TSC,CX8,MMX real mem = 1039724544 (991MB) avail mem = 1011290112 (964MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 11/26/10, BIOS32 rev. 0 @ 0xf0010 apm0 at bios0: Power Management spec V1.2 pcibios0 at bios0: rev 3.0 @ 0xf/0x1 pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf2fe0/240 (13 entries) pcibios0: no compatible PCI ICU found: ICU vendor 0x17f3 product 0x6036 pcibios0: Warning, unable to fix up PCI interrupt routing pcibios0: PCI bus #0 is the last bus bios0: ROM list: 0xc/0x8000 cpu0 at mainbus0: (uniprocessor) pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 vendor "RDC", unknown product 0x6022 rev 0x00 rl0 at pci0 dev 1 function 0 "Realtek 8139" rev 0x10: irq 11, address 44:4d:50:07:1b:19 rlphy0 at rl0 phy 0: RTL internal PHY rl1 at pci0 dev 2 function 0 "Realtek 8139" rev 0x10: irq 11, address 44:4d:50:07:1b:1a rlphy1 at rl1 phy 0: RTL internal PHY pcib0 at pci0 dev 7 function 0 vendor "RDC", unknown product 0x6036 rev 0x00 vte0 at pci0 dev 8 function 0 "RDC R6040 Ethernet" rev 0x00: irq 6, address 00:1b:eb:25:30:9e rdcphy0 at vte0 phy 1: R6040 10/100 PHY, rev. 1 ohci0 at pci0 dev 10 function 0 "RDC R6060 USB" rev 0x12: irq 7, version 1.0, legacy support ehci0 at pci0 dev 10 function 1 "RDC R6061 USB" rev 0x03: irq 3 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 "RDC EHCI root hub" rev 2.00/1.00 addr 1 ohci1 at pci0 dev 11 function 0 "RDC R6060 USB" rev 0x12: irq 5, version 1.0, legacy support ehci1 at pci0 dev 11 function 1 "RDC R6061 USB" rev 0x03: irq 9 usb1 at ehci1: USB revision 2.0 uhub1 at usb1 "RDC EHCI root hub" rev 2.00/1.00 addr 1 pciide0 at pci0 dev 12 function 0 "RDC R1011 IDE" rev 0x01: DMA (unsupported), channel 0 configured to compatibility, channel 1 configured to compatibility pciide0: channel 0 ignored (not responding; disabled or no drives?) wd0 at pciide0 channel 1 drive 0: wd0: 16-sector PIO, LBA48, 305245MB, 625142448 sectors vga1 at pci0 dev 13 function 0 vendor "RDC", unknown product 0x2012 rev 0x00 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) azalia0 at pci0 dev 14 function 0 vendor "RDC", unknown product 0x3010 rev 0x01: irq 10 azalia0: No codecs found isa0 at pcib0 isadma0 at isa0 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo com0: probed fifo depth: 0 bytes pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard, using wsdisplay0 pcppi0 at isa0 port 0x61 spkr0 at pcppi0 npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16 usb2 at ohci0: USB revision 1.0 uhub2 at usb2 "RDC OHCI root hub" rev 1.00/1.00 addr 1 usb3 at ohci1: USB revision 1.0 uhub3 at usb3 "RDC OHCI root hub" rev 1.00/1.00 addr 1 ugen0 at uhub0 port 2 "Realtek 802.11n WLAN Adapter" rev 2.00/2.00 addr 2 vscsi0 at root scsibus0 at vscsi0: 256 targets softraid0 at root scsibus1 at softraid0: 256 targets root on wd0a (197b846eebaa6c90.a) swap on wd0b dump on wd0b
Re: Request for Funding our Electricity
>> Then maybe the number of bugs for an architecture can bematched to >> the power-on-time for the machines for that architecture. > >So your solution is to replace requiring financial donations to >requiring more hardware donations? Cold boots are by far the biggest >cause of hardware failure, this risk is far too high for some of the >older machines that consequently have more expensive and harder to find >parts. To clarify the situation: the machines are on all the time. And as much as possible, they are always building something, whether it be ports or builds, hoping that some of the address space randomization or such will spot bugs. Also, if a new change goes into the source tree which creates a problem, we want to spot it as soon as possible, before the developers involved have become distracted in other directions. > Besides, how are you going to find bugs on powered-off machines? No kidding.
Re: NIST-free crypto, autociphering, and libsodium (NaCl)
MJ [m...@sci.fi] wrote: > > On 16 Jan 2014, at 20.24, Chris Cappuccio wrote: > > > > Block traffic with specific ciphers from traversing the network? That's > > sci.fi > > > > You?re right again - this stuff is futuristic but could potentially be > accomplished via inspection of unencrypted packet headers, etc (i.e. via > packet-pattern/flow analysis). However, it could likely be accomplished for > things that access the machine itself. > > We are getting into the realm of wirespeed DPI now. If we won?t be doing it, > somebody else will. What are our efforts worth if the crypto exists in silos > and is vulnerable to side channel attacks? Is it really worth delegating > these sorts of things to ports? > This is just another area where someone has to have the interest and the skill. I don't think you'll ever see pf trying to filter out bad crypto. On that note, Franco Fichtner has been doing some nice DPI work. https://github.com/fichtner Although you'll probably have to track him down and email him to get some more current code. Fichtner's work has been mated with Netmap more recently (which I started porting to OpenBSD but never finished, it compiles...) and I bet it could also be mated with divert-packet for performance (see http://quigon.bsws.de/papers/2013/vbsdcon/mgp00044.html)
Re: Request for Funding our Electricity
Then maybe the number of bugs for an architecture can bematched to the power-on-time for the machines for that architecture. So your solution is to replace requiring financial donations to requiring more hardware donations? Cold boots are by far the biggest cause of hardware failure, this risk is far too high for some of the older machines that consequently have more expensive and harder to find parts. Besides, how are you going to find bugs on powered-off machines?
Re: NIST-free crypto, autociphering, and libsodium (NaCl)
On 16 Jan 2014, at 20.24, Chris Cappuccio wrote: > > Block traffic with specific ciphers from traversing the network? That's sci.fi > You’re right again - this stuff is futuristic but could potentially be accomplished via inspection of unencrypted packet headers, etc (i.e. via packet-pattern/flow analysis). However, it could likely be accomplished for things that access the machine itself. We are getting into the realm of wirespeed DPI now. If we won’t be doing it, somebody else will. What are our efforts worth if the crypto exists in silos and is vulnerable to side channel attacks? Is it really worth delegating these sorts of things to ports?
problems with non-utf8 characters in mutt after upgrading to 5.4
Hello, After upgrading from OpenBSD 5.3 to OpenBSD 5.4 I've got problems with non-utf8 characters in mutt email client. It worked just fine until upgrade, but after upgrade it doesn't show non-ascii characters in subject or body if email message is non-utf8 (tried it with iso-8859-13, windows-1257, koi8-r charsets, none of them display correctly). In email messages that are UTF-8 encoded all characters display fine. It seems that mutt stopped converting other charsets to utf8. I exprience same issue on both i386 and amd64, by using xterm or rxvt-unicode. I haven't changed anything regarding X.org or mutt configuration. I've made sure that these files were rm'ed after upgrading to 5.4: /usr/share/locale/*.* /usr/share/locale/de_AT Any ideas what could be wrong? Thanks! -- Karlis
Re: Is my 5.4 CD ok?
On 01/17/14 01:28, Mario wrote: Hi list. I know you are all busy discussing electricity issues but maybe one of you can take a moment to answer this. Browsing my new CDs for first time ever, I am a little confused and I am seeking clarification. Is the following normal? Because when I think about it, can really over 14,000 packages (amd64 + hppa) fit on a CD. I am puzzled. marst:349$ pwd /mnt/5.4/packages/amd64 marst:350$ ls -l total 25238 -r--r--r-- 1 root wheel 539 Aug 5 17:25 TRANS.TBL -r--r--r-- 1 root wheel 125468 Jul 29 13:26 bzip2-1.0.6p0.tgz -r--r--r-- 1 root wheel 674979 Jul 29 13:26 curl-7.26.0p3.tgz -r--r--r-- 1 root wheel 7556487 Jul 29 13:26 gettext-0.18.2p3.tgz -r--r--r-- 1 root wheel 2012934 Jul 29 13:26 gnupg-1.4.13p0.tgz -r--r--r-- 1 root wheel 159 Aug 5 17:22 index.txt -r--r--r-- 1 root wheel 1521545 Jul 29 13:26 libiconv-1.14p0.tgz -r--r--r-- 1 root wheel 264257 Jul 29 13:26 libidn-1.27.tgz -r--r--r-- 1 root wheel 280021 Jul 29 13:26 rsync-3.0.9p3.tgz -r--r--r-- 1 root wheel 165840 Jul 29 13:26 unzip-6.0p2.tgz -r--r--r-- 1 root wheel 322276 Jul 29 13:26 xz-5.0.5.tgz marst:351$ I guess the question is are all the binaries supposed to be on CD because if I follow instructions as per booklet: % su Password : # mount /dev/cd0a /mnt # /mnt/5.4/packages/amd64 # pkg_add emacs-21.4p23.tgz That's not working. Well it worked when my $PKG_PATH was still set on ftp but I suppose PKG_PATH is supposed to be set to the CD path. Also nowhere on CD2 I can find the soundtrack. I suppose that should be easy. I would really need a song at the moment. Hi Mario, The song is on the i386 + loongson + vax cd: port:fred ~> sudo mount -t cd9660 /dev/cd0a /mnt/cd Password: port:fred ~> ls /mnt/cd/ 5.4PACKAGES README etc HARDWARE PORTS TRANS.TBL song54.mp3 And yes there are only 9 packages on the CD - the rest can be download from one of the mirrors. There is only so much that can be put on 3 CDROMs. Cheers Fred
Re: NIST-free crypto, autociphering, and libsodium (NaCl)
On Thu, Jan 16, 2014 at 01:24:09PM +0200, MJ wrote: > Hello, > > I would like to inquire as to which OpenBSD RELEASE will offer the possibility > to avoid NIST crypto for everything in Base (isakmpd, openssh, openssl, https, > nginx being the key items in mind)? Hi MJ, Base must be interoperable with other systems of course, and for some time that will require TLS unfortunately. Aside from that though, the upcoming OpenBSD release, 5.5, will be a landmark for strong crypto. Look here for strings like "25519", "signify", and "chacha" http://www.openbsd.org/plus.html As for your point, there's a lot of interest in and support for NaCl. For example, Curve25519 is now in a bunch of stuff like OpenSSH, Tor, Chromium and DNSCurve. Salsa20 and ChaCha20 are getting big. It's happening. Now that people are more focused on using crypto that actually protects them and their data/privacy, I think there may be a "choice" looming where the IETF either adopts strong crypto, or people move beyond such standards groups in favor of a bottom-up approach. (This is already beginning to happen.) I think certain standards groups have become way too comfortable and don't serve a common good. > Thoughts, comments, insults, etc, are all welcome! Things are moving in the right direction! The last six months have seen MAJOR improvements in crypto. If you want to be a part of it, pick up DNSCrypt or DNSCurve. Get a recent Chromium and play with QUIC. Read about MinimaLT. Strong, fast encryption is coming. And I think OpenBSD 5.5 will be light years ahead when it's released in May. Nicolai
Re: Request for Funding our Electricity
Bob Beck wrote: so it's not a source of sustainable funding, unless we were to do something like introduce an annual quota of bugs http://dilbert.com/strips/comic/1995-11-13/ -- Jack Woehr # "We commonly say we have no time when, Box 51, Golden CO 80402 # of course, we have all that there is." http://www.softwoehr.com # - James Mason, _The Art of Chess_, 1905
Re: Request for Funding our Electricity
+1 for the subscription idea. Not that it completely solves the problem at hand. But a great (IMHO) idea. -- Josh Smith KD8HRX Email/jabber: juice...@gmail.com Phone: 304.237.9369(c) Sent from my iPhone. > On Jan 16, 2014, at 2:34 PM, Jan Lambertz wrote: > > I like the subscription idea. I'd love to have every release without > actually doing the shopping every time. This could at least make a bit of > safe money. > > I believe, making a company sending 20k$ every year to openbsd could be > quite difficult. > Why should they do this ? > What do they get ? > Why is that better than spending that money in new hardware or buying fancy > whiteboards in managers office ? > > I know what they would get, but they dont. How do we make a company to know > about the benefit of openbsd? They never heard of it. They wont ever use it > because they dont get a 24/7 support contract from a big consulting company > for it. > They dont know about openbsd and most dont care. > That might not be the opinion of most people on this list but it is the > opinion of most people not on this list [the ones with money].
Re: NIST-free crypto, autociphering, and libsodium (NaCl)
On 16 Jan 2014, at 19.17, Chris Cappuccio wrote: > OpenBSD has already began incorporating NaCl by bypassing OpenSSL entirely. Good news - perhaps my philosophy is “why lay a lot of small bricks here and there when you can lay a cornerstone and be done with it?”. But perhaps I am not taking all things into consideration. > I can't speak for the architectural issues but I can't imagine that I or you > are the only people imagining better cipher suites in the base system. You are certainly right - that would be just naive. The OpenBSD approach to things is generally to make the interfaces as simple as possible, drop-dead simple. This eliminates configuration mistakes. Take OpenNTPD for example - it’s simply beautiful what has been done with the configuration interface. A systemwide autocipher engine device could easily be incorporated directly in to PF, no? block all cipher hmac-sha1 (for example). -mike
Request for Funding our Electricity
I like the subscription idea. I'd love to have every release without actually doing the shopping every time. This could at least make a bit of safe money. I believe, making a company sending 20k$ every year to openbsd could be quite difficult. Why should they do this ? What do they get ? Why is that better than spending that money in new hardware or buying fancy whiteboards in managers office ? I know what they would get, but they dont. How do we make a company to know about the benefit of openbsd? They never heard of it. They wont ever use it because they dont get a 24/7 support contract from a big consulting company for it. They dont know about openbsd and most dont care. That might not be the opinion of most people on this list but it is the opinion of most people not on this list [the ones with money].
Re: Request for Funding our Electricity
On 16 Jan 2014, at 19.45, Jack Woehr wrote: > > I think Theo has answered this previously. His point was that he doesn't want > to spend his time year after year > running campaigns. Being neither a politician nor a diplomat nor a > grantmaster, he wants a sustainable model. There’s a person who writes excellent documentation for OpenBSD, isn’t he an English language professor? Excellent documentation is one of the key features of OpenBSD, hands down, i.e. he is an extremely valuable project member even if he doesn’t commit executable code to version control. With this in mind, wouldn’t there be room in core for a person dedicated to fund-raising, i.e. a person with a strong vote? I really do want to see OpenBSD survive, but expenses are a reality as we now see. Being the project leader means also addressing the issue of funding in a feasible manner, even if addressing simply means delegation to a person who has both the competence as well as motivation to perform such a role. Fact is, if I were capable of funding the electricity bill then I would do it in a heartbeat, but it would definitely require transparency as has been stated earlier in this conversation. Wikipedia runs these sort of fundraisers every year and they do it in a very obtrusive way, but they haven’t yet run out of money. Time to face reality. -mike
Re: Request for Funding our Electricity
On Thu, Jan 16, 2014 at 09:05:24AM -0800, Han Hwei Woo wrote: > Rather than raising prices on CD's/T-Shirts, how about allowing for > subscriptions? I've bought CD's and shirts in the past, but don't do so > regularly simply as it's not something I think/remember to do at every > release. However, I'd gladly signup to purchase a CD and T-Shirt every > release on an ongoing basis. Adding subscriptions is an interesting idea and something I would sign up for. Seems like they would - provide a source of sustainable/recurring income - falls within good taste and controlled by the project (not kickstarter, not ads in motd, etc.) - fits within an existing source of revenue (purchasing stuff on the site) An unknown is how much something like this would take away from real development; and whether it would be worth doing. I'm not an OS/kernel developer but have been creating web applications forever. I am willing to help with this or any other tasks so the OS hackers can continue to make OpenBSD, OpenSSH (and the rest of the family) the best tools out there. Jeff
Re: NIST-free crypto, autociphering, and libsodium (NaCl)
MJ [m...@sci.fi] wrote: > > On 16 Jan 2014, at 19.17, Chris Cappuccio wrote: > > OpenBSD has already began incorporating NaCl by bypassing OpenSSL entirely. > > Good news - perhaps my philosophy is ?why lay a lot of small bricks here and > there when you can lay a cornerstone and be done with it??. But perhaps I am > not taking all things into consideration. > OpenSSH is a project that gets used outside of OpenBSD so the way NaCl was incorporated makes sense to me... It allows OpenSSH to evolve the SSH standard with a minimum of fuss and contention. How new crypto primitives get incorporated into the rest of the system depends on how the people who work on those systems see things. > > > I can't speak for the architectural issues but I can't imagine that I or you > > are the only people imagining better cipher suites in the base system. > > You are certainly right - that would be just naive. The OpenBSD approach to > things is generally to make the interfaces as simple as possible, drop-dead > simple. This eliminates configuration mistakes. Take OpenNTPD for example - > it?s simply beautiful what has been done with the configuration interface. > > A systemwide autocipher engine device could easily be incorporated directly > in to PF, no? block all cipher hmac-sha1 (for example). > Block traffic with specific ciphers from traversing the network? That's sci.fi
Re: Request for Funding our Electricity
On Thu, Jan 16, 2014 at 10:58 AM, Daniel Cegiełka wrote: > Another example: Google will pay even more than $3000 for finding an > error in OpenSSH (Core infrastructure network services) - do they know > about your problems? > > http://googleonlinesecurity.blogspot.com/2013/10/going-beyond-vulnerability-rewards.html > > Daniel > Yes, we're aware of that program. However it still comes down to a bounty for bugfixes or change of some sort. so it's not a source of sustainable funding, unless we were to do something like introduce an annual quota of bugs and convincing looking churn for the sake of "finding them" every year. Would you want to depend upon software in your infrastructure that we were doing that to?
Re: Request for Funding our Electricity
2014/1/16 Jack Woehr : > Daniel Cegiełka wrote: >> >> http://goteo.org/project/gnupg-new-website-and-infrastructure >> >> Why do not you do such a campaign? > > > I think Theo has answered this previously. His point was that he doesn't > want to spend his time year after year > running campaigns. Being neither a politician nor a diplomat nor a > grantmaster, he wants a sustainable model. I agree that in the long term stable funding is needed. Today, however, we are faced with shut down risk. Another example: Google will pay even more than $3000 for finding an error in OpenSSH (Core infrastructure network services) - do they know about your problems? http://googleonlinesecurity.blogspot.com/2013/10/going-beyond-vulnerability-rewards.html Daniel
Re: Request for Funding our Electricity
On Thu, 16 Jan 2014 09:09:09 -0800 patrick keshishian wrote: > > The installer or man page asks for donations, how about the ssh login > > banner or initial output which might get perhaps 100s of thousands more > > eyefall? > > I see where this is headed: In app purchases! e.g., after > couple of failed attempts/insults by sudo, it prompts you > to purchase your 'access' for only $1.99! I can't see that happening when the code is OpenBSD's myself. I primarily meant client usage but server access from other clients too. This way you may get Windows, Linux, Android, hosting companies and OSX users etc.. So you use the client and it has a carefully considered one-liner like Keep ssh as secure and fast as possible. Why not donate today at www. or the sympathy vote OpenSSH has one of the lowest donation to user ratios of all open source software and the environment in which it was born within is currently under threat. Please support this critical piece of software at www. You could even have it show up once in 10 times or something. Just a thought from figuring it was one of the easiest tools OpenBSD has to reach out to many many people. Bad side is may take years to hit hosting companies that have Ubuntu LTS etc. but the initial shock factor may cause a winfall.
Hibernated system crashes during wakeup boot
Hi,
Hibernating does not work on my Cooler Master RC-K280-KKN1 desktop pc:
when apmd is running and
$ ZZZ
is invoked, the screen goes blank and the system appears
to be shutting down, not responding to keyboard input anymore. The disk
activity light is blinking, and after approx. 3 minutes the system
powers down. Booting the system then results in a system crash and ddb
is invoked; the following output was copied manually from the screen:
[...]
cpu6: ITLB 48 4KB entries fully associative, 24 4MB entries fully
associative
cpu6: DTLB 64 4KB entries fully associative, 64 4MB entries fully
associative
cpu6: smt 0, core 5, package 0
[distorted output]
cpu7: ITLB 48 4KB entries fully associative, 24 4MB entries fully
associative
[distorted output]
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 21, 24 pins
ioapic0: misconfigured as apic 0, remapped to apid 2
[distorted output]
dfdabu{l4t} >trap, code=0
Faulted in DDB; continuing...
dkernel: page fault trap, code=0
Faulted in DDB; continuing...
ddb{6}> x
mp_pdirpa+0x121c: 252cff48
ddb{6}> trace
mp_pdirpa() at mp_pdirpa+0x121c
Xresume_lapic_ipi() at Xresume_lapic_ipi+0x1b
--- interrupt ---
Bad frame pointer: 0x80002206af10
end trace framekernel: page fault trap, code=0
Faulted in DDB; continuing...
ddb{6}> show registers
ds 0x10
es 0x10
fs 0x10
gs 0x10
rdi 0x8018f000
rsi 0x1
rbp 0x80002206ae28
rbx 0x8
rdx 0x819fcd01 cpu_ca+0x1
rcx 0x8
rax 0x112fa mp_pdirpa+0x1213
r80
r90
r10 0x800022013f90
r11 0x8
r12 0
r13 0'panic: smashed stack in kprintf
At this point the system does not respond to keyboard input anymore.
Please let me know if more information is required.
OpenBSD 5.5-beta (GENERIC.MP) #267: Sun Jan 12 22:33:47 MST 2014
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8034123776 (7661MB)
avail mem = 7812063232 (7450MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf0100 (53 entries)
bios0: vendor Award Software International, Inc. version "F4" date
10/19/2012 bios0: Gigabyte Technology Co., Ltd. GA-78LMT-USB3
acpi0 at bios0: rev 0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP MSDM HPET MCFG TAMG APIC SSDT
acpi0: wakeup devices USB0(S3) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5
(S3) USB6(S3) SBAZ(S4) P2P_(S5) PCE2(S4) PCE3(S4) PCE4(S4) PCE5(S4) PCE6
(S4) PCE7(S4) PCE9(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpihpet0 at acpi0: 14318180 Hz acpimcfg0 at acpi0 addr 0xe000, bus
0-255 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD FX(tm)-8320 Eight-Core Processor , 3516.05 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,NODEID,TBM,TOPEXT,ITSC,BMI1
cpu0: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB
64b/line 16-way L2 cache, 8MB 64b/line 64-way L3 cache cpu0: ITLB 48
4KB entries fully associative, 24 4MB entries fully associative cpu0:
DTLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var
ranges, 88 fixed ranges cpu0: apic clock running at 200MHz cpu0: mwait
min=64, max=64, C-substates=0.0.0.0.0, IBE cpu1 at mainbus0: apid 1
(application processor) cpu1: AMD FX(tm)-8320 Eight-Core Processor ,
3515.55 MHz cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,NODEID,TBM,TOPEXT,ITSC,BMI1
cpu1: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB
64b/line 16-way L2 cache, 8MB 64b/line 64-way L3 cache cpu1: ITLB 48
4KB entries fully associative, 24 4MB entries fully associative cpu1:
DTLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu1: smt 0, core 3, package 0 cpu2 at mainbus0: apid 2 (application
processor) cpu2: AMD FX(tm)-8320 Eight-Core Processor , 3515.55 MHz
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,NODEID,TBM,TOPEXT,ITSC,BMI1
cpu2: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB
64b/line 16-way L2 cache, 8MB 64b/line 64-way L3 cache cpu2: ITLB 48
4KB entries fully associative, 24 4MB entries fully associative cpu2:
DTLB 64 4KB entries fully associative
Re: Request for Funding our Electricity
Daniel Cegiełka wrote: http://goteo.org/project/gnupg-new-website-and-infrastructure Why do not you do such a campaign? I think Theo has answered this previously. His point was that he doesn't want to spend his time year after year running campaigns. Being neither a politician nor a diplomat nor a grantmaster, he wants a sustainable model. -- Jack Woehr # "We commonly say we have no time when, Box 51, Golden CO 80402 # of course, we have all that there is." http://www.softwoehr.com # - James Mason, _The Art of Chess_, 1905
Re: Request for Funding our Electricity
http://goteo.org/project/gnupg-new-website-and-infrastructure Why do not you do such a campaign? Wow.. new website and infrastructure for GnuPG. Result: more then 24k USD in three weeks. So where OpenBSD/OpenSSH are worse than GnuPG? Guys, your problem is not the OpenBSD foundation, but the total lack of good marketing. Best regards, Daniel
Re: NIST-free crypto, autociphering, and libsodium (NaCl)
MJ [m...@sci.fi] wrote: > > Thanks Chris for your response and yes, you make a good point regarding > compatibility. > > I am by far a crypto expert, but these issues have been anyway on my mind as > of late. So bear with me, but would it be possible to switch /dev/crypto to > be an interface to an autocipher engine where both OpenSSL and NaCl ciphers > could be supported via e.g. /etc/autocipher.conf and then change all > crypto-enabled apps to use /dev/crypto and only /dev/crypto as the interface? > This approach could highly simplify the crypto operations in all of the > associated daemons/tools included in Base, as well Ports could slowly > converted to use the same interface. This is precisely the approach that is > being taken in Ethos operating system which is being designed from the ground > up to withstand cryptographic attack. Given the current status quo > (widespread compromise of our computing base by 3 letter agencies), this > starts to sound a bit less paranoid of an approach. > > Or have I got something wrong? Again, I am open to any sort of response. > OpenBSD has already began incorporating NaCl by bypassing OpenSSL entirely. I can't speak for the architectural issues but I can't imagine that I or you are the only people imagining better cipher suites in the base system.
Re: NIST-free crypto, autociphering, and libsodium (NaCl)
On 16 Jan 2014, at 18.23, Chris Cappuccio wrote: > > For instance, you may have noticed that OpenSSH is moving towards an > openssl-free mode by importing NaCl components directly? > > One problem with abandoning OpenSSL is that you lose SSL, TLS, (oh, and > everything has to be rewritten to use NaCl, and is now incompatible with > everything else.) So what you see with OpenSSH is the first attempt at > doing this, and it will only be compatible with other people also using > new OpenSSH. > > The issue is compatbility. I’m sorry for the typo: s/I am by far a crypto expert/I am far from being a crypto expert/ Thanks. -mike
Re: Request for Funding our Electricity
On 1/16/14, Kevin Chadwick wrote: > The installer or man page asks for donations, how about the ssh login > banner or initial output which might get perhaps 100s of thousands more > eyefall? I see where this is headed: In app purchases! e.g., after couple of failed attempts/insults by sudo, it prompts you to purchase your 'access' for only $1.99! (: --patrick > > -- > ___ > > 'Write programs that do one thing and do it well. Write programs to work > together. Write programs to handle text streams, because that is a > universal interface' > > (Doug McIlroy) > > In Other Words - Don't design like polkit or systemd > ___
Re: Request for Funding our Electricity
Rather than raising prices on CD's/T-Shirts, how about allowing for subscriptions? I've bought CD's and shirts in the past, but don't do so regularly simply as it's not something I think/remember to do at every release. However, I'd gladly signup to purchase a CD and T-Shirt every release on an ongoing basis.
Re: NIST-free crypto, autociphering, and libsodium (NaCl)
On 16 Jan 2014, at 18.23, Chris Cappuccio wrote: > For instance, you may have noticed that OpenSSH is moving towards an > openssl-free mode by importing NaCl components directly? > > One problem with abandoning OpenSSL is that you lose SSL, TLS, (oh, and > everything has to be rewritten to use NaCl, and is now incompatible with > everything else.) So what you see with OpenSSH is the first attempt at > doing this, and it will only be compatible with other people also using > new OpenSSH. > > The issue is compatbility. Thanks Chris for your response and yes, you make a good point regarding compatibility. I am by far a crypto expert, but these issues have been anyway on my mind as of late. So bear with me, but would it be possible to switch /dev/crypto to be an interface to an autocipher engine where both OpenSSL and NaCl ciphers could be supported via e.g. /etc/autocipher.conf and then change all crypto-enabled apps to use /dev/crypto and only /dev/crypto as the interface? This approach could highly simplify the crypto operations in all of the associated daemons/tools included in Base, as well Ports could slowly converted to use the same interface. This is precisely the approach that is being taken in Ethos operating system which is being designed from the ground up to withstand cryptographic attack. Given the current status quo (widespread compromise of our computing base by 3 letter agencies), this starts to sound a bit less paranoid of an approach. Or have I got something wrong? Again, I am open to any sort of response. -mike
Re: unreliable connections
This issue is still with me. Sporadically the connection will fail, and a connection attempt immediately after the failure will (so far) always work. Again the problem is only with this one remote firewall, all of the others are fine. the hardware is virtually identical, similar versions of the Supermicro 5015A boxes. Also note that said problem box was used in another location with an older version of OpenBSD without said issues. It's possible the ISP's cable modem might be to blame but I'd like to have something to go on before I point that finger. Could really use some ideas on how to troubleshoot this. Chris On Sun, Dec 29, 2013 at 9:56 PM, Chris Smith wrote: > I'm having a problem connecting with (and through) one OpenBSD box. > Both ends are running OpenBSD -current (-current as of last weekend) > and I've had the issue through a couple of months of various builds of > -current. > > The problem occurs whether I'm connecting directly to the remote > OpenBSD box (firewall) or connecting through it via a redirect to an > inside box. > > The connections attempts are all coming from a Linux box inside my > network (and i'm running a recent -current as my firewall), and > connections to and through several other remote OpenBSD boxes > (although not running a recent -current) all work 100% of the time. > > With the problem box sometimes the connection never completes. After > the failed connection attempt subsequent connection attempts work > fine, it's only after some time that the problem may arise again. > > For example if I attempt to ssh to the problem box I'm greeted with a > blank line: > > $ ssh problem_box > > > > And after some minutes, I'l finally receive this: > > ssh_exchange_identification: read: Connection timed out > > > From another terminal I can then shell in (whether or not I kill the > first attempt). The connection states reported are (all address have > been munged): > my local firewall: > > all tcp 51.213.211.197:22 <- 172.25.12.66:44291 ESTABLISHED:ESTABLISHED > all tcp 76.112.133.216:54348 (172.25.12.66:44291) -> 51.213.211.197:22 > ESTABLISHED:ESTABLISHED > all tcp 51.213.211.197:22 <- 172.25.12.66:44292 ESTABLISHED:ESTABLISHED > all tcp 76.112.133.216:58306 (172.25.12.66:44292) -> 51.213.211.197:22 > ESTABLISHED:ESTABLISHED > > > the remote firewall: > > all tcp 51.213.211.197:22 <- 76.112.133.216:54348 SYN_SENT:ESTABLISHED > all tcp 51.213.211.197:22 <- 76.112.133.216:58306 > ESTABLISHED:ESTABLISHED > > > The "hung" connection is the "SYN_SENT:ESTABLISHED" one and it stays > that way for some time, although my local firewall believes it to be > established. > > I've seen the same issue with an RDP connection to an inside Windows > box via a redirect. Sometimes the first attempt will not connect, if I > kill it and try again, voila, it works. > > The critical part is that my rsync backup to an internal box fails > about every third night due to this issue. As I rsync two different > paths (one and then the other) on the remote daemon the first path > will fail sporadically, the second path always completes. Have none of > these issues with other accounts (but as mentioned the OpenBSD > versions on those firewalls are a bit older). > > Any assistance on resolving this would be much appreciated. > > Thank you, > > Chris
Re: Is my 5.4 CD ok?
Mario wrote: > Also nowhere on CD2 I can find the soundtrack. I suppose that should be \ > easy. I would really need a song at the moment. > > -- > Mario It's not a file. It's CD track 2. Try putting it in a CD player. To play it on your computer, see cdio(1) in base or a number of other programs in packages and other OSes. - Martin
Re: Is my 5.4 CD ok?
Only a small subset of the packages fit on the CD. Emacs is not on the CD afaik. You can set multiple sources in your PKG_PATH variable (colon deliminated), so set the second one to be a mirror. See man pkg_add. On Thu, Jan 16, 2014 at 5:28 PM, Mario wrote: > Hi list. > > I know you are all busy discussing electricity issues but maybe one of you > can take a moment to answer this. > > Browsing my new CDs for first time ever, I am a little confused and I am > seeking clarification. Is the following normal? Because when I think > about it, can really over 14,000 packages (amd64 + hppa) fit on a CD. I > am puzzled. > > marst:349$ pwd > /mnt/5.4/packages/amd64 > marst:350$ ls -l > total 25238 > -r--r--r-- 1 root wheel 539 Aug 5 17:25 TRANS.TBL > -r--r--r-- 1 root wheel 125468 Jul 29 13:26 bzip2-1.0.6p0.tgz > -r--r--r-- 1 root wheel 674979 Jul 29 13:26 curl-7.26.0p3.tgz > -r--r--r-- 1 root wheel 7556487 Jul 29 13:26 gettext-0.18.2p3.tgz > -r--r--r-- 1 root wheel 2012934 Jul 29 13:26 gnupg-1.4.13p0.tgz > -r--r--r-- 1 root wheel 159 Aug 5 17:22 index.txt > -r--r--r-- 1 root wheel 1521545 Jul 29 13:26 libiconv-1.14p0.tgz > -r--r--r-- 1 root wheel 264257 Jul 29 13:26 libidn-1.27.tgz > -r--r--r-- 1 root wheel 280021 Jul 29 13:26 rsync-3.0.9p3.tgz > -r--r--r-- 1 root wheel 165840 Jul 29 13:26 unzip-6.0p2.tgz > -r--r--r-- 1 root wheel 322276 Jul 29 13:26 xz-5.0.5.tgz > marst:351$ > > I guess the question is are all the binaries supposed to be on CD because > if I follow instructions as per booklet: > > % su > Password : > # mount /dev/cd0a /mnt > # /mnt/5.4/packages/amd64 > # pkg_add emacs-21.4p23.tgz > > That's not working. Well it worked when my $PKG_PATH was still set on ftp > but I suppose PKG_PATH is supposed to be set to the CD path. > > Also nowhere on CD2 I can find the soundtrack. I suppose that should be > easy. I would really need a song at the moment. > > -- > Mario
Re: Automounting with hotplugd on OpenBSD
I had a usb that wouldn't mount so I've added logging and support for "unused" sd*c disklabels for vfat, ext2/3/4 and ntfs via blkid. I think newfs ffs writes the disklabel so you don't get unused for sd*c and so don't need a blkid tool. It's three times as long now though so if anyones interested mail me and I'll attach it privately. p.s. If anyone has a native alternative to blkid I'd appreciate the pointer.
Re: [Bulk] Is my 5.4 CD ok?
previously on this list Mario contributed: > # mount /dev/cd0a /mnt > # /mnt/5.4/packages/amd64 > # pkg_add emacs-21.4p23.tgz You could set the PKG_PATH Did you cd /mnt/5.4/packages/amd64 -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___
Re: NIST-free crypto, autociphering, and libsodium (NaCl)
MJ [m...@sci.fi] wrote: > Hello, > > I would like to inquire as to which OpenBSD RELEASE will offer the possibility > to avoid NIST crypto for everything in Base (isakmpd, openssh, openssl, https, > nginx being the key items in mind)? > > BTW, looks like things are heading in the right direction > (http://www.slideshare.net/yandex/rubsd2013-mikeben) > > And, of course, the autocipher engine would be powered by libsodium (NaCl). > > Thoughts, comments, insults, etc, are all welcome! The quantum computer is > coming soon to a theatre near you. > For instance, you may have noticed that OpenSSH is moving towards an openssl-free mode by importing NaCl components directly? One problem with abandoning OpenSSL is that you lose SSL, TLS, (oh, and everything has to be rewritten to use NaCl, and is now incompatible with everything else.) So what you see with OpenSSH is the first attempt at doing this, and it will only be compatible with other people also using new OpenSSH. The issue is compatbility.
Re: Is my 5.4 CD ok?
There isn't any reason all the packages couldn't fit on a cd. Most are just a few bytes to a few kb, and a small number are into a few MB. Browsing the package list (for i386), it looks like the largest one might be 4mb. You should set your pkg path to the cd if you want to install from there, *export PKG_PATH=/mnt/cdrom/5.4/packages/`machine -a`/*(change to the mount point of your cdrom) Personally, I prefer to just set the pkg path to an http mirror as it is just as fast, or often faster, than cdrom and I don't have to have the cd on hand. On Thu, Jan 16, 2014 at 7:28 PM, Mario wrote: > Hi list. > > I know you are all busy discussing electricity issues but maybe one of you > can take a moment to answer this. > > Browsing my new CDs for first time ever, I am a little confused and I am > seeking clarification. Is the following normal? Because when I think > about it, can really over 14,000 packages (amd64 + hppa) fit on a CD. I > am puzzled. > > marst:349$ pwd > /mnt/5.4/packages/amd64 > marst:350$ ls -l > total 25238 > -r--r--r-- 1 root wheel 539 Aug 5 17:25 TRANS.TBL > -r--r--r-- 1 root wheel 125468 Jul 29 13:26 bzip2-1.0.6p0.tgz > -r--r--r-- 1 root wheel 674979 Jul 29 13:26 curl-7.26.0p3.tgz > -r--r--r-- 1 root wheel 7556487 Jul 29 13:26 gettext-0.18.2p3.tgz > -r--r--r-- 1 root wheel 2012934 Jul 29 13:26 gnupg-1.4.13p0.tgz > -r--r--r-- 1 root wheel 159 Aug 5 17:22 index.txt > -r--r--r-- 1 root wheel 1521545 Jul 29 13:26 libiconv-1.14p0.tgz > -r--r--r-- 1 root wheel 264257 Jul 29 13:26 libidn-1.27.tgz > -r--r--r-- 1 root wheel 280021 Jul 29 13:26 rsync-3.0.9p3.tgz > -r--r--r-- 1 root wheel 165840 Jul 29 13:26 unzip-6.0p2.tgz > -r--r--r-- 1 root wheel 322276 Jul 29 13:26 xz-5.0.5.tgz > marst:351$ > > I guess the question is are all the binaries supposed to be on CD because > if I follow instructions as per booklet: > > % su > Password : > # mount /dev/cd0a /mnt > # /mnt/5.4/packages/amd64 > # pkg_add emacs-21.4p23.tgz > > That's not working. Well it worked when my $PKG_PATH was still set on ftp > but I suppose PKG_PATH is supposed to be set to the CD path. > > Also nowhere on CD2 I can find the soundtrack. I suppose that should be > easy. I would really need a song at the moment. > > -- > Mario
Is my 5.4 CD ok?
Hi list. I know you are all busy discussing electricity issues but maybe one of you can take a moment to answer this. Browsing my new CDs for first time ever, I am a little confused and I am seeking clarification. Is the following normal? Because when I think about it, can really over 14,000 packages (amd64 + hppa) fit on a CD. I am puzzled. marst:349$ pwd /mnt/5.4/packages/amd64 marst:350$ ls -l total 25238 -r--r--r-- 1 root wheel 539 Aug 5 17:25 TRANS.TBL -r--r--r-- 1 root wheel 125468 Jul 29 13:26 bzip2-1.0.6p0.tgz -r--r--r-- 1 root wheel 674979 Jul 29 13:26 curl-7.26.0p3.tgz -r--r--r-- 1 root wheel 7556487 Jul 29 13:26 gettext-0.18.2p3.tgz -r--r--r-- 1 root wheel 2012934 Jul 29 13:26 gnupg-1.4.13p0.tgz -r--r--r-- 1 root wheel 159 Aug 5 17:22 index.txt -r--r--r-- 1 root wheel 1521545 Jul 29 13:26 libiconv-1.14p0.tgz -r--r--r-- 1 root wheel 264257 Jul 29 13:26 libidn-1.27.tgz -r--r--r-- 1 root wheel 280021 Jul 29 13:26 rsync-3.0.9p3.tgz -r--r--r-- 1 root wheel 165840 Jul 29 13:26 unzip-6.0p2.tgz -r--r--r-- 1 root wheel 322276 Jul 29 13:26 xz-5.0.5.tgz marst:351$ I guess the question is are all the binaries supposed to be on CD because if I follow instructions as per booklet: % su Password : # mount /dev/cd0a /mnt # /mnt/5.4/packages/amd64 # pkg_add emacs-21.4p23.tgz That's not working. Well it worked when my $PKG_PATH was still set on ftp but I suppose PKG_PATH is supposed to be set to the CD path. Also nowhere on CD2 I can find the soundtrack. I suppose that should be easy. I would really need a song at the moment. -- Mario
Re: Request for Funding our Electricity
The installer or man page asks for donations, how about the ssh login banner or initial output which might get perhaps 100s of thousands more eyefall? -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___
Re: Request for Funding our Electricity
On Wed, Jan 15, 2014 at 09:55:04PM +, Franchini Fabien wrote:
> [...]
> I suggest to write a letter to theses companies who are known to using OpenBSD
> or other product-related like OpenSSH. In this letter we can explain (as the
> first
> post from Theo) our issue. I'm sure they can give us an hand if they know our
> problem. And in my opinion, ONLY a company can give us a long-term solution.
> [...]
Maybe to inject a further point into this discussion... One of these
companies is Apple. They replaced ipfw with pf in recent releases of
Darwin (see [0]).
Since, with Darwin being Open Source, they seem not entirely against
spending resources on Open Source Software, and they profit in no small
margin from the OpenBSD project and its "satellites" like OpenSSH, they
might be a good recipient for a polite letter in request of help. Not
the least because they could use their assistance in their marketing
("Look how cool we are, we are paying them their electricity!").
> [...]
> Sorry I'm not a native english-speaker and I can't help to write a letter
> like that
> but I'm sure that's realistic solution.
> [...]
Same for me. Still, if this is not entirely off the table, I'd be
willing to draft something.
> [...]
> Another solution is to approach the *BSD community. FreeBSD are bigger
> than us and how they'll solve these kind of problem ?
> [...]
Fewer architectures, more corporate backing, I'd say.
[0]:
https://developer.apple.com/library/mac/documentation/darwin/reference/manpages/man8/ipfw.8.html
--
Gregor Best
Re: Request for Funding our Electricity
On Thu, Jan 16, 2014 at 1:10 PM, Sia Lang wrote: > Virtual machines/emus and canadian cross builds should be able to reduce > the amount of iron, no? > I don't think virtual machines are the solution: I see them as another buggy ecosystem on which developers will try to debug their code. A lot of people on this thread are suggesting to remove/reduce platforms OpenBSD supports, and it seems to me it is pretty clear the project will not do that (and I appreciate the decision). We have to deal with supporting OpenBSD, not trying to shrink the project. Luca
Re: Process monitoring
Em 16-01-2014 02:59, Cyrus escreveu: > I am looking for ways to monitor processes on the system in the long > term. It would be helpful to get a bigger picture about how the > individual processes of users contribute to load averages. It would go a > long way in diagnosing problems related to load. > Cyrus, There are lots of ways to accomplish this. I personally use symon and syweb. They are both in ports/packages and work nicely. There are other options, like nagios with nagiosgraph, munin, etc. There are lots of choices. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
NIST-free crypto, autociphering, and libsodium (NaCl)
Hello, I would like to inquire as to which OpenBSD RELEASE will offer the possibility to avoid NIST crypto for everything in Base (isakmpd, openssh, openssl, https, nginx being the key items in mind)? BTW, looks like things are heading in the right direction (http://www.slideshare.net/yandex/rubsd2013-mikeben) As it stands, there is currently cipher-suite negotiation / configuration coded into every single crypto-enabled tool / daemon and its a bit of a mess and a headache to manage it all. Would it be good to start to think about having a single, system-wide cipher-suite negotiation configuration and socket? interface and removing all this mess from things like isakmpd, openssh, openssl, httpd, nginx, etc? For example, one could specify a preferred ordered list of cipher suites and ones that arent listed would be completely avoided at the system level. This could, for example, eliminate static algorithm configuration in ipsec.conf and instead start negotiation traveling down the ordered list until either success or end of list. This method would provide an abstract interface to avoid future version downgrade attacks, i.e. no need to update anything other than the configuration file. And, of course, the autocipher engine would be powered by libsodium (NaCl). Thoughts, comments, insults, etc, are all welcome! The quantum computer is coming soon to a theatre near you. -mike
Re: Request for Funding our Electricity
hmm, on Wed, Jan 15, 2014 at 08:14:24PM +0100, Peter J. Philipp said that > # pkg_add somepackage > ... > This package's buildtime was generously donated by Peter J. Philipp. > # ads in openbsd? you must be out of your mind. what next, adblock for openbsd? -f -- why do they call it a tv set when you only get one?
Re: Request for Funding our Electricity
Virtual machines/emus and canadian cross builds should be able to reduce the amount of iron, no? On Thu, Jan 16, 2014 at 12:53 PM, Theo de Raadt wrote: > >Through the history of openbsd there have been architectures in which > more bugs have been found and some in which fewer bugs have appeared. > > That is not true. > > >Then maybe the number of bugs for an architecture can be matched to the > power-on-time for the machines for that architecture. > > Maybe. Probably need them on to prove or disprove the point. > > >For example, if 1% of the total number of bugs in the history of openbsd > have appeared on architecture x, then it's likely that it will continue to > be so, then all the machines for that architecture should be powered on > just 1% of the time. > > Another great advantage here is that all the pesky developers who love > those machines will go away, and we'll only need to run on the best > architectures (which of course, are big endian). > > >Then perform that analysis on all architectures to make a more better use > of energy. And that's it. > > It's so simple. Why didn't I think of it.
Re: Request for Funding our Electricity
>Through the history of openbsd there have been architectures in which more >bugs have been found and some in which fewer bugs have appeared. That is not true. >Then maybe the number of bugs for an architecture can be matched to the >power-on-time for the machines for that architecture. Maybe. Probably need them on to prove or disprove the point. >For example, if 1% of the total number of bugs in the history of openbsd have >appeared on architecture x, then it's likely that it will continue to be so, >then all the machines for that architecture should be powered on just 1% of >the time. Another great advantage here is that all the pesky developers who love those machines will go away, and we'll only need to run on the best architectures (which of course, are big endian). >Then perform that analysis on all architectures to make a more better use of >energy. And that's it. It's so simple. Why didn't I think of it.
Re: Request for Funding our Electricity
> El 20/12/2013, a las 18:08, Theo de Raadt escribió: > > I am resending this request for funding our electricity bills because > it is not yet resolved. > > We really need even more funding beyond that, because otherwise all of > this is simply unsustainable. This request is the smallest we can > make. > > --- > > Hi everyone. > > The OpenBSD project uses a lot of electricity for running the > development and build machines. A number of logistical reasons > prevents us from moving the machines to another location which might > offer space/power for free, so let's not allow the conversation to go > that way. > > We are looking for a Canadian company who will take on our electrical > expenses -- on their books, rather than on our books. We would be > happiest to find someone who will do this on an annual recurring > basis. > > That way the various OpenBSD efforts can be supported, yet written off > as an off-site operations cost by such a company. If we reduce this > cost, it will leave more money for other parts of the project. > > We think that a Canadian company is the best choice for accounting > reasons. If a company in some other jurisdiction feels they can also > do this successfully, we'd be very happy to hear from them as well. > > I am not going to disclose the actual numbers here. Please contact me > for details if serious. > > Thanks. Well, we know that energy prices will continue to increase, not decrease, so this will be harder in the future. Whit this in mind, why not look for a strategy to save up on energy costs. Something like this: Through the history of openbsd there have been architectures in which more bugs have been found and some in which fewer bugs have appeared. Then maybe the number of bugs for an architecture can be matched to the power-on-time for the machines for that architecture. For example, if 1% of the total number of bugs in the history of openbsd have appeared on architecture x, then it's likely that it will continue to be so, then all the machines for that architecture should be powered on just 1% of the time. Then perform that analysis on all architectures to make a more better use of energy. And that's it.
