Here's the series of patches - looks like applied few hours ago.
https://lore.kernel.org/netdev/20190617.104121.1475407136257...
HN user
Twitter: @nitinics email: nitinics@gmail.com www.nitinics.com
Verifying my Blockstack ID is secured with the address 1DiaxZCRXyZoWBmTN1Fh7gxXs1Ne53htKy https://explorer.blockstack.org/address/1DiaxZCRXyZoWBmTN1Fh7gxXs1Ne53htKy
Here's the series of patches - looks like applied few hours ago.
https://lore.kernel.org/netdev/20190617.104121.1475407136257...
I think it all boils down to how you deploy your stuff. If you think Cloud is so massive that it is never a SPOF, you'll likely not meet your availability aspirations in some time in future.
Cloud to me is also shared risk. I read - "Google cloud outage" as "multiple companies that rely on a shared infrastructure is not available ATM".
The mindset should be to run your services on a distributed infrastructure with no SPOF. Leverage cloud, fog, racks, PCs, whatever resources you can, but diversify your content/service and be risk averse from failure of one kind.
Yes. But the point is you cannot assume TCP is the only transport protocol that moves data across the public internet.
I agree that with better modulation techniques on DOCSIS protocols, you could achieve higher throughput on the downstream.
However, IMO - what should have been the focus for Google Fiber is to come up with applications that consume more upstream traffic. That is where DOCSIS lacks in terms of throughput and a fundamental problem docsis nodes face called "noise funneling". To avoid that - cable companies push fiber nodes closer to last mile.
If Google would have been successful in creating a FTTH marketplace, it wouldn't be that difficult for cable companies to start investing on ONU/ONT and GPON solutions to compete. With competition, Google wouldn't really get the ROI they were expecting unless they really bring about change in applications that utilize the upstream bandwidth heavy.
You are assuming that TCP with current congestion avoidance algorithm is the only transport medium. When you have bigger pipes allowing you more bits to pack/unpack, you might find the era of newer transport protocols that do specific tasks more efficiently while increasing your overall throughput for specific use-cases. I can think of video streaming, gaming, file storage, etc that might add up to consuming the pipe to the ceiling.
1. Customer Service - Provide enterprise solutions for customer service and charge $$$ per transaction. The live nature of this would prove a lot of value for feedback mechanisms for enterprise when they go through their change management.
2. Live Interaction with Events, Games, Television, Radio etc. e.g. Polls, QnA, Sentiment etc.
3. Open Access to Developers to build Apps on real-time content.
4. Enable fact-check score methodologies on every tweets. Don't completely wipe out the trolls. As weird as it may sound - trolls make twitter interesting.
5. The Ultimate messaging platform that replaces SMS/Texts with an identity that is not numbers.
"Even if you file an 83b election, you are still liable for paper gains between the value of your options when you were granted them and the value when you exercised."
Wouldn't this be taxed as capital gains though - when exercised?
Him sending an email to the .np cctld has nothing to do with the hack he's talking about. More likely, his plain text email was intercepted 'on the wire' and would have been the same to whichever cctld he would have sent to.
SSL/TLS certificates provisioned through AWS Certificate Manager are free. You pay only for the AWS resources you create to run your application.
I saw this coming. Nepal has such good natural resources to generate enough electricity for itself and export to its neighbors, yet political deadlocks and bureaucratic hurdles are ruining the potential. http://newsinfo.inquirer.net/755108/energy-starved-nepal-los...
I think Industry Research is mostly driven by some constraints that applies to their architecture, their business use-cases and how much the company is willing to spend $$$ on research that adds value to their products or services. Academics on the other hand thinks beyond the box and researches and gives clues to upcoming industries on where the problem might be and how it could be solved, therefore eventually helping Industry grow with validation from the researches and allowing them to put them into "products" and "services".
Therefore, I don't think Academics should stop doing what they do (i.e. wander around) and have a laser focus on Industry's product-based researches.
More than just an OS, I think what they've built is a Network OS (NOS) on top of Linux. They have been involved in Switch Abstraction Interface(SAI) specifications from Open Compute Networking Projects from early days. I am excited what this brings on the table in Software Defined Networking. I really hope they open source their SAI implementation, and their NOS can be used with ONIE. So I could get a bare metal switch, install their NOS, and build network apps for my use-cases.
One of the strategy NYCMesh took for where line of sight was not available was to tunnel through the Internet to mesh. This would enable anyone to join the mesh without line of sight requirement, and once more and more people join and the density increases, they can get their dependency on Internet Tunnels away, by connecting/hopping through line-of-sight nodes.
BGP's transitive trust mechanism involves 2 parties. The router making an "announcement" or "withdrawal" and the router "accepting" or "origin validating" these. If one of the party announces a false/hijacked route to its upstreams it could have an adverse effect to the entire Internet routing table.
BGP itself, is a path vector protocol (came from standard and vetted Graph Theory algorithms) and therefore for the scalability of the Internet Prefixes - works perfectly with many network devices talking the standard protocol.
Work has always been done within the IETF wg on BGP attributes that the protocol carries for many use-cases and so far BGP has been the preferable choice for many networks, both within an AS and outside an AS(Autonomous System).
You wouldn't want the Internet be controlled by a central authority, that is an absolute NO - at the same time - you have to work together to make sure the "global routing table" or the "default free zone" is not polluted with unnecessary updates and churn and overseeing misbehavior from other ASes.
I believe with so many disparate organizations and networks around the world - we could not have built a common talking "language"/"protocol" without having accountability into it and constantly monitoring it.
With 2 renewals of 3-year H1B work visa, you do not have much time to shop around for employers sponsoring permanent residency. It is a long process in itself , and usually companies want the employee to work for them until they file the paperwork. That means, you are not putting yourself out there for bigger and better options, even if you have any - since you're tied to the employer until they file. Also the author said it correct - it is extremely difficult for one to startup on their own - since it is not favorable as well on work visas. It just does not make sense that an immigrant having got their higher education in US, are asked to leave and usually the ones that leave may be ambitious, having hopped multiple jobs without tying themselves to one employer and gathered enough expertise in their fields, both academic and industry. Immigration reform in this aspect, is therefore, warranted.
Not really. You'd want every routers in the path to reply to see all the hops in between. This would be unreliable though, since the ICMP TTL exceeded message might come in out-of-order to the sender, who is sending these probes(with varying TTLs) simultaneously. But assuming, you could somehow figure out the hop-order, this IMO is faster than current traceroute implementation.
I'd think sending multiple packets (parallelism) with varying TTLs (1,2,3..n) without waiting for responses from each hops to increment the TTL, would probably give us faster traceroute. n being the number of hops you "expect" the destination subnet to be.
First of, Thanks for this technology that helped save some of my countrymen. This goes to show that technology can indeed help in many avenues to save lives. I am originally from Nepal living in NYC, and looking for ideas that could create technology-aided sustainable development as a key to rebuilding. Ideas that come to me, which might have high $$ values for implementation are - 3D printed housing, Organic Farming for quick rehabilitation on these villages, Open-Source BTS for communications etc. As costs go lower, these affected areas might be the right place to implement these. As much as I am devastated by what is happening in Nepal right now with the death toll only rising, I would like to reach out to the technology community out here or anywhere to provide me with ideas into helping us rebuild. Most of the relief efforts are donation-based, however, for longer term - creating a sustainable economy in these low privileged areas with the help of emerging technologies is what I think is crucial for faster recovery.
Hi, We would want to establish a solar cell-phone charging system in Kathmandu and affected areas. If anyone got any ideas of how to proceed (who would donate these, who would transport these), please contact us at wg@nypny.com [ Nepalese Young Professionals in New York (NYPNY) ]
Humans try hard to be smarter than their "software" counterparts. Start-ups emerge with a problem to solve "How to make a normal human smarter than any machines". Economics would be decentralized, and ultimately survival of the fittest. If only I could live to see all this.
You should trace the attackers by tracing back. Work with your upstream providers and mailing lists (NANOG) and publicly shame these attackers. Likely, they are spoofing addresses - validate that and make sure you let the network know where the spoofed traffic is sourcing from to follow BCP38 and BCP84, defined by RFCs 2827 and 3704.
Congrats! Would love to see BGPMon providing more intelligent analysis partnering with OpenDNS to Internet incidents such as the Google service disruption in some parts of the world today. https://news.ycombinator.com/item?id=9192032
You can also check RIPE BGPlay here and track the outage - https://stat.ripe.net/widget/bgplay#w.resource=74.125.226.0/...
Type: A > pathchange Involving: 74.125.226.0/24
Short description: The route 39202 174 9498 17488 15169 is changed to 39202 174 15169
Path: 39202, 174, 15169,
Date and time: 2015-03-12 09:16:23 Collected by: 01-195.66.225.2Your traffic traversed through SMILE>Zantel>Tata .. You may not be able to influence the best path to reach Google through Smile even though Zantel might be multihomed (unless the best path changes). I'd recommend testing from other providers such as SPICE-NET-TZ, TZ or simbanet-tz,TZ etc. [ Look above at the Seacom's downstream adjacent AS link I provided to find if you can use any of those carrier instead ]
# whois -h whois.cymru.com 41.138.222.196
AS | IP | AS Name
327692 | 41.138.222.196 | SMILECOMMS,UG
# whois -h whois.cymru.com 41.73.194.97
AS | IP | AS Name
36930 | 41.73.194.97 | Zantel-AS,TZLooks like your provider is traversing through TATA Communications (AS6453) on both of those.
Wonder what your latency would be with a SEACOM(AS37100) traversal, http://en.wikipedia.org/wiki/Telecommunications_in_Tanzania
Here are your downstream carrier options : http://www.cidr-report.org/cgi-bin/as-report?as=AS37100&v=4&...
Programmers can easily resonate to this blog. But I think this is the moment of truth of transition from a programmer to an engineer where you realize you are better off creating something on your own from the ground up than working for someone else's creation.
On any post incident reports - shall we ever come out of using the most common and ambiguous technology lingo "network issue". If it were identified a network issue (Route black hole, prefix hijacking, resources depletion or consistency issues etc) then you probably know enough to elaborate on the specifics.
I wonder if autonomous local mesh networks and hyper local mesh networks which is essentially a network of networks would fall under the term "Internet" and under these regulations. That would certainly stop innovation on that front (?)
Looks like they use Ka band [ http://en.wikipedia.org/wiki/O3b_%28satellite%29 ]. Wonder what were the factors of not choosing the Ku band. As far as I know Ku band is more cost effective and less susceptible to rain fade and such.
AS Numbers are how you announce the prefixes where content C resides e.g. 1.0.0.0/24 to the Internet, and you (through your provider announcing your prefix to the Internet) find your path to the content C for the services.
http://www.cidr-report.org/cgi-bin/as-report?as=AS15169&view...
Complexities aside - this is how your Internet works.