hhw

Teksavvy which has pretty good national presence using lines from any of Shaw, Telus, Bell, and Rogers charges $45/mo for 30Mb, $55/mo for 75Mb, and $70/mo for 100Mb. Just in nominal dollars without adjusting for currency, this is better than most pricing I've seen in the US.

Comcast is showing a $65/mo promotional offer for 1 year, with no details showing on what speed that is. If it's anything like the $50/mo offer I used to have, it will most likely increase significantly at the end of the year, and will continue going up in price periodically unless you call and complain.

Which ISP with nationwide coverage in the US offers significantly better pricing than Teksavvy on comparable plans?

Canadaian broadband pricing is actually quite reasonable, especially as you have smaller players that are able to buy last mile lines wholesale at/near cost to compete.

Wholesale metro fiber is also considerably less than in the US, as public and utilities infrastructure is much more open. And there is already municipal fiber in Montreal, Calgary, and some suburban parts of Vancouver to name a few.

You also don't have to play games, like with Comcast that periodically raises your pricing arbitrarily and can really rack up if you're not paying attention. A few years back when I kept an apartment in Seattle, I went from $50/mo on promotional offer, to $80/mo regular, and ended up at almost $120/mo by the time I cancelled less than 2 years later. Such practices would never fly in Canada.

> especially when he has much of his wealth invested in the very industry that is likely to be affected by the results of this Coronavirus study

Citation needed. As far as I can tell, his only healthcare related holding is Schrodinger, Inc. which is new, and at 300M out of his 106B net worth could hardly be considered "much of his wealth" .

Historical rate of return on stocks is about 7%. So in theory, a stock trading at a price to earnings ratio of 14 or less is good value, whereas a stock trading at 15 times earnings is not so much.

However, other factors could play a part, as certain industries are favoured over others, risk, projecting earnings growth, etc.

As such, you can make the argument that stocks are overvalued because they're trading at all time or near all time highs in terms of price to earnings ratios and other metrics. And especially so now given that projected future earnings will have dropped considerably while stock valuations have not.

However, evidence of absence is unlikely to be found as the vast majority of researchers tend not to bother publishing papers with negative results. So if an idea seems like it should have been researched already, but no research papers are to be found, it may very well be because the evidence of absence simply hasn't been shared.

It's not about ideological purity, but about respecting the GPLv2.

https://sfconservancy.org/blog/2016/feb/25/zfs-and-linux/

IANAL but Canonical's justification for the ZFS kernel module and Linux kernel being totally separate works, and the distribution itself not being a derivative work of GPLv2 seems dubious to me.

https://blog.dustinkirkland.com/2016/02/zfs-licensing-and-li...

Seeing as how the Software Freedom Conservancy believes this to be a GPLv2 violation, and Oracle could launch a lawsuit as a result of it also being a CDDLv1 violation, I think it's safe to say that it's not just ideological purity that factored into Debian's decision not to include ZFS.

It may not have explicitly stated that there was no human to human transmission, but that was strongly suggestive that there wasn’t.

The default assumption should be, that a virus affecting hundreds of people already, could be contagious. Suggesting otherwise, with no reasonable evidence to support such, is deliberately obfuscating if not deliberately misleading. There was absolutely no reason to make such a statement other than to parrot without question what was being reported by the PRC.

Considering Tedros Adhanom Ghebreyesus received support from the PRC in his candidacy for leadership of the WHO, and the significant ties between his home country of Ethiopia and the PRC, I’m skeptical that it was just absolute ignorance without any political influence or bias that prompted such a statement.

You're unlikely to see anywhere near line rate though, especially with higher packets/s, as cheaper equipment tends to use CPU based forwarding. Whereas ASICs based gear, even when using merchant silicon like Broadcom or Marvell, still cost a decent amount.

I think you're missing the parent's point, that you can use a /31 without separate network (not gateway) and broadcast addresses.

Putting multiple customers on the same /24 introduces all kinds of issues. Either you leave it open leaving IP's vulnerable to hijacking, or you have to create static ARP and/or MAC entries, and deal with all the hassle of managing that. Presumably, you're describing consumer service where they don't really have to care about your security unlike a business/enterprise level service.

China has state run Telecom companies providing all the eyeball access, so it's relatively straightforward to ensure outside connectivity goes through the great firewall.

Hong Kong has multiple private companies providing eyeball access. It would be far more difficult for the Chinese government to get all of their compliance. If they just wanted to get traffic information, it would be far easier to just collect a statistical sampling collected from flows data on core routers for general info or to monitor specific IP's using rulesets without the massive undertaking needed for always on firewall capabilities on every single packet.

Maybe if your load is unusually extremely erratic. In the vast majority of cases, you could purchase 2-3x more than you need in bare metal hosting resources (with data centre and hardware operations already outsourced), making scaling not an issue, and still see significant cost savings compared to public cloud which is typically 6-7x the cost for equivalent resources.

From a dedicated hosting provider's perspective, some customers will notice interruptions more than 5 minutes (1 monitoring cycle), start submitting trouble tickets at 15 minutes, and require RFO's at 30+ minutes of downtime. An hour and up even just one time, we would probably start to see cancellations. Not going to say I'm not envious that AWS seems to have a much more outage tolerant customer base.

A c4 dedicated host at AWS (simply picked as the 2nd listed in the Dedicated Hosts Configuration Table as c3 the first doesn't show up under the Instance Types page) comes with an E5 2666v3, 64GB of RAM, and no storage for $810/mo.

The CPU model is non-standard, but at 10 cores and 2.90GHz is effectively a slightly higher clocked version of the E5 2660v3 (10 cores, 2.60GHz). The first google result for a 2660v3 dedicated server with an order page that allows to adjust the options (13 usable IP's, 64GB RAM, minimal 120GB SSD storage) comes out to $275.

And this is based on whole box to whole box comparison. The cost of individual instances at AWS equivalent to one of those boxes can be much higher depending on the type and size.

2-3 hours per year is a lot of downtime. Most competent bare metal providers see maybe one major outage of less than an hour every 3-5 years. Nothing other than a facility wide power outage, if the load somehow gets dropped because the generators don't start right away as they should, or a misbehaving (only partially failing) core network infrastructure device should result in major outages when all the proper redundancies are in place.

Specific providers aside, there's more complexity involved in a large cloud provider's infrastructure and much more that can go wrong as a result. Having a code update, or some orchestration issue from your infrastructure provider be potential points of major outages are huge and unnecessary risks. You don't need that much scale, just utilizing enough resources to fill up a few whole physical machines for a few hundred dollars a month. Add some globally distributed BGP Anycast DNS and database replication and you have enough redundancy to withstand most of the worst major infrastructure failures.

I would understand if AWS was super simple and convenient, but these days the learning curve seems far greater than setting up the above described bare metal solution. While being almost an order of magnitude more expensive for the equivalent amount of resources.

How did we end up here? Does brand recognition just trump all technical and economic factors, or what am I missing?

Disclaimer: I run a bare metal hosting provider

It doesn't really matter how much money economy brings in at the top line, if there's little to nothing to be made on the bottom line. An entire plane of economy only at market fares is not worthwhile for an airline to operate on a per flight basis. Possibly worthwhile to operate in some situations just to keep their fleet in use, but likely not.

If this weren't the case, more airlines would operate flights like that. There isn't any conspiracy between airlines to minimize plane space for economy seats. The reality is that currently, the premium classes subsidize economy and not the other way around like you originally suggested.

By all accounts I've previously heard from people in the airline industy, you have the economics completely backwards. The bulk of the profits come from premium classes, while economy is totally unprofitable but serves to provide the economies of scale for a larger flight.

Premium economy seems to be the best compromise for this situation that the market has come up with. There's still economy to stay competitive against other airlines for passengers who want to pay bottom dollar, but provide a bit more comfort and amenities without being too exorbitantly expensive. Passenger gets treated a little better, and the airlines make a bit of margin.

They could also just rent dedicated bare metal servers on a month-to-month basis, getting whatever hardware specs they want so long as it's not overly exotic. Then they don't have to worry about anything at the data centre or hardware level.

Given that cloud costs easily 6-7x for the equivalent amount of hardware resources as a well priced dedicated server provider, you can just buy 2-3x the resources you need for extra scalability and not have to share those resources with anyone. Or if you are in the tiny minority of companies that really does have extremely erratic load requirements, you can put your base load on bare metal and your excess load on cloud.

I don't understand why people on HN always put forth a false dichotomy between cloud and running your own data centre when there's a plethora of different mixes of infrastructure and managed services that falls in between.

If they were going to buy the card for $30K anyway if you didn't discount it, yes. Even if they weren't going to buy the car without the discount, but someone else would likely come along and buy it for $30K, then still yes, you would have given away $5K.

Add on to the fact that if you sold that one car for $25K, you end up with other people who would've paid $30K but now want that same discount, so you may have given away a lot more than $5K.

Vancouver, BC is probably the easiest city on the West Coast to manage without a car. The downtown core is very walkable, and there is reasonable public transit through most of the greater metro area. There's a high proportion of residential buildings downtown, and many have pretty empty parking lots as cars aren't necessary for a lot of people most of the time, and there are a number of competing car share services the rest of the time.

Last updated in 2003. Seems eerily prescient, most of what it said back then would apply even more so today. All that would be needed is an amendment to 3) so that it also applies for init systems, to bring that list fully up to date.

Most volumetric attacks are UDP reflection based, and relatively simple to filter out at the network level using ACL's. When using decent network gear, these can be filtered at line rate using ASICs. These comprise the vast majority of real-world DDoS attacks.

Having the ability to protect against more focused attacks with HAProxy could be very useful in those few instances where volumetric attacks are not being used.

The rate of increase far exceeds what could be accounted for by the natural cycle, so there's no legitimate question for anyone both informed and intellectually honest about the subject about whether climate change is anthropogenic.

In a world where more and more power is concentrated into fewer and fewer large corporations, I'm not so sure this is crazy that they're not allowed to do this, nor that it would be a good thing if they were. The natural result would be that different states or nations race to the bottom chasing the corporations to locate there, depriving their citizens of substantial tax revenues that could have been used for the public good. Even if you're against social programs, there is still common infrastructure that everyone benefits from such as roads that need to be paid for.

But the article states quite clearly that he is NOT claiming to use genuine parts.

“PCKompaniet has never removed the coverup of the Apple logo on the screens that have been imported and has no interest in doing so. PCKompaniet does not pretend or market itself as Apple authorized and does not give any indication that the repair comes with an Apple warranty.”

Unless you have evidence of the contrary, your argument is not applicable to this case.

Correlation != Causation

The more likely explanation for Castro seeking treatment in Spain is that Cuba is a relatively small country of only 11 million, and it should be expected that they're not at the very forefront of the world on every area of medical expertise.

Yet the US has double the carbon footprint per capita of China and more than 8x that of India. It would be much easier for Western countries to cut their resource consumption in half than for Eastern countries to cut their population in half.

Anything can be construed as a racist comment by an unreasonable person. I don't see any legitimate cause for a reasonable person to construe it as such however.

And although it shouldn't really matter, I say the above as a person of Chinese heritage, who does not speak for others of Chinese heritage. But if you aren't even of Chinese heritage, and are attempting to be outraged on our behalf, I would take a long, hard look at what misguided ideology brought you to post that comment.

JunOS is based on FreeBSD, which doesn't have a fix yet. Not sure about the different variants of Cisco IOS. You wouldn't run untrusted code on a router though, so spectre would not be a concern. In fact, it's probably better not to patch for it given the performance degradation.

Not sure how far back you're going, or which model of Cisco router you're referring to. I first cut my teeth on networking working at a Tier 2 carrier back in 2005 on Cisco GSR's (12000 series) which use a 200MHz R5000 MIPS CPU, but they were already quite long in the tooth at the time and were one of the few remaining networks still running them. And I do recall implementing ACL's to be an issue. Not sure if you were referring to ACL's or BGP policies themselves when referring to securing BGP.

These days, a full BGP capable router starts with the ASR1001 for Cisco which starts with a 32bit 1.5GHz CPU + 4GB RAM on the RP1 and goes up to a 64bit quad-core 2.2GHz CPU + 8-64GB on the RP3. Juniper land, the lowest end non-EOS router would be the MX80 which comes with a 1.33GHz PPC CPU and 2GB RAM, but unofficially Juniper will always steer you towards the MX104 with a 1.8GHz CPU and 4GB of RAM. I can't comment on the ASR's, but we have MX80's and we can do line rate ACL's with hundreds of terms in ASICs without issue. BGP policies themselves are still handled by the CPU though, and are indeed quite slow on the MX80's with full convergence taking up to 20 minutes or so. We've mostly relegated them to core switching duty at this point though, and are waiting for the new MX204's (800Gbps in 1U) to become mature enough before replacing them.

Moving up a bit, we use MX480's as well which we currently have routing engines with 2GHz Intel CPU's and 4GB of RAM, which I believe these are already EOS, but not enough of an issue for us to buy upgraded routing engines for this platform. These do full table re-convergence in about a minute or two. I believe quad-core 1.8GHz is standard now though, with up to hex-core 2GHz available. I don't think CPU's are really much of an issue anymore, although obviously still not as fast as what you can find easily enough in commodity hardware. The ASICs handle most things flawlessly though.

I run a not too small hosting ISP today, and ten years ago I used routers based on commodity hardware running OpenBSD. Back when we were at Gbps scale and most customers were on 100Mb links, this worked fine. However, it did not scale to 10Gbps+, let alone the 100Gbps+ of capacity we're at today.

Beside the obvious case of performance not keeping up in aggregate, performance for just customers being on 1Gbps links was not as good. We found individual TCP session throughput routed through commodity hardware was noticeably lower than using a layer 3 ASICS based switch despite various attempts at tweaking various kernel sysctl variables.

Also, because nobody operates commodity based hardware routers at carrier scale, you cannot trust any open source BGP daemon's implementation of BGP confederations if they even have it at all. At that, I wouldn't really trust any vendor other than Cisco or Juniper for carrier scale routing.

So even if someone were to create a popular, open source routing project making use of DPDK to increase performance scalability on commodity hardware, I'd still stick to Cisco or Juniper solutions like CSR 1000V or vMX for the foreseeable future if I really wanted to use commodity hardware, as the full feature set is going to be proven and mature. I'd want to see any new product stand up well for 5+ years at carrier scale production use before I'd give it any serious consideration.

Even then, I'm not sure how well DPDK will stand up to UDP reflection volumetric type attacks which now dominate DDOS. The top packets/s levels achieved are barely sufficient for simple routing, and would likely drop precipitously with a modest ACL in place, in comparison to ASICS based routers being able to still do full line rate with ACL's that have a large number (hundreds) of terms.