Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Microsoft and Red Hat partner

blogs.microsoft.com

Post reply on HN
Print view View original

171–177 of 177 posts

Re: Microsoft and Red Hat partner

#171

Post by sivaedupuganti »

aexaey wrote: post #133
mobiplayer wrote: post #107

Earlier quoted context omitted.

Hi aexaey, There are some things wrong on your comment, please let me comment on them: I don't think A0 are capped at all, I don't know where did you get that: user@A0VM:~$ speedtest-cli Retrieving speedtest.net configuration... Retrieving speedtest.net server list... Testing from Microsoft Corporation (40.113.XX.XX)... Selecting best server based on latency... Hosted by KsFiberNet (Wichita, KS) [45.26 km]: 139.703 m…

ILPIP look promising. I'll try it, thanks! Speed test though... hm... 22Mbit/s is not exactly unrestricted, plus not sure how long is the burst that "speedtest-cli" makes. In my experience A0's uplink is burstable (but unusably slow when recovering from a burst), with long-term average being bang-on 5Mbps. I do of course see exactly one "my" private IP in traceroute, but I'm not talking about that. I meant there are…

Based on iperf tests, it appears uplink on a A0 is being capped around 5Mbps. Considering I work with Azure Networking, I will find more details on this internally.

I generally work with Azure CLI (https://github.com/azure/azure-xplat-cli) and ARM templates (https://github.com/Azure/azure-quickstart-templates), helps with simpler configuration and consistent results across deployments.

Though we are aggressively working on adding more features and improving documentation, evidently there are gaps in certain areas. Please feel free to reach out to us through Twitter (@AzureSupport) or Stackoverflow (tag-Azure), for anything we can help with your deployments on Azure.

Re: Microsoft and Red Hat partner

#172

Post by jacquesm »

stronglikedan wrote: post #77
Someone1234 wrote: post #63

Earlier quoted context omitted.

With all due respect: I don't buy it. That isn't how the technology works. Compilation in particular would never even hit the hypervisor layer regardless of which one you were utilising. It is CPU/memory bound. The difference between hypervisors for IO is tiny. They're all slower than native, but vary very little between one another. That's why the manufacturers have all almost given up trying to use performance for…

I have a developer who can show a marked difference in performance between VMWare Fusion (paid) and VirtualBox (free) running Windows 7 on OSX. Same Windows ISO used to install both, and both running on the same hardware and OS, with exact VM configs (as close a you can get between the two). I'm talking a night-and-day difference - VMWare Fusion is usable, but VirtualBox is not. After reading your comment, and admitt…

It might be worth your time to run that same benchmark without any hypervisor to establish a baseline.

Re: Microsoft and Red Hat partner

#173

Post by CaptSpify »

avar wrote: post #170
CaptSpify wrote: post #119

Earlier quoted context omitted.

maybe, maybe not. What that tells me though, is that they didn't sit down and say: "Here's how we optimize this to work for the cloud". I can't say other distro's do either, but it seems like something they should do

I don't think they should. This way lies madness. You want e.g. the kernel & packages to be pruned down to only have the things needed for each cloud host? That means that for N cloud hosts Red Hat would have to potentially build N different patches for any update or security fix. Now you can't certify software to run on "RHEL 7" anymore, it has to be "RHEL 7, assuming it has XYZ, which some cloud hosts don't". It ca…

> That means that for N cloud hosts Red Hat would have to potentially build N different patches for any update or security fix.

Why would they have to do that? AFAIK, patches apply to packages, not the entire distro. If $package_x isn't installed, it doesn't get the patch. If it is installed, it does get the patch.

And for me, the concern isn't space, as much as running processes, and littered un-needed files.

Re: Microsoft and Red Hat partner

#174

Post by X-Istence »

aexaey wrote: post #149
mobiplayer wrote: post #142

Earlier quoted context omitted.

Yeah, the ICMP stuff could be a bit annoying :) My comment about the traceroute was because you previously said that you've found those weird IP addresses between the VM and Internet. That's not how I actually see it, but I get your point, too. The ones you identify as packet loss are just the ones you didn't get an ICMP back. I don't know anything about your background, but as per my experience with networking I've…

Actually, in public Internet traceroutes are reasonably reliable. It's corporate networks where you would expect weird stuff like that. > (About #12, WTF? Weird!) There is a fairly boring explanation to that. Similar to public IPv4 exhaustion, RFC1918-style private IPv4 addresses can easily be exhausted in a big private network as well. If you have noticed, MS has actually run out of RFC1918, and uses RFC6598 (a.k.a.…

This is why it is unfortunate that more companies are not using IPv6 or moving towards it.

Currently working at a large MSP, and all of our stuff is still IPv4 only. Although we happen to have a ton of extra IPv4 space, so we aren't as concerned, but there is no movement towards IPv6 at all.

Re: Microsoft and Red Hat partner

#175

Post by avar »

CaptSpify wrote: post #173
avar wrote: post #170

Earlier quoted context omitted.

I don't think they should. This way lies madness. You want e.g. the kernel & packages to be pruned down to only have the things needed for each cloud host? That means that for N cloud hosts Red Hat would have to potentially build N different patches for any update or security fix. Now you can't certify software to run on "RHEL 7" anymore, it has to be "RHEL 7, assuming it has XYZ, which some cloud hosts don't". It ca…

> That means that for N cloud hosts Red Hat would have to potentially build N different patches for any update or security fix. Why would they have to do that? AFAIK, patches apply to packages, not the entire distro. If $package_x isn't installed, it doesn't get the patch. If it is installed, it does get the patch. And for me, the concern isn't space, as much as running processes, and littered un-needed files.

If you're concerned about either of those RHEL is not the distro for you. It has a bunch of running processes, some of them are even written in Python! Talk about unoptimal. Similarly it's not the smallest Linux distro by far.

I think this whole line of argument is just some misplaced nostalgia for distro micro-optimization. It's not the mid-90s anymore. Space and CPU is cheap, you're not going to gain anything significant by trimming down your distro.

If those things were actually important you wouldn't be using Azure in the first place.

Re: Microsoft and Red Hat partner

#176

Post by technofiend »

edgyswingset wrote: post #70
technofiend wrote: post #54

Earlier quoted context omitted.

You may be right, I don't know. I suppose the acid test is when YC companies start posting for front-end developers with C#, .NET and UNIX experience versus what's required today, i.e. either node.js, django, ruby, etc.

Why YC companies? There are lots of other startups out there (some of which even using .NET).

Ah, great question. I sort of view the YC guys as cutting edge, i.e. willing and able to adopt new and sometimes still changing technology. In contrast to a Fortune 500 shop which in my humble opinion is unlikely to adopt a wholesale change to a new technology.

Re: Microsoft and Red Hat partner

#177

Post by X-Istence »

aexaey wrote: post #104
X-Istence wrote: post #98

Earlier quoted context omitted.

I don't see why private IP's in a trace route is necessarily wrong... Many large providers are numbering their hops with private IP space and routing public space across it because they don't want to waste /30's of public space for each point to point. Yes, /31 is an option, but there were a lot of edge cases or network gear that didn't support it.

Yes, you are absolutely right that IPv4 addresses are scarce. Which bring a related question - what's up with none of AWS/Azure/GCE supporting IPv6?

Unfortunately IPv6 in cloud deployments is still very much lacking. OpenStack is one of those where IPv6 has only recently become something that is being built into OpenStack.
Post reply on HN