[riot-devel] [y...@isoc.org: [92all] Live video stream available - Re: Reminder: IETF 92 Lunch Host Speaker Series Tomorrow]

2015-03-25 Thread Oleg Hahm 
FYI
-- 
/* vsprintf.c -- Lars Wirzenius & Linus Torvalds. */
 *
 * Wirzenius wrote this portably, Torvalds fucked it up :-)
 */
linux-2.2.16/lib/vsprintf.c
--- Begin Message ---
FYI, if you want to invite other people who are not in Dallas to view this 
session, you can direct them to:

http://www.ietf.org/live/

where there is the link for the YouTube live event stream for this session.  
(There is also a link for tonight’s admin plenary.)

Enjoy,
Dan


On Mar 25, 2015, at 5:01 PM, Alexa Morris 
mailto:amor...@amsl.com>> wrote:

Topic: Open Source, How is it Really Doing?
Speaker: Chris DiBona, Director, Open Source and Science Outreach

Logistics:

• Room: Parisian
• Thursday, 26 March 2015
• Time: 12:00 – 12:45
• Lunch will NOT be provided.

Note: Grab-n-Go lunches will be available for purchase in the Fairmont.


Abstract:
In this talk, Google's Chris DiBona will talk about the direction that Open 
Source has taken over the last few years, where it has been succeeding, where 
it has failed and how the IETF has impacted adoption. As part of this, he'll 
talk about the spread of Android and Chromium codebases and what it has meant 
for the industry. Questions will be answered! What do open standards mean 
without open source? What does open source switches and routers mean for the 
future of the internet? SDN is software...open source software? Is open 
daylight a thing?

Biography:
Chris DiBona is the Director of Open Source for Mountain View, Ca. based 
Google. His teams oversees license compliance and supports the open source 
developer community through programs such as the Google Summer of Code and 
through the release of open source software projects and patches. In the public 
sector space, he looks after Google Moderator and Google Elections.

Mr. DiBona is an internationally known advocate of open source software and 
related methodologies. He occasionally appears on the This Week in Tech and the 
This Week in Google podcasts. He is a visiting scholar at the MIT Sloan School 
of Management and has a masters in software engineering from Carnegie Mellon 
University. Additionally, he serves on a number of technical advisory boards.

Before joining Google, Mr. DiBona was an editor and author for the website 
Slashdot.org. Additionally, he coedited the award-winning 
essay compilations "Open Sources" and "Open Sources 2.0" and writes for several 
publications. He was the host of Floss Weekly with Leo Laporte and made a 
number of appearances on TechTV's "The Screensavers" and on the Cranky Geeks.

His personal blog can be found at http://dibona.com.


--
Alexa Morris / Executive Director / IETF
48377 Fremont Blvd., Suite 117, Fremont, CA  94538
Phone: +1.510.492.4089 / Fax: +1.510.492.4001
Email: amor...@amsl.com

Managed by Association Management Solutions (AMS)
Forum Management, Meeting and Event Planning
www.amsl.com 

___
92all mailing list
92...@ietf.org
https://www.ietf.org/mailman/listinfo/92all

--
Dan York
Senior Content Strategist, Internet Society
y...@isoc.org   +1-802-735-1624
Jabber: y...@jabber.isoc.org
Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/deploy360/



___
92all mailing list
92...@ietf.org
https://www.ietf.org/mailman/listinfo/92all
--- End Message ---


pgpEfjirrcJdz.pgp
Description: PGP signature
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] [info] kernel network stack as a shared library

2015-03-25 Thread Eric Fleury 
and most important,  the link to LibOS: https://lwn.net/Articles/637658/ 

sorry for the noise.
eric

- -
Eric FLEURY, Professor at ENS de Lyon / Chaire Inria
Leader of DANTE INRIA TEAM
Deputy Scientific Delegate  for Inria Grenoble Rhône Alpes
TEL: +33 (0)4 26 23 3818  +33 (0)672 162 974
WEB: http://perso.ens-lyon.fr/eric.fleury/ 

WEB: https://team.inria.fr/dante/ 
Assistant: laetitia.le...@ens-lyon.fr 
> Le 25 mars 2015 à 22:29, Eric Fleury  a écrit :
> 
> Dear all and native/nativenet users,
> 
> I just read this info on hacker-news (https://news.ycombinator.com 
> ) this morning:
> 
> A post on library operating system (LibOS) for Linux which goal is " build 
> the kernel network stack as a shared library that can be linked to by 
> user-space programs to provide network stack personalization and testing 
> facilities, and allow researchers to more easily simulate complex network 
> topologies of linux routers/hosts. ». 
> 
> It may interest some of you.
> 
> Best
> 
> eric fleury
> 
> 
> 
> 
> - -
> Eric FLEURY, Professor at ENS de Lyon / Chaire Inria
> Leader of DANTE INRIA TEAM
> Deputy Scientific Delegate  for Inria Grenoble Rhône Alpes
> TEL: +33 (0)4 26 23 3818  +33 (0)672 162 974
> WEB: http://perso.ens-lyon.fr/eric.fleury/ 
> 
> WEB: https://team.inria.fr/dante/ 
> Assistant: laetitia.le...@ens-lyon.fr 
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel

___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] [info] kernel network stack as a shared library

2015-03-25 Thread Eric Fleury 
Dear all and native/nativenet users,

I just read this info on hacker-news (https://news.ycombinator.com 
) this morning:

A post on library operating system (LibOS) for Linux which goal is " build the 
kernel network stack as a shared library that can be linked to by user-space 
programs to provide network stack personalization and testing facilities, and 
allow researchers to more easily simulate complex network topologies of linux 
routers/hosts. ». 

It may interest some of you.

Best

eric fleury




- -
Eric FLEURY, Professor at ENS de Lyon / Chaire Inria
Leader of DANTE INRIA TEAM
Deputy Scientific Delegate  for Inria Grenoble Rhône Alpes
TEL: +33 (0)4 26 23 3818  +33 (0)672 162 974
WEB: http://perso.ens-lyon.fr/eric.fleury/ 

WEB: https://team.inria.fr/dante/ 
Assistant: laetitia.le...@ens-lyon.fr 
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] API proficiency levels

2015-03-25 Thread Kaspar Schleiser 

Hey,

On 03/25/2015 11:12 AM, Hauke Petersen wrote:

in general I like the idea, one problem I see is however, that is not
always clear, to which level an API belongs (e.g. the GPIO API is
definitely used also by high-level application programmers, while still
belonging to the low-level peripheral drivers...).
We could mark certain functions / parts of an API as "advanced" in the 
docs and provide "safe" alternatives.


Seriously, it hurts to not be able to work around 10 redundant 
checks whether an int coming from flash is a correct SPI device...


Kaspar
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Updated Invitation: Biweekly virtual meeting @ Wed Mar 25, 2015 2pm - 3pm (RIOT Events)

2015-03-25 Thread Oleg Hahm 
Hi!

> we will start with the bi-weekly developer meeting now. The PlaceCam link
> for joining is the following:
> 
> http://placecam.de/call.php?c=lmakKMrDG8a35aIBNqLBvOnApExkKFntj9xXawGNgTc-

The corresponding Etherpad with the Minutes is online at
http://riot.pad.spline.de/10

Cheers,
Oleg
-- 
The problem UDP jokes


pgprsu0E8odNt.pgp
Description: PGP signature
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Updated Invitation: Biweekly virtual meeting @ Wed Mar 25, 2015 2pm - 3pm (RIOT Events)

2015-03-25 Thread Hauke Petersen 

Hi everyone,

we will start with the bi-weekly developer meeting now. The PlaceCam 
link for joining is the following:


http://placecam.de/call.php?c=lmakKMrDG8a35aIBNqLBvOnApExkKFntj9xXawGNgTc-

Please refer to the RIOT wiki [1] for information on how to join.

Cheers,
Hauke

[1] 
https://github.com/RIOT-OS/RIOT/wiki/Instructions-for-remote-participation




On 24.03.2015 16:44, Martine Lenders wrote:


Event Invitation

Title:



Biweekly virtual meeting

Location:



When:



Wed 25 Mar 2015 14:00 – 15:00




Organizer:



Description:



Developer discussions. Remote participation will be provided. View 
your event at 
https://www.google.com/calendar/event?action=VIEW&eid=anBwMXUyaXZsdWVkOHFkdHA1MGpzYjFzZ2tfMjAxNTAzMjVUMDkwMDAwWiBrM3FsOHNldHY3bDQ4b2Zub2wwdGZ1dTZ0c0Bn.


Comment:



Attendees:






___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] API proficiency levels

2015-03-25 Thread Hauke Petersen 

Hi Kaspar,

in general I like the idea, one problem I see is however, that is not 
always clear, to which level an API belongs (e.g. the GPIO API is 
definitely used also by high-level application programmers, while still 
belonging to the low-level peripheral drivers...).


Cheers,
Hauke

On 25.03.2015 10:39, Kaspar Schleiser wrote:

Hey guys,

I've been thinking about how to find generally usable principles for 
certain API aspects, like when to check a function's parameters for 
validity.


An idea came to mind:

We could define some (two, three) levels of how low an API goes and 
define (and document) consistent behaviour around those levels.


For example, a high-level timer or socket API that is being used by 
any simple application has probably more need for parameter checking 
than a low-level interface that no normal user will ever see.
On the other hand, low-level functions for accessing the flash will 
probably abstracted with a sane user API.


The idea is to document that some API's do need a deep understanding 
of what's going on, thus will be used by developers that don't need a 
high level of safeguards. We could omit a lot of extra sanity checks.


Other API's will be used by high-level programmers which might not 
know how to debug parameter mistakes, so checking function arguments 
is more important.


What do you think?

Kaspar

___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] API proficiency levels

2015-03-25 Thread Kaspar Schleiser 

Hey guys,

I've been thinking about how to find generally usable principles for 
certain API aspects, like when to check a function's parameters for 
validity.


An idea came to mind:

We could define some (two, three) levels of how low an API goes and 
define (and document) consistent behaviour around those levels.


For example, a high-level timer or socket API that is being used by any 
simple application has probably more need for parameter checking than a 
low-level interface that no normal user will ever see.
On the other hand, low-level functions for accessing the flash will 
probably abstracted with a sane user API.


The idea is to document that some API's do need a deep understanding of 
what's going on, thus will be used by developers that don't need a high 
level of safeguards. We could omit a lot of extra sanity checks.


Other API's will be used by high-level programmers which might not know 
how to debug parameter mistakes, so checking function arguments is more 
important.


What do you think?

Kaspar

___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel