bitwiseand

Please don't discourage people without having the full view. There are many good low-level teams with software first people. At least in the bay area there are many exciting projects for people with this skill set. Self driving cars (Waymo, Tesla etc) , VR / AR headsets (Microsoft, Facebook etc.), Phones (Qualcomm, Google etc.) , Wearables (Apple, Fitbit) GPUs (Nvidia) and startups AirWare etc..

Here is a sample opening at Waymo - https://careers.google.com/jobs/#!t=jo&jid=/waymo/embedded-s...

Sure my experience may be skewed too but there are definitely great jobs with rewarding experiences of shipping tangible products for low level programmers. Not many people get the joy of shipping something your friends and family use and literally say "wow".

If a system performance is profiled as being dominated by 80% A , 19% B and 1 % C. I'd focus on working on A first to get maximum gains. Amdahl's law gives you the backing as to why you should do this.

As a real world example, if an operation involves a network call and you see the RTT dominating the time. You may want to think of ways to avoid the call (caching etc..) if possible to get really good gains.

I fully agree with you. It's not just infrastructure but also devices and the surrounding ecosystem. I work in this space and let me assure you there are many jobs with GREAT pay.

I"ll go on and make another bold claim. Focusing on lower level stuff and systems concepts lay an excellent foundation for designing complex systems regardless of the language used. Once you understand how a program is executed from the ground up i.e. right from the program counter to page table lookups to cache hits to cache coherency, all abstractions are easier to deconstruct and understand. I work up and down the stack and this has been my, quite possibly just anecdotal, experience.

Writing and designing code that is mindful of latencies (Amdahl's law). Temporal / Spatial locality, avoiding needless copies etc.. This approach needs to start from design and also follow into implementing the code. Moreover, this is done without compromising on readability.

A self-driving car, as proposed by Waymo and many others, in no way relies just on GPS. These beasts have fusion of many sensors with built in redundancy.

Technology improves and evolves. If it didn't you wouldn't be so reliant on Google Maps. We convince people of progress by a safe track record. Google maps may fail occasionally but more often than not it gets you to your destination at the estimated time.

Yes self-driving cars can't be "more often than not" safe. But starting with smaller areas and showing the difference it makes on people's lives and the environment can be a good start.

"There are only two hard problems in CS : 1. Naming things. 2. Cache invalidation. "

- Allow an unambiguous, never "played with", chronological timeline. Have a separate view that's your ML playground.

I disagree. The alternate to a vision you may not agree with is not having two visions. Use data to support one not both.

Thanks :)

Edit: I also wrote my comment because the article is beginner friendly. A lot of beginners will get the right idea about CAP once they go through comments and then back again to your article.

No need to be sorry. I liked the rest of the article. Thanks for that.

I liked the article but I feel the CAP theorem is again misquoted; it often leads to misunderstanding. From the article - "but they would still confront the reality of the CAP theorem: your system can be consistent, available, or partition-tolerant, and you can only pick two"

The CAP theorem states that in the event of a network-partition you have to choose one of C or A. More intuitively, any delay between nodes can be modeled as a temporary network partition and in that event you have but two choices either wait to return the latest data at a peer node (C) or return the last available data at a peer node (A).

Edit: Switched C and A

This is essentially same as processes sharing (via Page Table mapping) one .so file AKA Dynamic Linking :).

AFAIK, this is how docker CoW works. Your read-only parts i.e. base OS / starting point of the image is always shared. As you make changes a per-container R/W layer records those changes. This link explains it well -

https://docs.docker.com/engine/userguide/storagedriver/image...

The 90 reforms were by the same person you are criticizing.

Do you really think people will install and use PayTm apps overnight in villages ?. Was there any research done on mobile literacy or making things easier in rural areas ?

Also, you wish to ignore facts and reasoning posted by economists all in the name of "disruption". And FYI The Planning Commission of India AKA "Policy Pundits" consists of renowned economists.

"Should we call transportation a failure and put a halt to every mode of transportation (be it autos, cars, buses, trains, planes etc) just because of this statistic or should we work towards improving the system?"

Are you actually comparing currency to transportation ? People have a choice in the mode of transport. Your villager however can't use bitcoins because his Rs.500 note isn't legal tender.

"I have a wider positive perspective that no large-scale riots or coup d'état happened that would have sent the Indian economy in a downward spiral or worse: civil war."

Your standards for a successful policy are shockingly low. And stop lying, you have no sympathy, you just called a 100 deaths as having a "narrow perspective".

Do you also disagree with the countless economists that have criticized the move based on theory and facts. Or is that "foreign propaganda" for you ?

"Seriously? In a populace of a billion the death of 100 people for such a huge economic move is close to nothing."

This might be a stat for you but if it was your kin maybe you won't feel the same way.

Google works with a subsidiary of the Railways called RailTel. A lot of the infrastructure / backbone was supplied by RailTel which allowed the project to move fast.

I took 213 at CMU. Can't recommend it highly enough. A lot of other intro systems courses are based off that. It is a prerequisite for most classes moving forward at CMU. The textbook is also available online as a pdf (Google it). First 2 or 3 labs deal with bitwise, assembly (buf overflow attacks - bomb lab), then cache lab (matrix multiply performance), then signals, then implementing malloc, and finally using pthread API / threads to create a proxy server.