> My objective is to better understand how computers work, how ruby works...
Check out Pat Shaughnessy's Ruby Under a Microscope [0].
It gives a nice overview of the internals of MRI. It doesn't cover a who lot of the C code, but references plenty of it and where it can be found in the source code of MRI. Grab the book, the source for MRI, and do some digging.
I only looked very briefly, but yes in this case 5.1 driver hasn't made any changes other than the version. But doing a quick vimdiff with a few of the other drivers show that the files have seen some substantial changes over time, and in some cases the small differences between two versions of a driver are to work around bugs, whether new or newly identified.
> It is very cool to see that the class is being taught by a group of juniors/seniors
I'm not sure how common such courses are, but where I went they were called "Student Directed Seminars" and allowed for some interesting courses that normally wouldn't get offered.
> I learned two things that weren't widely reported at the time.
For what it's worth, the Anandtech review [0] mentioned your first issue in their review back in October. Anandtech has missed things in the past, but I trust them a lot to find and point out possible issues with hardware.
[0] Linking to the last page 'Final Words' section as it is mentioned up front and centre there. A lot of times, I'll read or skim the first page, and jump directly to the final page conclusion for hardware I just want a quick overview of - http://www.anandtech.com/show/9702/samsung-950-pro-ssd-revie...
I recently stepped into a role with a devops component, and one of my first surprises was just how slow status.aws.amazon.com was to update about ongoing issues. I had to scramble to find twitter and external forums confirmation for the client.
What's even worse is that when Amazon finally updates their status page it's usually still a green icon with a little i tick for "information" even if it was a partial outage. It takes a lot for the icons to go red which is what you'd look for if you're experiencing issues.
I do the same thing, often searching Twitter for "aws" or "outage" and find people complaining about the problem which confirms my suspicions. It's a sad state of affairs when you have to do this and Amazon doesn't seem interested in fixing it.
The most recent issue that affected me was when all EC2 instances in VPCs couldn't connect to S3. At all.
It wasn't indicated on the status page until after it was fixed. And it was indicated as a green check in a sea of green checks. With a small "i" in the corner to represent the outage.
I love AWS. It's not without fault but overall I think it's been well architected, well documented, and well implemented.
But the status page has got to be the ultimate example of what not to do.
Huh, I wonder if the status page is in fact based on any automated monitoring at all, or just manual updates? I guess probably automated monitoring, just not very good automated monitoring.
If you have a support agreement with them then file a ticket requesting better customer communication and link back here as an example of how to do it right.
I think everyone complains in forums and online but doesn't actually file tickets about it. These things are worth tickets too.
I take it you have no experience filing tickets with them. A typical ticket goes something like this:
1. File ticket.
2. Wait. Then wait some more. Even if you pay big money for a support contract, they take a long time to respond (often > 1 hour).
3. Get a response from a first level rep who has no access to anything, has little dev experience, and asks some inane questions which I'm convinced is a purposeful stalling tactic.
4. Play the dumb question/obvious response dance, waiting an hour or more for a response each time.
5. If you are lucky (usually a couple hours in now) they acknowledge there's some problem (but never give you any detail) and escalate your ticket to a higher level internal team. If you are unlucky, you are calling up your account rep (do you even have one??) and getting them to harass tech support.
6. Usually around now the problem "magically" disappears if you haven't already fixed it yourself.
7. If you are lucky, a few hours, days, weeks later you get a response asking if you are still having the problem? You, of course, are NOT having the problem since you long ago solved it yourself. If you are really unlucky they try to schedule a meeting with one of their "solution architects" who is then going to waste an hour of your time telling you how to properly "design" your software for the cloud (i.e. trying to sell you on even more of their services).
8. Ticket is closed having never gotten to the bottom of the problem, maybe get a survey.
I've never seen this go down differently. Filing more tickets isn't going to change this. You want to really change things?
STOP PAYING THEM!
If a few mid-sized customers stop paying them and make a big-stink when they do it, then I guarantee you things will change! Until then, they have little incentive to improve and the big customers have a direct line to Amazon so they can circumvent all this crap. It's up to the small and mid-sized customers to push for change and the most effective way to do this would be to spend your money elsewhere.
To be honest, I've always found their support to be really good. Sometimes it can be a little slow to start, but I regularly experience technicians that go way above what I would expect to assist me & deliver a great outcome. If other companies in Australia were as responsive as them (e.g. telcos), I'd be a very happy man. EDIT: I'm on Business Support, so maybe that's your issue?
I'm also in Australia and have nothing but good things to say about AWS support, and are usually solved by the first responder (not necessarily on the first response). The technical skill has generally been pretty good.
But it's not specific to us down under - the support contacts come from all over the globe. We dropped from Business to Developer support when the $A tanked in order to save a buck, and it just takes a little longer is all - no real drop in quality. I wish other large companies had their level of support quality.
I'm on business support too and generally am talking to a rep in minutes. They aren't always able to find the problem before I do, but I always get follow up details later on the how / why that they did determine.
I wish our experience was like this. We used to have business level but we dropped it because we weren't getting value for it. Our experience was slightly better when we had it but we still ended up either fixing most problems on our own or waiting them out.
Which is unacceptable for one of the largest infrastructure providers. So many times we were sitting around twiddling our thumbs waiting for our expensive amazon support to get back to us when things were broken.
Same experience here. But: I've had luck complaining with a few well-chose hashtags and mentions on twitter, getting the attention of a tech lead related to a particular AWS service.
One example: redshift. Had an expensive temporary cluster that couldn't be deleted, for days. Was stuck "pending" or "rebuilding". Assigned account rep would take forever to respond, and just didn't understand, would forward directions to using AWS console. Yeah, DOESN'T WORK. After a week decided to try getting attention on twitter, got it fixed in about 12 hours.
>2. Wait. Then wait some more. Even if you pay big money for a support contract, they take a long time to respond (often > 1 hour).
My experiences don't reflect this, perhaps we are familiar with different levels of support contracts. I use AWS for work only so I can only speak to one level if their support.
>3. Get a response from a first level rep who has no access to anything, has little dev experience, and asks some inane questions which I'm convinced is a purposeful stalling tactic.
4. Play the dumb question/obvious response dance, waiting an hour or more for a response each time.
I can't agree with this either. I almost always use their chat option and a rep is usually available within 15m unless there is an AWS outage.
I do however completely agree with 5 and 6, but I don't let it bother me. They can't expose too much info about their infrastructure. I'm usually just looking for a confirmation of an issue in their side or not which they have always been willing to provide.
If you're using aws for business and are unhappy with their current level if support maybe you should talk with their sales folks to find out about higher tier support plans.
I think a lot of folks feel that it's a useless endeavor, so they don't bother. Amazon's been operating this way for years, and they're quite a large company; it seems unlikely to me that fundamental change can happen inspired by customer tickets, even if you're paying for support.
Basically, if Netflix isn't the source of the complaint, they're not going to give two fucks.
/me suspects that netflix engineers get outage notifications through some other avenue than the status page.
day to day i mostly write software, but I also help manage our infrastructure (we're a small company - 9 people total, 4 engineers, I'm one of the 2 that understands managing servers well enough to support it). We were on linode up until about a year and change ago and switched to AWS/Opsworks to both decrease our infrastructure bill and increase our ability to scale horizontally quickly (for unfortunately long definitions of quickly - "running setup...")
Both Linode and Amazon suck at their status pages (though linode was quite informative about their DDoS outages that started on Christmas). Every amazon issue we've had, the status page only changed once they'd more or less fixed it. As far as I'm concerned their status page is basically useless unless it's an extended outage, at which point it's still basically useless...
They use the Lucas–Lehmer primality test [0], along with trial factoring candidate numbers up to a given bit depth to sift out some composites from the prime candidates quicker than a full LL test.
Thanks for pointing out the list and detailed views. I missed that when looking this morning as was bummed because I can't stand the unaligned-boxes-of-different-heights view that so many websites go for these days. Maybe I'm just not used to it because I recoil from it every time, but it messes up my read-from-left-to-right nature.
That said, two annoyances I just noticed with the list view (braindump style):
There is no header. I have no idea what the columns are. I can only guess, and that is useless for e.g. the rightmost column here [0]. Mental thoughts as I view it: It's just an icon? It's not clickable and doesn't appear to show anything useful. The speakers change to blue when I have my mouse over them. What does this mean? It's still not clickable... what is it doing?
Another problem related to not having a header: when I sort by e.g. views, the views are not actually shown. Maybe I wanted to see that information as well as having the rows sorted by the column.
Oh wait, I just noticed that there is a header there... but it's not clear it's for the columns of the table underneath it. They're not aligned... and it still doesn't explain what that column of icons is. But now I see that the number of views is shown as the leftmost column. I guessed that it was some sort of filesize initially (1.6B, 377.7M, etc.).
One last thing, I wish clicking the column in the header would toggle ascending/descending sorting like almost every other table I've interacted with. It's not clear at first that I need to go all the way over to the left to toggle that behaviour.
I see why you might link to the page you did since it has some additional information, and even provides a link to the more recent edition, but be aware that this is an old version of PLAI that has been updated as recently as 2012 [0].
Furthermore, the cs173 class at Brown now uses a different book, Programming and Programming Languages [1], that was updated as recently as 2014. It's very much in the same spirit, but uses Pyret instead of plai-typed.
Another thing to note is that cs173 had a MOOC-like online offering in 2012, and the videos are still available [2].
Thanks for mentioning Pyret, I've searched for it and it made me laugh discovering the extension of the files is .arr (some would say I'm really easily amused).
I've been watching the videos from 2012, and the professor sprinkles that humor throughout the lectures, and done well in that its not annoying (to me at least).
What was copied? I flipped through my copy of Expert C Programming and didn't see either of the diagrams.
If instead by "straight from" you mean "similar to", well, there is only a handful of ways to explain this material so of course they are going to be similar.
Please don't throw around accusations of copying lightly. I would like to see more material like this shared, not less.
I much prefer to have the option exposed in the UI, but you can do this with any HTML5 video element by setting the video element's playbackRate. Often, it's as easy as 'document.getElementsByTagName('video')[0].playbackRate = 1.5'. I have a bookmarklet that does exactly this, so I love to see HTML5 video being the default more and more.
Check out Pat Shaughnessy's Ruby Under a Microscope [0].
It gives a nice overview of the internals of MRI. It doesn't cover a who lot of the C code, but references plenty of it and where it can be found in the source code of MRI. Grab the book, the source for MRI, and do some digging.
[0] https://www.amazon.com/Ruby-Under-Microscope-Illustrated-Int...