gregdunn

Disclaimer: I work at AWS, primarily in the compute space, but I'm not speaking in an official capacity.

I would say they fulfill different purposes. The SSM agent has quite a bit of additional functionality, even within the Session Manager portion. It's more of your solution for online, general day to day access.

Serial console will let you fix issues when you have lost the ability to boot an instance, or network connectivity has failed. When SSH or Session Manager are available, I personally would opt to utilize them over the serial console. But if I have an instance that I can't reach via those, am unable to replace it for whatever reason, and need to bring it back online, serial console would be what I would reach for.

Disclaimer: I work at AWS, primarily in the compute space, but I'm not speaking in an official capacity.

As fguerraz mentioned, modern AWS instance families are basically all powered by Nitro, which refers to the ecosystem around the hypervisor and hardware acceleration cards utilized. https://aws.amazon.com/ec2/nitro/

>Maybe Amazon is doing something similar?

Yep!

https://sustainability.aboutamazon.com/environment/sustainab...

Disclaimer: Amazon employee, not speaking on behalf of the company, just posting a link to something I am aware of.

Disclaimer: I work at AWS, totally different team, and had never heard of this product until this announcement. This is 100% my personal opinion and I'm not operating in any official capacity.

>Personally, I'd probably just suffer through having to spend a week doing a slow internet upload/download rather than paying for Snowcone.

Well, I think there's two things here.

1) A lot of businesses probably won't be willing to spend a week with reduced internet capacity to upload stuff. Things we as single users might be okay with might not always translate to being a good fit for a business overall.

2) My reading is that some of the use cases for this are areas where you are likely to have limited or no internet connectivity.

From https://aws.amazon.com/snowcone/

>AWS Snowcone is built for edge computing and data storage outside of a data center. It is designed to meet stringent standards for ruggedization, including free-fall shock, operational vibration, and more. When sealed, the device is both dust-tight and water-resistant, protected from water jets on all sides. Snowcone has a wide operating temperature range from freezing to desert-like conditions, and withstands even harsher temperatures in storage.

and:

>AWS Snowcone deploys virtually anywhere you need it. It features 2 CPUs, 4 GB of memory, 8 TB of usable storage, Wi-Fi or wired access, and USB-C power using a cord or optional battery. You can put it in a messenger bag, run it in an autonomous vehicle or an airplane, or even attach it to a drone.

So, ruggedization and the ability to run this totally off battery points me towards thinking about use cases where there's not existing infrastructure to take advantage of. I guess this supported by the 'run it in an autonomous vehicle or airplane' bit I'm quoting as well.

Market, and point in the career.

If you've got 15-20 years of experience and you've never stayed somewhere more than 12-18 months, it's a very different scenario than someone with 5-6 years, even in SV.

It depends on the company and their needs. In the majority of cases, I would say this is a positive thing for your resume.

If their goal is to hire someone for a specific position and they hope that person stays in that same role long term, maybe not so much. Companies are generally happy to just have you stick around, though - if you are moving within the company, you should in theory still be providing value to the company, and potentially even more value, if the moves are upwards.

This matches my experiences, and I'm certainly no Distinguished Engineer, but as a PE I would still have relatively few options to work at a similar level and compensation if I was looking. Thankfully I'm quite happy where I am.

Disclaimer: I work at AWS on an unrelated team. I was not involved in development of this product. Opinions stated are my own, and not necessarily a reflection of my employer. Nothing here is being posted in any sort of official capacity.

There's lots of focus here in the comments on the code reviewer portion, but one of the things I'm most excited about is the profiler - https://aws.amazon.com/codeguru/features/

I do a lot of performance engineering work, and one of my go to tools for visualizing where programs are spending their time is flamegraphs. While you can certainly create them with profilers besides CodeGuru (and I do not work with Java, so I haven't yet had the chance to check out CodeGuru for any of my use cases), I'm super excited about anything that gets more people using them. They make it very easy to see where your optimization opportunities are, and I have personally found them very useful when working with our customers - they're way easier, in my opinion, to go through and explain than just looking at raw perf output or similar.

Disclaimer: I work at AWS, but this post isn't being made in any sort of official capacity, I have no relation to the team in question (this is the first I've even heard of the service), and the opinions here are entirely my own and not necessarily a reflection of that of my employer.

> I wonder what kind of future this spells for quantum computing - will it continue to spread or will it be limited/stunted by being controlled by only the few?

I feel like this is a step in the right direction, though. Right now using quantum computers is totally outside of the realm of possibility for the vast majority of people - they're simply too expensive in materials cost, expertise to create, conditions for operation, etc. etc. etc. - without services like this one. The only chance an "everyday" person has to try out a quantum computer is to rent time on someone's else's.

I don't think at a similar point in the life of classical computers we had options like this that were readily available - you could rent time on the computers, but I can't imagine that getting access to them was as easy as it will be today with the internet being a thing and service providers offering high granularity on billing.

My understanding (and I'm not even remotely an expert, so I could be totally off base here!) is that it's an open question on whether or not quantum computing will ever even be doable in environments where classical computing works - it might not be within the realm of what physics allows for it ever to be possible to have a quantum computer powered smartphone.

I hope access is ubiquitous someday for people, but in general I feel like this is a good step while that's not practical.

High performance networking: https://www.iovisor.org/technology/xdp

Cloudflare uses XDP for a variety of things: https://blog.cloudflare.com/xdpcap/ https://blog.cloudflare.com/l4drop-xdp-ebpf-based-ddos-mitig...

Performance engineering, debugging, etc: https://github.com/iovisor/bcc https://github.com/iovisor/bpftrace

Brendan Gregg is all on board the BPF train as well - check out all the blogs he's written about it over the past several years: http://www.brendangregg.com/blog/

IMO, (E)BPF is one of the most exciting technologies to be introduced in the past half decade or so. bcc and now bpftrace have become two of my favorite tools to reach for when assisting EC2 customers with performance issues. (Edit: I suppose I should note that that's a personal preference and not AWS policy, and also that the performance issues aren't special to EC2 ;))

I feel like a unique ID isn't enough to protect your identity from an analytics provider, especially if they're receiving analytics on you from multiple sources.

It's not strong enough to overcome the forces keeping us together.

But that might not be the case for forever: https://en.wikipedia.org/wiki/Big_Rip

A decent amount of countries offer point based immigration visas, where a degree certainly helps, but is not a hard requirement.

For example, Japan's Highly Skilled Worker visa can be pretty easily achieved without a degree.

>I'm forced to wonder whether the same strain of yeast also survived on the surface near the original brewery location

Maybe something similar to it. Commercial breweries were selective in reusing batches of yeast even back then. House strains were refined over time to reuse batches that had fermented the most reliably, produced the fewest off flavors, etc. The yeast they used might also not have been local in origin.

But the wild ancestor might still be around, somewhere. (It's also possible the yeast they have is a wild yeast contaminate, as noted in one of my other comments in here)

I've read a dozen or so articles on this (It's been a somewhat popular discussion on several homebrewing communities focused on using interesting/rare/"alternative" yeasts), and the beer that's been brewed so far has only used a subset of the yeast cultured from the bottles.

If they were trying to more faithfully reproduce the beer they found, they'd need to use all of the yeast cultures they recovered. (They commercial beer listed here was not actually attempting to reproduce the beer - just use the yeast)

There's some debate as to whether or not the yeast they're using is a contaminate, as well. Sacch strains do not seem to live long enough in fermented beer to make it 200+ years (though there's evidence that Brett strains will do just fine), and the samples were taken from bottles that had been decanted 20 years prior. The characteristics reported of the yeast are also similar to what many people find when using wild yeast. That might be due to them being wild yeast contaminates, or due to the selective "breeding" pressure of commercial yeasts having not yet eliminated these traits.

I wish they would sequence the yeast and release the results.

You can also get VTune as part of System Studio through a 90 day perpetually renewable community support license - https://software.intel.com/en-us/system-studio/choose-downlo...

No talking to Intel's engineers, but kind of cool if you're alright going without a real support channel.

>Rovelli's position is that time is not fundamental, not that it does not exist. It emerges from something more fundamental.

Well, I'm a layperson, and I'm guessing you are a physicist (or at least much more inclined towards it than I am), so I'm hesitant to argue here, but...

If that's what Rovelli means, he really should say that :)

I've got The Order of Time in front of me and in it, as well as plenty of articles and interviews (targeted at laypeople), he says time doesn't exist, uses phrases such as 'A world without time', etc. Good portions of the book are prose where he muses on things like the meaning of life if time doesn't exist. He calls our perception of it an illusion.

> our block universe

In Order of Time he specifically says '[Our world] is not a "static" world, or a "block universe"'.

I feel disconnected here, because I'm definitely not able to argue with what you're saying, but Rovelli's words from a book 23 years newer than your referenced article, seem to directly contradict what you're arguing - he explicitly states he does not believe we live in a block universe.

>Galaxies probably don't cease to exist at the moment they cross out of our causal cone with the metric expansion, or soon afterwards. We exist even though there are observers who saw our ancestors cross out of their causal cones. Do you think the density and spectrum of the CMB evolve very differently for them and for us? Do you assert that such a question is meaningless? Do you think Rovelli does? (If so, why do you think that?)

No, I am saying specifically that saying something is happening /now/ when it is outside of our light cone is a meaningless statement. It's not a matter of whether or not something exists when outside of our light cone (Though in some ways, as it can never effect us, it might as well not), but whether or not something distant can happen now. It doesn't even need to be outside of our light cone - just far off. 'A present that is common throughout the whole universe does not exist. There is a present that is near to us, but nothing that is "present" in a far-off galaxy. The present is a localized rather than a global phenomenon."

Early on in the book, Rovelli argues that the concept of "now" or the present really only applies on a scale that's about the size of the Earth.

As for what I believe, I'm not sure. I think Rovelli makes compelling arguments. But I could say the same about Smolin and others. I think I lean towards Rovelli's interpretation, or at least what I (hopefully!) understand of it.

I'm perfectly willing to accept that you could be totally correct here and that I am wildly off base - but what I don't understand is why Rovelli's non-science paper writings seem to argue very differently than what you are saying. Am I misinterpreting them? Is he dumbing things down for the layperson? Why does he explicitly say we do not live in a block universe, and that time doesn't exist?

> Everyone in the same reference frame (or close enough) is going to agree about the order of events

Not necessarily. On a macro scale for general human interactions, for the most part, but the only thing observers have to agree on is space time interval and causality. Space, time, and order (if not important to causality) might be different.

> It is perfectly okay to say something is happening at 1 million light years away.

Well, maybe. Maybe not. Carlo Rovelli would argue that time doesn't exist like that (or at all) and that saying that something is happening now when it is beyond our lightcone would be a meaningless statement, and a lot of physicists would agree with him. (A lot would disagree, too.)

Reference frames only clear this up if time does exist in a meaningful way and 'now' is more than a construction of our own observation.

The 3 years/10^18 figures I used were taken from https://arxiv.org/pdf/1304.2821.pdf :

"Using the largest allowed value for the photon mass from other experiments, we find a lower limit of about 3 yr on the photon rest-frame lifetime. For photons in the visible spectrum, this corresponds to a lifetime around 10^18 yrs."

Which does work under the assumption that photons have a non-zero rest mass, and as such, could decay. I probably should have phrased my post better - this is hardly settled science, and the majority of physicists would almost certainly say that photons, with our current accepted theories, do not have rest mass. SR is pretty explicit on this :). But we can't say for sure that photons have zero rest mass - experiments have allowed us to set an upper bound on the rest mass, but not allow us to deterministically say they have zero rest mass. In such a case that photons do have rest mass, we would need to stop saying "The speed of light", and instead say "The speed of a (rest) massless particle", though this might be worth doing in general - gluons (and gravitons, if they exist) should be similarly massless.

Yep. Time still passes for photons, but, at a rate so insanely slow in comparison to how we view it.

10^18 years by our perspective would only be 3 years by the perspective of something traveling at the speed of light.

We observe things going the speed of light all the time =]

Active FAANG employee here, so a bit of my take on it. Personal opinion, of course, and not any sort of official Amazon statement.

Management DOES do a lot to prioritize/delegate/lubricate channels of communication, etc. That is their primary role.

But you have more engineers than you have managers. You have more people providing a more varied set of insights into what should be prioritized, what general work needs to be done, what opportunities exist, etc.

To a certain extent, you have to be willing to let some people sometimes be working a little sub-optimally to allow the autonomy that results in making some of the crazy cool products and services these companies create. That autonomy being available is one of the big things that drew me to Amazon, and it's something I believe I've taken full advantage of to the company's benefit.

Giving people the latitude to run projects and create PoCs before getting full buy in from management allows people to be creative. But yes, if you've spent a year working on a project, you should be expected to show the results of what you've done. Some stuff is more ambitious, sure - but even when the results aren't immediately obvious, you do need to be able to explain the potential and what data backs up that potential and the ability for the project to reach it.

From my experiences over the past five years, being able to find opportunities for improvement is hugely important to the culture and the promotion process. You need to be able to identify these opportunities, and that generally means some sort of metric is available to work from, and measure against as you try to improve it. (Of course metrics and statistics can be gamed, but I'd argue it's not good to go through life assuming everyone is a bad actor). It's a skill that sometimes needs to be developed, and it's something I work with people on to help them with the process, but I think it's a very good thing in general. I've seen a lot of positive come out of it.

My two cents, anyway.

For now they are, and that might hold true in the future as well.

There are some projects to bring BPF features needed (generally called eBPF) to FreeBSD, such as https://github.com/YutaroHayakawa/generic-ebpf - but there's no accepted mainline implementation as of yet.

>But my most basic experiments so far have failed, and I don't know how to get support.

I'd recommend the #iovisor irc channel on oftc. I haven't stopped by in a bit, but the times I did, I usually was able to get assistance from nice people!

Hey Brendan! Super exciting - I'm already updating some internal documentation to point people towards this :)

When are we getting a Linux performance engineering book with all the bpf/bcc/bpftrace stuff in it?

Unless I'm woefully off base here, if the satellites were incorrect, you would basically be permanently 300m off, not just temporarily.

There's not so many GPS satellites out there that you're going to be bouncing around them all the time - even if only one is affected, it would be very noticeable for extended periods of time.

>Whether this qualifies as exceptional is, of course, arguable, but I'm arguing that it is. I could understand the point that it doesn't have to be, but, to be actually convinced, I'd want to see evidence that it's well understood and well implemented enough that neither rare expertise, substantial engineering effort, nor constrained configuration (hardware or software) would be required to take advantage of it. I'd expect most technically-minded decision makers to think similarly.

Oh. My apologies for misunderstanding your point.

SR-IOV is available on basically any and all server grade NICs, and is quite simple to use. With Azure and AWS it's basically just making sure you have the proper driver installed (gotten for free on basically all modern kernels) and flipping a command switch.

If you're rolling your own virtualization stack, it's generally about as simple as any other task for that stack.

With vSphere it takes a matter of seconds: https://docs.vmware.com/en/VMware-vSphere/6.7/com.vmware.vsp...

Similarly easy for XenServer: https://support.citrix.com/article/CTX126624

A little bit more work with the common KVM management options, but still a very simple task as far as Linux sysadmin tasks go: https://access.redhat.com/documentation/en-us/red_hat_enterp...

OpenStack is a bit more complicated, but frankly, less complicated than plenty other tasks in OpenStack: https://docs.openstack.org/mitaka/networking-guide/config-sr...

All of the real setup work has to be done at the hypervisor level, but you're primarily just doing two things: Creating VFs, and assigning them to VMs. The driver does all of the rest of the hard work. I would argue that any Linux or vSphere admin with any real amount of experience should be able to read any of the documentation I linked and be able to confidently work through it in an hour or two.

For the guest, just making sure the driver is installed should be all that's required. For ixgbevf, the ubiquitous commercial option, it's been in-tree for the Linux kernel for at least half a decade.

Once VFs are created and assigned, it largely "Just Works". The only real caveat I know of is that seamless live migration of the guest is no longer an option, because now all of the network virtualization is handled in the hardware instead of the hypervisor.

For sure! But that's a matter of the provider's placement decisions, and not inherent to virtualization.

By no means do you need DPDK to basically eliminate the latency difference - I just wanted to point out how low latency can go in general.

A vm using SR-IOV with ixgbevf on good ol' Intel 82599 from 7 years ago will not have a latency difference noticeable to the overwhelming majority of use cases vs. bare metal.

>Visualization overhead for networking is too high for the cost.

Do you mean virtualization?

If so, I recommend looking into testing this with SR-IOV based NICs and passing through a VF to the guest. Even in regular operation the latency difference between bare metal and an ixgbevf virtualized NIC all but disappear into levels well below anything that would be meaningful for voice communication.

Moving to a DPDK based poll mode driver would reduce the latency differences even further.

Edit: https://01.org/packet-processing/blogs/nsundar/2018/nfv-i-ho... some actual numbers w/ DPDK on bare metal vs vm

Disclaimer: I work for a cloud company, but SR-IOV knowledge in general is something I had from my days running a vmware environment, and not anything new :)