Re: openbsd's future plans?
Ok, please stop that now. Those pseudo-witty replies are getting quite annoying. Thanks.
Re: openbsd's future plans?
Hello! On Tue, Feb 07, 2006 at 10:33:19PM +, Miod Vallat wrote: i think we should rewrite the kernel in java since it has good support for threads. Remember we opted for C++ during c2k2 (or was it c2k3), but not until ddb has proper name demangling code. *rolls eyes* Yuck. Miod Kind regards, Hannah.
Re: openbsd's future plans?
Quoth Marius Van Deventer - Umzimkulu On Wednesday 08 February 2006 04:20, Diana Eichert wrote: On Tue, 7 Feb 2006, Miod Vallat wrote: i think we should rewrite the kernel in java since it has good support for threads. Remember we opted for C++ during c2k2 (or was it c2k3), but not until ddb has proper name demangling code. Miod I cast a vote for re-writing the kernel in Ruby because of it's robust threads implementation. You are misled, Diana. The kernel should be written in SNOBOL4. --STeve Andre' Intercal!!! It is soo comforting to see that this topic is getting the close attention it so richly deserves. Spaghetti code -- at least it looks like lots of threads.
Re: openbsd's future plans?
On 08/02/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Quoth Marius Van Deventer - Umzimkulu On Wednesday 08 February 2006 04:20, Diana Eichert wrote: On Tue, 7 Feb 2006, Miod Vallat wrote: i think we should rewrite the kernel in java since it has good support for threads. Remember we opted for C++ during c2k2 (or was it c2k3), but not until ddb has proper name demangling code. Miod I cast a vote for re-writing the kernel in Ruby because of it's robust threads implementation. You are misled, Diana. The kernel should be written in SNOBOL4. --STeve Andre' Intercal!!! It is soo comforting to see that this topic is getting the close attention it so richly deserves. Spaghetti code -- at least it looks like lots of threads. In the end I think most users don't care what language the kernel is written in as long as they can find it in the ports tree. [EMAIL PROTECTED] cd /usr/ports/ [EMAIL PROTECTED] make search key=kernel [EMAIL PROTECTED] When it's in there I might start to use it also. -- Tony Sarendal - [EMAIL PROTECTED] IP/Unix -= The scorpion replied, I couldn't help it, it's my nature =-
Re: openbsd's future plans?
On Tue, 7 Feb 2006 14:01:38 -0800 Ted Unangst [EMAIL PROTECTED] wrote: On 2/7/06, Antonios Anastasiadis [EMAIL PROTECTED] wrote: I have been wondering what are the openbsd team's long term-plans (if any at all,of course) regarding future smp support. I am aware that openbsd currently supports smp under the big kernel lock, which offers some advantages for userland applications but generally things like interrupt and io load don't scale at all. I understand it is an enormous task, judging by the other os'es struggle to remove the bkl by various techniques. What are the developers thinking about the future regarding this matter, and what are their opinions about the other os'es paths as well. i think we should rewrite the kernel in java since it has good support for threads. Weee! I think OpenBSD kernel should be implemented in hardware part! -- God is real, unless declared integer.
Re: openbsd's future plans?
On 2/8/06, Diana Eichert [EMAIL PROTECTED] wrote: I cast a vote for re-writing the kernel in Ruby because of it's robust threads implementation. No no no, OpenBSD should be rewritten with the new GPL v3 as soon as it stabilizes. It seems much more robust than the previous releases, and it is already very good at spawning threads. Eric.
Re: openbsd's future plans?
At 06:40 PM 2/7/06, STeve Andre' wrote: On Wednesday 08 February 2006 04:20, Diana Eichert wrote: On Tue, 7 Feb 2006, Miod Vallat wrote: i think we should rewrite the kernel in java since it has good support for threads. Remember we opted for C++ during c2k2 (or was it c2k3), but not until ddb has proper name demangling code. Miod I cast a vote for re-writing the kernel in Ruby because of it's robust threads implementation. You are misled, Diana. The kernel should be written in SNOBOL4. Coincidentally (?) I came across a SNOBOL4 book yesterday - cleaning out the basement.
Re: openbsd's future plans?
On 02/08/06 14:56, Nickolay A Burkov wrote: Weee! I think OpenBSD kernel should be implemented in hardware part! Of course, big gate array and stellar performance. So the language should be VHDL! +++chefren
Re: openbsd's future plans?
On Wednesday, February 8, chefren wrote: On 02/08/06 14:56, Nickolay A Burkov wrote: Weee! I think OpenBSD kernel should be implemented in hardware part! Of course, big gate array and stellar performance. So the language should be VHDL! Ugh! That's akin to using C++ and C# at the same time. Use Verilog or something a little more sane... :) --Toby.
Re: openbsd's future plans?
On 02/08/06 14:56, Nickolay A Burkov wrote: Weee! I think OpenBSD kernel should be implemented in hardware part! Of course, big gate array and stellar performance. So the language should be VHDL! +++chefren Just write the OS in SQL PL and move on! Geeeze ..
Re: openbsd's future plans?
It's been a while since I've had the opportunity to code in RPG. Implementing an SMP kernel in an old IBM report generating language is an interesting challenge, and would open up the possibility of running OpenBSD 4.0 on card-sorting machines.
Re: openbsd's future plans?
On Wed, 08 Feb 2006 11:35:30 -0700 Tobias Weingartner [EMAIL PROTECTED] wrote: On Wednesday, February 8, chefren wrote: On 02/08/06 14:56, Nickolay A Burkov wrote: Weee! I think OpenBSD kernel should be implemented in hardware part! Of course, big gate array and stellar performance. So the language should be VHDL! Ugh! That's akin to using C++ and C# at the same time. Use Verilog or something a little more sane... :) You all must be out of your minds...just forget all the platforms and everything, and rewrite it all in MIPS R12k assembler. ;-) --Toby. -- Humppa is a serious thing! [demime 1.01d removed an attachment of type application/pgp-signature]
Re: openbsd's future plans?
On Wed, 8 Feb 2006, Tobias Weingartner wrote: On Wednesday, February 8, chefren wrote: On 02/08/06 14:56, Nickolay A Burkov wrote: Weee! I think OpenBSD kernel should be implemented in hardware part! Of course, big gate array and stellar performance. So the language should be VHDL! Ugh! That's akin to using C++ and C# at the same time. Use Verilog or something a little more sane... :) --Toby. and I know just the card to do it, http://www.metanetworks.org/products.html
Re: openbsd's future plans?
On 02/08/06 21:48, Diana Eichert wrote: On Wed, 8 Feb 2006, Tobias Weingartner wrote: On Wednesday, February 8, chefren wrote: On 02/08/06 14:56, Nickolay A Burkov wrote: Weee! I think OpenBSD kernel should be implemented in hardware part! Of course, big gate array and stellar performance. So the language should be VHDL! Ugh! That's akin to using C++ and C# at the same time. Use Verilog or something a little more sane... :) --Toby. and I know just the card to do it, http://www.metanetworks.org/products.html No no no, those cards have not enough memory shameless plug we manufacture one with up to 2x 256MB SDRAM with fully independent address and data busses: http://idd.nl/ft/pci.jpg A bigger gate array can be mounted but I presume we still need a micro, eh no, nano kernel version of OpenBSD to get it running. +++chefren
Re: openbsd's future plans?
On Tue, Feb 07, 2006 at 08:51:31PM -0500, Nick Holland wrote: digressed a bit (I'm sure that surprises everyone here that I'd do that), Shocked! Anyway, to folks who are wondering about SMP, all you have to do is notice how little traffic there is on smp@ and how (relatively) few commits there are that deal with smp. Writing quality SMP code is a *monumentous* task. I work for a contracts-based software shop, and if I had to bid that one, I'd bid hundreds of man-hours, if not thousands. If the core team of OpenBSD developers is 50 people, there might be 4-5 people who could concentrate all their OpenBSD efforts on this (just picking those numbers of of thin air) If it takes 5000 man-hours to get scalable, robust SMP code written, then we're talking 25 weeks of full-time work for each of those 5 people. I don't know about you guys, but I can't take 25 weeks off from work, and my spare time each week adds up to about to *maybe* 20-25 hours, and that's *everything*. If I were to say ok, I'll contribute 1000 hours, and I totally ignored my wife and kids, my parents, her parents, all my friends, community activites, etc., I'd be doing nothing but sleeping, working my paid job, and working OpenBSD for 40-50 weeks. It would take a year to get what folks are asking for --- and that's assuming 4 other people doing exactly the same thing. My estimates could be off, but I think the ballpark is good enough to get the point across. Even if I'm off by 2x, that's still 6 months of 5 people doing *nothing else* but OpenBSD. [demime 1.01d removed an attachment of type application/pgp-signature]
Re: openbsd's future plans?
On Wed, 8 Feb 2006, chefren wrote: and I know just the card to do it, http://www.metanetworks.org/products.html No no no, those cards have not enough memory shameless plug we manufacture one with up to 2x 256MB SDRAM with fully independent address and data busses: http://idd.nl/ft/pci.jpg A bigger gate array can be mounted but I presume we still need a micro, eh no, nano kernel version of OpenBSD to get it running. +++chefren Can you do line rate 10G/OC192 with your card? diana
Re: openbsd's future plans?
On Wed, 2006-02-08 at 15:21:19 -0700, Diana Eichert proclaimed... Can you do line rate 10G/OC192 with your card? Last I heard only Endace could; and they're not supported.
Re: openbsd's future plans?
Now I don't feel at all bad about not being able to run bsd.mp on my clunky old dual-266 Dell PowerEdge 4200. Pah! Programmers nowadays, no idea of commitment! ;) On Tue, 2006-02-07 at 22:36 -0600, Benjamin Collins wrote: On Tue, Feb 07, 2006 at 08:51:31PM -0500, Nick Holland wrote: digressed a bit (I'm sure that surprises everyone here that I'd do that), Shocked! Anyway, to folks who are wondering about SMP, all you have to do is notice how little traffic there is on smp@ and how (relatively) few commits there are that deal with smp. Writing quality SMP code is a *monumentous* task. I work for a contracts-based software shop, and if I had to bid that one, I'd bid hundreds of man-hours, if not thousands. If the core team of OpenBSD developers is 50 people, there might be 4-5 people who could concentrate all their OpenBSD efforts on this (just picking those numbers of of thin air) If it takes 5000 man-hours to get scalable, robust SMP code written, then we're talking 25 weeks of full-time work for each of those 5 people. I don't know about you guys, but I can't take 25 weeks off from work, and my spare time each week adds up to about to *maybe* 20-25 hours, and that's *everything*. If I were to say ok, I'll contribute 1000 hours, and I totally ignored my wife and kids, my parents, her parents, all my friends, community activites, etc., I'd be doing nothing but sleeping, working my paid job, and working OpenBSD for 40-50 weeks. It would take a year to get what folks are asking for --- and that's assuming 4 other people doing exactly the same thing. My estimates could be off, but I think the ballpark is good enough to get the point across. Even if I'm off by 2x, that's still 6 months of 5 people doing *nothing else* but OpenBSD. [demime 1.01d removed an attachment of type application/pgp-signature]
Re: openbsd's future plans?
On Wed, 8 Feb 2006, eric wrote: On Wed, 2006-02-08 at 15:21:19 -0700, Diana Eichert proclaimed... Can you do line rate 10G/OC192 with your card? Last I heard only Endace could; and they're not supported. the metanetworks 10G can
Re: openbsd's future plans?
On Wed, 2006-02-08 at 16:04:22 -0700, Diana Eichert proclaimed... the metanetworks 10G can Hmm, no kidding. Do you know of anything that is rather lossless just for 1G networks (optical)? We may be throwing some taps out and the usually intel cards are very lossy.
Re: openbsd's future plans?
On Wed, 8 Feb 2006, eric wrote: On Wed, 2006-02-08 at 16:04:22 -0700, Diana Eichert proclaimed... the metanetworks 10G can Hmm, no kidding. Do you know of anything that is rather lossless just for 1G networks (optical)? We may be throwing some taps out and the usually intel cards are very lossy. The MTP-10G can actually filter in both directions at 10G. Livio made a short presentation at the Internet2 Joint Techs Workshop today. A gentleman (I think it was Arien Vijn, I'm real bad with names) from AMS-IX (Amsterdam Internet Exchange) presented with Livio their plans for the 10G card at AMS-IX. The Force10 cards, Force10 bought Metanetworks in Nov 2005, are designed more for filtering. Per my request Livio created an OpenBSD driver for the card, so you can use either Linux or OpenBSD. diana
Re: openbsd's future plans?
On Wed, 8 Feb 2006, eric wrote: SNIP Hmm, no kidding. Do you know of anything that is rather lossless just for 1G networks (optical)? We may be throwing some taps out and the usually intel cards are very lossy. Oops, I just re-read your original post. They have a new 1G card with http://www.metanetworks.org/products.html with varied physical interface support. diana
Re: openbsd's future plans?
On 02/09/06 00:04, Diana Eichert wrote: On Wed, 8 Feb 2006, eric wrote: On Wed, 2006-02-08 at 15:21:19 -0700, Diana Eichert proclaimed... Can you do line rate 10G/OC192 with your card? Last I heard only Endace could; and they're not supported. the metanetworks 10G can Since also OC192 was mentioned I believe it's not so easy to say without further information. Lets put in the OpenBSD plug first: Yes OpenBSD is fully supported with the FT-x card. Disclaimer: I didn't know anything of metanetworks http://www.metanetworks.org/ and their products before I saw the link on this list a few hours ago. Up to a minute ago I never heard of Endace http://www.endace.com/ . Claimer: I work for IDD http://idd.nl/ and know a thing or two of our card and if if I don't know it I can ask people here about the last details. http://www.metanetworks.org/products.html http://www.endace.com/images/E2DAG6.2Lge.jpg http://idd.nl/ft/pci.jpg As probably anyone here can see on the pictures there is a big difference between the cards. The IDD card has large memory banks which seem to lack on the other cards (I might be wrong on this, couldn't see the back of the cards on the pictures.). These memory banks of up to 256MB per channel allow us to unpack not only Gigabit Ethernet, Packet over Sonet but also MPLS, ATM and L2TP for two channels at up to 2.5Gbps in real time. As far as I know it's the only card in the world of this type with that arrangement and flexibility. Other differences I see: Metanetworks claims Jumbo frames, we don't (don't know if that's a hard limit, no customer has ever asked for it). As far as I see the Endace card and our card only monitor, we do repeat a retimed to Sonet specs optical signal. Metaworks claims to be able to Filter out viruses and worms with approximately 1 5s latency and wirespeed URI decoding I cannot take that seriously without further specifications. [(URI as being URL like http:// ? And where? also from compressed http streams too?] We manufacture our card on request of Dutch internet providers for lawful interceptions, tapping their networks. (In the Netherlands providers tap and deliver the tapped info to a government institution named ULI (formerly LIO). ULI delivers to police and intelligence services. So the government doesn't tap itself, as much checks and balances as you can think of.) The card is a good solution for a few formerly almost untappable holes in their networks. By the way, designing such a card is almost only a matter of both knowledge and skill, we did it in 6 weeks flat, (one small and fortunately fixable bug because of a bad specified part, nobody is perfect...). Manufacturing is a disaster, pointless to start with the good old soldering iron (that's like asking Dave Feustel to code a more secure new OpenBSD kernel without the big lock...), the ball-grid arrays and fine pitch high-speed parts need state of the art robot handling, soldering and x-ray inspection. Assembly of a single card costs about 2000E excluding the setup costs and without any parts. Very few assembly companies can do this reliably in small quantities. Software took some more time but we have our own quite complete library of single cycle algorithms now. With modern gate arrays and memory interfaces 2x 10GE seems no serious problem to me, getting serious customers for it, need interesting quantities, is. And above all... Understanding almost all details of the Internet with a small team and getting it work is definitely fun! +++chefren end of plug, I will donate if something serious comes from this
Re: openbsd's future plans?
On 2/7/06, Antonios Anastasiadis [EMAIL PROTECTED] wrote: I have been wondering what are the openbsd team's long term-plans (if any at all,of course) regarding future smp support. I am aware that openbsd currently supports smp under the big kernel lock, which offers some advantages for userland applications but generally things like interrupt and io load don't scale at all. I understand it is an enormous task, judging by the other os'es struggle to remove the bkl by various techniques. What are the developers thinking about the future regarding this matter, and what are their opinions about the other os'es paths as well. i think we should rewrite the kernel in java since it has good support for threads.
Re: openbsd's future plans?
Hello! On Tue, Feb 07, 2006 at 02:01:38PM -0800, Ted Unangst wrote: [...] i think we should rewrite the kernel in java since it has good support for threads. ;-) How about erlang (once we've got a working port)? Erlang's threads (called processes) are much more lightweight, and OpenBSD is, as we all know, not so fond of bloat. Kind regards (with tongue in cheek, of course), Hannah.
Re: openbsd's future plans?
i think we should rewrite the kernel in java since it has good support for threads. Remember we opted for C++ during c2k2 (or was it c2k3), but not until ddb has proper name demangling code. Miod
Re: openbsd's future plans?
On 07/02/06, Ted Unangst [EMAIL PROTECTED] wrote: On 2/7/06, Antonios Anastasiadis [EMAIL PROTECTED] wrote: I have been wondering what are the openbsd team's long term-plans (if any at all,of course) regarding future smp support. I am aware that openbsd currently supports smp under the big kernel lock, which offers some advantages for userland applications but generally things like interrupt and io load don't scale at all. I understand it is an enormous task, judging by the other os'es struggle to remove the bkl by various techniques. What are the developers thinking about the future regarding this matter, and what are their opinions about the other os'es paths as well. i think we should rewrite the kernel in java since it has good support for threads. Get real Ted. You know that python is the way to go. /Tony -- Tony Sarendal - [EMAIL PROTECTED] IP/Unix -= The scorpion replied, I couldn't help it, it's my nature =-
Re: openbsd's future plans?
i think we should rewrite the kernel in java since it has good support for threads. Get real Ted. You know that python is the way to go. What's the point of re-writing in either language? emacs already has a kernel.
Re: openbsd's future plans?
On 07/02/06, Bryan Irvine [EMAIL PROTECTED] wrote: i think we should rewrite the kernel in java since it has good support for threads. Get real Ted. You know that python is the way to go. What's the point of re-writing in either language? emacs already has a kernel. I don't want to make us loose focus in this important dicussion, or start a flamewar, but someone has to say it. Emacs sucks, vi rules. /Tony
Re: openbsd's future plans?
Damn. I shouldn't have asked.
Re: openbsd's future plans?
Aside from all (somewhat funny, especially the java one) jokes, what are the plans regarding SMP? Recently I had to install FreeBSD on a dual-Xeon server because it's SMP support is kinda better than OpenBSD's, but that did not please me at all, so that is indeed a good question. -- Felipe Brant Scarel PATUX/OpenBSD Project Leader (http://www.patux.cic.unb.br)
Re: openbsd's future plans?
Felipe Scarel wrote: Aside from all (somewhat funny, especially the java one) jokes, what are the plans regarding SMP? Same as always. Wait for someone to show REAL CODE. Evaluate the merits of that code. If it is up to OpenBSD standards, commit the code. Note that the real code comes first. Academic discussions are for people who don't produce. We don't talk about things that aren't ready for use, for the simple fact that if it doesn't exist, IT DOESN'T EXIST. You can't (er.. shouldn't!) make your decisions based on products that don't exist, so what's the point in idle talk? Recently I had to install FreeBSD on a dual-Xeon server because it's SMP support is kinda better than OpenBSD's, but that did not please me at all, so that is indeed a good question. That's...interesting. Long ago, when I started in the computer business, the rule was, let the application pick the hardware. Apparently, that is obsolete (ok, to be fair, people rarely followed it twenty five years ago) What you are saying is using that preferred the box over the OS and application, that using that machine defined a good job more than using OpenBSD. Of course, that's fine if that's what your priorities are. A couple years ago, I was giving an Internet Safety Training talk to a group of high school students. These were mostly refugees from the local failed public school district -- these kids didn't have much opportunity to become rocket scientists. One of the kids asked me why his computer at home crashed a lot, and I answered that it was basically because he and most of the rest of the world pick flash over quality. I digressed a bit (I'm sure that surprises everyone here that I'd do that), and told them about my involvement in the OpenBSD project, a group that puts quality and security at Task #1 in reality, not just in slogan. I told them we regularly get people that say things like, I'd really like to run OpenBSD for the security, but I want to run ProductX, and that doesn't run with/on OpenBSD. That was the biggest laugh line of the day! I think these kids actually understood my point -- saying security is most important doesn't mean a thing if you aren't willing to compromise anything else in order to get it. While many people will say, Security and quality is important, what they are saying by their actions is, Security and quality is the LEAST IMPORTANT CRITERIA to me, but I'll happily accept it if it doesn't conflict with my real priorities.. Again...talk is cheap. Nick.
Re: openbsd's future plans?
On Wednesday, February 8, Felipe Scarel wrote: Just to explain better what happened, I was willing to install OpenBSD on the machine even if it somewhat lost some power because of the SMP stuff. However, my boss doesn't share the same views regarding security with me, so I had no choice. Since this is a CS Department, it's rather impossible to disagree with the people here when it comes to computers. Bull. You can always disagree. Run on the system what is needed. If you need high-performance SMP, see what there is available that will give you the performance you need. Stick it behind a decent firewall. If this is to be a firewall... well, you makes your choices... --Toby.
Re: openbsd's future plans?
On Wednesday 08 February 2006 04:20, Diana Eichert wrote: On Tue, 7 Feb 2006, Miod Vallat wrote: i think we should rewrite the kernel in java since it has good support for threads. Remember we opted for C++ during c2k2 (or was it c2k3), but not until ddb has proper name demangling code. Miod I cast a vote for re-writing the kernel in Ruby because of it's robust threads implementation. You are misled, Diana. The kernel should be written in SNOBOL4. --STeve Andre'
Re: openbsd's future plans?
-Original Message- From: STeve Andre' [mailto:[EMAIL PROTECTED] Sent: 08 February 2006 01:40 AM To: Diana Eichert Cc: misc@openbsd.org Subject: Re: openbsd's future plans? On Wednesday 08 February 2006 04:20, Diana Eichert wrote: On Tue, 7 Feb 2006, Miod Vallat wrote: i think we should rewrite the kernel in java since it has good support for threads. Remember we opted for C++ during c2k2 (or was it c2k3), but not until ddb has proper name demangling code. Miod I cast a vote for re-writing the kernel in Ruby because of it's robust threads implementation. You are misled, Diana. The kernel should be written in SNOBOL4. --STeve Andre' Intercal!!! [demime 1.01d removed an attachment of type application/x-pkcs7-signature which had a name of smime.p7s]
