Uvloop: Blazing fast Python networking

Quite surprisingly, pure-Python asyncio, with the help of high-performance HTTP parser is faster than nodejs, which uses the same HTTP parser!

Go is faster for 1 KiB responses, but uvloop+asyncio is measurably better for 10/100 KiB responses. The quality of service is excellent for asyncio and uvloop with httptools, as wells as for Go.

Admittedly, httptools-based server is very minimal and does not include any routing logic, unlike other implementations. Nonetheless, the benchmark demonstrates how fast uvloop can be with an efficiently implemented protocol.

Original URL: http://feedproxy.google.com/~r/feedsapi/BwPx/~3/ABOK-uqTtWk/  

Original article

Introducing the LEDE project – A reboot of the OpenWrt community

The LEDE project is founded as a spin-off of the OpenWrt project and shares many of the same goals.
We are building an embedded Linux distribution that makes it easy for developers, system administrators or other Linux enthusiasts to build and customize software for embedded devices, especially wireless routers.
The name LEDE stands for Linux Embedded Development Environment.

Members of the project already include a significant share of the most active members of the OpenWrt community.
We intend to bring new life to Embedded Linux development by creating a community with a strong focus on transparency, collaboration and decentralisation.

LEDE’s stated goals are:

  • Building a great embedded Linux distribution with focus on stability and functionality.

  • Having regular, predictable release cycles coupled with community provided device testing feedback.

  • Establishing transparent decision processes with broad community participation and public meetings.

We decided to create this new project because of long standing issues that we were unable to fix from within the OpenWrt project/community:

  1. Number of active core developers at an all time low, no process for getting more new people involved.

  2. Unreliable infrastructure, fixes prevented by internal disagreements and single points of failure.

  3. Lack of communication, transparency and coordination in the OpenWrt project, both inside the core team and between the core team and the rest of the community.

  4. Not enough people with commit access to handle the incoming flow of patches, too little attention to testing and regular builds.

  5. Lack of focus on stability and documentation.

To address these issues we set up the LEDE project in a different way compared to OpenWrt:

  1. All our communication channels are public, some read-only to non-members to maintain a good signal-to-noise ratio.

  2. Our decision making process is more open, with an approximate 50/50 mix of developers and power users with voting rights.

  3. Our infrastructure is simplified a lot, to ensure that it creates less maintenance work for us.

  4. We have made our merge policy more liberal, based on our experience with the OpenWrt package github feed.

  5. We have a strong focus on automated testing combined with a simplified release process.


The *Wrt community is made up of many great communities all tinkering on their
own mission in improving something on this planet. The Following communities have
kindly decided to endorse this project. Thanks !

Original URL: http://feedproxy.google.com/~r/feedsapi/BwPx/~3/VBwTvUfstWM/  

Original article

Stack Overflow: How We Do Deployment

This is #3 in a very long series of posts on Stack Overflow’s architecture.
Previous post (#2): Stack Overflow: The Hardware – 2016 Edition

We’ve talked about Stack Overflow’s architecture and the hardware behind it. The next most requested topic was Deployment. How do we get code a developer (or some random stranger) writes into production? Let’s break it down. Keep in mind that we’re talking about deploying Stack Overflow for the example, but most of our projects follow almost an identical pattern to deploy a website or a service.

I’m going ahead and inserting a set of section links here because this post got a bit long with all of the bits that need an explanation:
Continue reading “Stack Overflow: How We Do Deployment”

Original URL: http://feedproxy.google.com/~r/feedsapi/BwPx/~3/LSBIschT9QM/  

Original article

Why no delete command?

Why no delete command?


Here’s why my blogging tools don’t have delete commands, basically until the users drag it out of me. 

In the early 1980s, I ran a computer bulletin board out of my living room in Menlo Park, CA. It was called the Living BBS or LBBS for short. I wrote and maintained it myself. It was written in UCSD Pascal and ran on an Apple II with an external 10MB hard disk.

I thought I understood security but I didn’t. Once the system got to a certain critical mass of users, someone started hacking me. They figured out how to get around the password and could delete messages that didn’t belong to them. Whoever it was, kept deleting the root of the tree, and when I’d come back there was just a welcoming message written by the hacker, and maybe one or two confused messages from users who had stumbled on the LBBS in its humbled state.

Eventually I realized the first answer was to disable the Delete command, thus making it more labor-intensive for the hacker to destroy my humble server. It worked. The asshole went away.

Then I brought the Delete command back, but made it just set a bit in the message that was being deleted. Nothing actually got reclaimed. So the hacker thought the message was gone, but all I had to do was run a script that visited all the nodes and flipped the bits back. Database restored.

Okay today is the day that 1999.io gets its Delete command. I just wanted to explain why it took me so long to do it. 

Original URL: http://scripting.com/2016/05/03/1234.html  

Original article

Stack Overflow: How We Do Deployment – 2016 Edition

We’ve talked about Stack Overflow’s architecture and the hardware behind it. The next most requested topic was Deployment. How do we get code a developer (or some random stranger) writes into production? Let’s break it down. Keep in mind that we’re talking about deploying Stack Overflow for the example, but most of our projects follow almost an identical pattern to deploy a website or a service.


This is our starting point for this article. We have the Stack Overflow repository on a developer’s machine. For the sake of discussing the process, let’s say they added a column to a database table and the corresponding property to the C# object — that way we can dig into how database migrations work along the way.

A Little Context

We deploy roughly 25 times per day to development (our CI build) just for Stack Overflow Q&A. Other projects also push many times. We deploy to production about 5-10 times on a typical day. A deploy from first push to full deploy is under 9 minutes (2:15 for dev, 2:40 for meta, and 3:20 for all sites). We have roughly 15 people pushing to the repository…

Read the rest of Stack Overflow: How We Do Deployment – 2016 Edition on Nick’s blog here. It’s the second in an extensive series of blog posts on Stack Overflow’s technical architecture.

By Nick Craver, Developer and Site Reliability Engineer

Original URL: http://feedproxy.google.com/~r/feedsapi/BwPx/~3/8NZmeBgCo5o/  

Original article

Google enables HTTPS for all Blogspot sites

fig1 Google today made HTTPS connections the default for all of the sites on its Blogspot domain. Google first enabled HTTPS for Blogspot last September, but at the time, it was an opt-in feature. Starting today, encrypted connections are enabled by default. It’s worth noting that this only applies to Blogspot blogs that fall under the .blogspot.com domain. HTTPS is currently not available… Read More

Original URL: http://feedproxy.google.com/~r/Techcrunch/~3/VyCRbSWvipA/  

Original article

The Moog Model 15 Synthesizer Stuffs a $10,000 Synth Into an iPad App

iOS: The Moog Modular Model 15 is one of Moog’s more popular synths, but it retails for around $10,000, which is far too expensive for most of us. If you’ve got an iPad sitting around, you can snag a digital recreation for $30.

Read more…

Original URL: http://feeds.gawker.com/~r/lifehacker/full/~3/-XdSQTQVEbE/the-moog-model-15-synthesizer-stuffs-a-10-000-synth-in-1774459449  

Original article

Proudly powered by WordPress | Theme: Baskerville 2 by Anders Noren.

Up ↑

%d bloggers like this: