Think Of Your Audience
One of the challenges technical authors face is that of peer respect. That is, technical people who took a lot of time to learn what they know want to be respected by their peers when they write. They want to be recognized for their knowledge, wisdom, and insights.
In that context, there’s often fear before pressing “Publish.” Was every detail correct? Was every scenario considered? Was the very latest information about a topic included?
The fear of hitting publish is well-founded for technical authors, because technical folks have a way of being nit-picky, pedantic, and annoying. One small detail wrong, one badly stated premise, and the angry comment and critical tweet claws come out, slashing at your ego.
Will they like me? I just want everyone to like me.
One solution, of course, is to have a thick skin. If you view criticisms as a way to improve a piece, that’s the best route to go, especially when the commenter has a good point. Being able to ignore critics is another useful skill, because there are plenty of folks who say a lot while adding no value whatsoever.
However, I think the most important point to keep in mind Continue reading
Think Of Your Audience
One of the challenges technical authors face is that of peer respect. That is, technical people who took a lot of time to learn what they know want to be respected by their peers when they write. They want to be recognized for their knowledge, wisdom, and insights.
In that context, there’s often fear before pressing “Publish.” Was every detail correct? Was every scenario considered? Was the very latest information about a topic included?
The fear of hitting publish is well-founded for technical authors, because technical folks have a way of being nit-picky, pedantic, and annoying. One small detail wrong, one badly stated premise, and the angry comment and critical tweet claws come out, slashing at your ego.
Will they like me? I just want everyone to like me.
One solution, of course, is to have a thick skin. If you view criticisms as a way to improve a piece, that’s the best route to go, especially when the commenter has a good point. Being able to ignore critics is another useful skill, because there are plenty of folks who say a lot while adding no value whatsoever.
However, I think the most important point to keep in mind Continue reading
Cisco’s $1.9B BroadSoft Purchase Gives it a Telecom Cloud Services Edge
Cisco's latest acquisition follows its Perspica purchase announced last week.
Fujitsu Provides SD-WAN for Service Providers via Silver Peak’s Tech
It conforms with MEF’s SD-WAN terminology.
Alphabet’s Project Loon Delivers Internet in Puerto Rico
The balloon-based connectivity project is working with AT&T.
SK Telecom Pumps Up WiFi to Match 5G Speeds
The WiFi technology is expected to help support video consumption ... eventually.
BGPsec and Reality
From time to time, someone publishes a new blog post lauding the wonderfulness of BGPsec, such as this one over at the Internet Society. In return, I sometimes feel like I am a broken record discussing the problems with the basic idea of BGPsec—while it can solve some problems, it creates a lot of new ones. Overall, BGPsec, as defined by the IETF Secure Interdomain (SIDR) working group is a “bad idea,” a classic study in the power of unintended consequences, and the fond hope that more processing power can solve everything. To begin, a quick review of the operation of BGPsec might be in order. Essentially, each AS in the AS Path signs the “BGP update” as it passes through the internetwork, as shown below.
In this diagram, assume AS65000 is originating some route at A, and advertising it to AS65001 and AS65002 at B and C. At B, the route is advertised with a cryptographic signature “covering” the first two hops in the AS Path, AS65000 and AS65001. At C, the route is advertised with a cryptogrphic signature “covering” the first two hops in the AS Path, AS65000 and AS65002. When F advertises this route to H, at Continue reading
Worth Reading: The Economics of DDoS
The post Worth Reading: The Economics of DDoS appeared first on rule 11 reader.
Network Break 158: Cisco Announces Predictive Services; KRACK Attack
Today's Network Break dives into Cisco's new predictive services, the KRACK vulnerabilities, HPE's step back from cloud servers & giant fighting robots. The post Network Break 158: Cisco Announces Predictive Services; KRACK Attack appeared first on Packet Pushers.
Why does one NGINX worker take all the load?
Scaling up TCP servers is usually straightforward. Most deployments start by using a single process setup. When the need arises more worker processes are added. This is a scalability model for many applications, including HTTP servers like Apache, NGINX or Lighttpd.
CC BY-SA 2.0 image by Paul Townsend
Increasing the number of worker processes is a great way to overcome a single CPU core bottleneck, but opens a whole new set of problems.
There are generally three ways of designing a TCP server with regard to performance:
(a) Single listen socket, single worker process.
(b) Single listen socket, multiple worker processes.
(c) Multiple worker processes, each with separate listen socket.
(a) Single listen socket, single worker process This is the simplest model, where processing is limited to a single CPU. A single worker process is doing both accept() calls to receive the new connections and processing of the requests themselves. This model is the preferred Lighttpd setup.
(b) Single listen socket, multiple worker process The new connections sit in a single kernel data structure (the listen socket). Multiple worker processes are doing both the accept() calls and processing of the requests. This model enables some spreading of the inbound Continue reading