I have two cars: a '96 Jeep Cherokee and an '01 M Coupe. You know what I love about both of them? The climate control system is analog. I user a slider or knob, feel the resistance, and know the temperature will adjust. The radios are simple: a few preset (physical) buttons, a volume knob, and a tuner knob. Sure, bluetooth would be nice, but I have a cigarette lighter dongle that works just fine over FM for streaming music and taking calls (I actually still have the cigarette lighters for both cars, too).
My wife, OTOH, has had a stream of cars with electronic climate control, complex infotainment systems, and all sorts of other bells and whistles. You know why we got rid of the last one? The climate control system kept thinking it was 20F outside and adjusted the heat accordingly. This in the summer in Texas. The automaker, despite repeated visits every summer, couldn't resolve the issue.
Oh, and navigation? For the few times I don't know where I'm going (really, it's scary how people rely on nav systems for drives they do every day), a quick glance at Google maps on my phone orients me (usually before I get in the car).
I'll allow some local microprocessor control for drivability and performance, but when it comes to the creature comforts and extras, I want them simple and functional. I want my car to talk to me through the engine, not the speakers.
Milk and meat are around the periphery because their display cases are connected to (or close to) the bulk cold storage in the stores. It's part of preserving the "cold chain" of ensuring that products that need constant refrigeration throughout the supply chain actually get constant refrigeration.
Most of the marketing text written about grocery store layouts was developed after the layouts were already in use. Most of the layout quirks are the way they are for more practical and mundane reasons. Layout as a conspiracy makes a great story, but in general, it's just that. Yes, impulse aisles are exceptions as are some other elements in the store, but for the most part, the practicalities of storing and presenting large amounts of food determine the layout.
One thing that gets me in discussions across organizations is how poorly the "cloud" is defined. IT often has a slightly different definition of the cloud than senior management than end users than tech support (and so on). Are we moving email to the cloud, setting up a collection of virtual servers to run our custom apps on, using Salesforce, creating a hybrid solution for redundancy? Even in those situations, the motivations and concerns are often different.
Then there's the accounting aspect. Is the shift simply to move IT from CapEx to OpEx? Does the IT staff understand the difference? Has management worked out a 3 year forecast to make sure the financials actually work out?
When making these decisions, all major stakeholders need to be involved and represented. You need to look at it from different perspectives and make sure everyone understands those perspectives. Only then can you really make an informed decision. Yes, that's much more difficult than simply believing the sales guy, but for something as important as IT infrastructure, it's what you should do.
I work on the laboratory informatics/gene sequencing side of the world and these conversations are becoming more common. To help give scientists some perspective, I've putting together some blog posts that introduce all the different angles:
Taking it a step further, the core platform could be a general "market" engine that simply provides a method for posting bids and asks. Immediately on top of it could be a meta-data engine that allows market-specific parameters to be attached to the requests that refine them (e.g., location, car size, etc). Developers could then leverage this to provide vertically oriented apps for different types of end users (UberX, UberBlack, UberPool, et) that filter the bids/asks based on that specific market's needs. You could also add in some basic rules at that level as well (since markets only exist in terms of the rules that set them up).
This would also open up the possibility of developing completely new markets. Want a local chef who can come over and cook dinner for 4 kids? We can make a market for that! Want someone to paint your house? Market!
It'd make for a really interesting experiment, if nothing else....
"On the other hand, what system would you propose to better reward drivers for working at high-demand times?"
If we want to stick with Uber's claims about simply being an app that enables a market, there's an easy solution. But first we have to be honest about one of Uber's core claims: Uber is not engaging in any form of free market capitalism. Uber sets the rates consumers pay and drivers receive. Their is no market driven supply and demand in Uber's model. Sure, they can say "but... algorithms" and confuse people into thinking this is a pure form of free market capitalism. In reality, it's just an authoritarian scheme controlled by a few people at the top. Hell, they use their massive VC warchest to rewrite regulations in their favor - you know, manipulate the market.
For Uber to really to do market driven ride-sharing, they would simply provide a bid/ask platform for riders and drivers. Riders could post what they're currently willing to pay per mile/minute/what-ever-metric-makes-sense, drivers could post what they're currently willing to work for. Transparency on both sides as to price and other factors (e.g., location, number in party, etc) would allow each to adjust their rates according to current market conditions. That's how a free market for ride-sharing would actually work and provide a natural (invisible?) method to reward/incentivize drivers during surge times.
ISPs would go for it if Google is paying for the FI traffic. Remember, not too long ago telephone service was the cash cow for most of the big ISPs (anyone with an investment in last mile and network wires). Moving phone traffic to Fi gives them back that stream and chips away at the wireless carriers' current dominance of voice and mobile data traffic.
Google could buy bull bandwidth and put Fi connectivity into their routers. ISPs wouldn't count Fi traffic against their customers.
Ok Batman, prove it. Using real programming languages, not toy academic ones. Particularly, prove for any program written in C, which according to other posts on this thread is the language that was used. Make sure your proof works for heavily macroed C programs with upwards of 2M lines of code developed by thousands of people over the last 30 or so years (again, see other posts for the details). Make sure any checker developed using your method completes its analysis before the heat death of the universe, too.
Then, just for completeness, prove it for all programs in the other languages I mentioned. You know, the languages people actually write software in.
And don't forget that external inputs are allowed (those pesky side effects). We're tracking airplanes here. If nothing else, a stream of inputs must be supported by your proof.
It annoys me that people like you make comments like that with nothing to back them up.
You can have poor memory management in any language.
Sure, historically C/C++ have had the been known for memory leaks due to memory that's not freed, but in Java/Python/pick-your-favorite-garbage-collected-language or using smart pointers in C++, all you need to do is have a container that keeps a reference to everything and nothing will go away. It's not hard to do this.
Based on the summary, it sounds like that's what happened. Some monitor views just kept a list of everything and the developer forgot to purge the lists when things went out of, er, scope.
This notion that human drivers aren't that good needs to die. How many rides occur each day? How many pedestrians are hit? Yeah, a lot and very few. Computers have a very high bar to reach just to be on par with humans.
Require more affordable parking in downtown areas.
Seriously, I live in Austin and work downtown. Most days I bike to work. The days I do drive, I spend 20 minutes circling looking for a spot that won't cost me $15. Street parking is $1/hr. Lots are typically $10-12. Garages (the most convenient) are always $15-20. They're also never full.
Cities should require all buildings have enough parking and set the rates to "reasonable" rather than "extortionate".
First off, most of us really aren't waiting for autonomous cars. Just saying it to grab headlines doesn't make it true. I bike mostly and enjoy driving when I do. I get motion sick when someone else is driving. I could care less about a driverless car.
Second, there's no evidence _at all_ that driverless cars will lead to fewer deaths. It's just pure speculation at this point based on the notion that computers will reduce the number of errors that lead to deaths. There's also just as good a chance that driverless cars will introduce a whole new set of ways that people get killed by cars.
Finally, despite all the hype and small wins by Google, if you actually think through all the technology that still needs to be developed before this is practical, we're not going to see it anytime soon. Sure, Google has some cool tech demos and Uber's convincing scientists to leave stable jobs for high flying startup jobs, but that's just a sign of research, not development. Billions are spent on research programs that are just a "few years away" from practical application. Driverless cars are likely in this category.
Now, what will be cool for consumers and insurance companies is when some of these technologies trickle into ordinary cars. Semi-autonomous driving on highways would be great and is probably only a few years away. Better accident avoidance in cities is also likely to emerge from this. This is the benefit of these billion dollar research programs: while they rarely deliver what's being promised, some really good things do come out of them.
While I agree with most commenters that you need to supply many more details before even beginning to narrow the options, if you do look at the storage vendors, DDN (Data Direct Networks) is really hard to beat.
I see the EMC Isilon guys posting here and need to counter.:) They are overpriced and underpowered for almost every application. Their strength is typical enterprise environments - lots of small files accessed via NFS and "enterprise" SLAs. That's almost always the wrong solution for big data applications (NFS is terrible for big data). EMC Isilon sold a lot of storage into my space (gene sequencing) and very few customers are happy, especially when they find out what the other vendors could do.
I've organized bake-offs between DDN, Isilon, and a number of other vendors. DDN always came out ahead on price and performance (every time they were half the price and twice the speed as Isilon). DDN is the most represented of the vendors on the Top 500 Supercomputing list and also power a certain streaming movie/TV service we all know and love. DDN is also a pretty ethical - if they're a bad match for your application, they'll let you know and provide recommendations.
Whatever you do, don't build it yourself. As tempting and fun as it is, given that you're asking the question, you've already self-identified as someone who won't be able to support it. I've seen many smart people go the SuperMicro JBOD route only to create support nightmares for themselves.
Also, for that much space, avoid Amazon at all costs. It's way too expensive compared to dedicated hardware.
For cost, budget around $150-250k to get started. It might seem pricey, but you'll spend more than that on manpower building it yourself (or your first few months on Amazon).
In addition to DDN, IBM, Dell, and HP all have solutions in this range that aren't terribly expensive.
Agreed. As a climber (haven't done El Cap yet, but have done some long Valley climbs), this is pretty lame. The distance between the images is way too far. I want a real, seamless view that I can follow up a route and see all the details. I want to be able to look at the rock, turn the camera and see all around. Look up, look down, find the next hold, see where my feet would be. You know, all the stuff that makes climbing fun.
Trip reports on Supertopo (www.supertopo.com) are way better than this if you want to get a feel for what it's like to climb a long route.
Python is written in C. Linux is written in C. OS X is written in C (with libraries in Objective C). Most low level software is written in C, not C++. It's very important for this exercise to differentiate C from C++. They are not the same language and haven't been since C++ stopped being implemented using macros and the preprocessor and got its first compiler.
C is a much simpler language to learn and maintain, especially if you're doing low level code. C++ has a lot of very nice features, but it's benefits really only come into play if you're willing to put the time and effort into properly learning generic programming (the foundation Boost and the STL).
But, as most people have already pointed out, starting with Python and then migrating portions over to C or C++ as needed for performance is a much better approach. You can manage IO just as effectively from Python as you can from C or C++ and your development time will be much much shorter.
And the author hasn't looked at a relation database in the last few years, either. PostgreSQL, Oracle, MySQL, and I'm sure the other big ones all have JSON (or similar) column types now that let you attach semi-structured elements to your records. You get all the benefits of a RDBMs (ACID, referential integrity, 40 years of history) _and_ all the benefits of NoSQL.
Seriously, there's no good reason not to start with PostgreSQL and only add MongoDB if you really have a good use case for it (you know, you suddenly need to be Web Scale). Personally (and professionally), I use both, with PostgreSQL as the main DB for everything and MongoDB for read-only collections of indexed data.
My challenge to devs out there: spend the hour it takes to learn SQL and understand what you can actually do with it. And, stop pretending that an RDBMS won't scale to meet your needs (spoiler alert: it will).
Huh? Can you back that up with some evidence? I'm not in the super wealthy class, but do know some of them. They all let their kids use smartphones and tablets. Just as I let my kids use them and so do all my friends. Sure, there are the occasional families that don't allow access or restrict access, but those are few and far between - much like the families without TVs when I was growing up in the 80s.
Your first job could be the best job you'll ever have and it could be your last job. But, it could also be the worst job you'll have.
Be honest with yourself. If it's not working, don't be afraid to move on. It's not worth being miserable when you're just starting your career. Don't quit impulsively, but if things don't feel right, ask some older friends if what you're experiencing is normal or not. You don't have the experience yet to know better, but your elders do.
My first job was as a software engineer at a site everyone over 30 has used (it's still around, but not as popular). It was the early days of the internet. At my 6 month review, I got "dinged" for going home one morning at 3 am when everyone else stayed through the night. This was after two weeks of 18 hour days. I was doing more harm than good coding at that point. I was being paid $33k/yr and had no stock options. I was told everyone had to do this to keep up with "Internet Time". Over the next few weeks, most of the senior developers (back when senior developers were actually senior with 10+ years' experience) quit en masse. It took me a few more months to realize that this was not normal and leave as well. I would have been much better off walking after the first month.
Most CS professors are paid market value. You can look up salaries at public schools. You'll find that at the ones that compete with CMU, the salaries are all in the range of what the researchers would make at a company ($100-250k). Bonuses are a little harder to compete with. But, in CS at least, grants cover a ton of travel. To publish in CS, you have to go to the conferences you're publishing in, unlike the rest of science which just has journals. That more than makes up for the lack of bonuses as far as fringe benefits go.
Now, the one benefit you get from industry is that you don't have to write grants. But, you also have more job security in academia. What worries me most about this is that when this bubble bursts, Uber will be one of the first companies to go (at least, research at Uber will go quickly). These researchers will now be stuck without jobs in a market that will be very hostile towards PhDs. For their sake, I hope they all vest quickly enough to get a nest egg before things go south. (it's going to happen, it always does)
In Lousiville, CO, I lived in one of the few neighborhoods that was skipped over for broadband in 1999. Sprint setup a microwave service that filled in the gap. Bandwidth was awesome - I was getting 10-30 MBs regularly. The downside was the latency - 100 ms ping times were the norm. I remember trying to play Duke Nuke 'Em with friends and having the unfair "advantage" of disappearing regularly when my client didn't ping back in time. Being line-of-site, there were also issues with trees occasionally swaying in front of the dish (a pizza box attached to my roof) and snow blocking the signal.
As others have pointed out, microwave Internet isn't something new and, unfortunately, in the real world isn't a perfect solution.
Slashdot Mirror
I have two cars: a '96 Jeep Cherokee and an '01 M Coupe. You know what I love about both of them? The climate control system is analog. I user a slider or knob, feel the resistance, and know the temperature will adjust. The radios are simple: a few preset (physical) buttons, a volume knob, and a tuner knob. Sure, bluetooth would be nice, but I have a cigarette lighter dongle that works just fine over FM for streaming music and taking calls (I actually still have the cigarette lighters for both cars, too).
My wife, OTOH, has had a stream of cars with electronic climate control, complex infotainment systems, and all sorts of other bells and whistles. You know why we got rid of the last one? The climate control system kept thinking it was 20F outside and adjusted the heat accordingly. This in the summer in Texas. The automaker, despite repeated visits every summer, couldn't resolve the issue.
Oh, and navigation? For the few times I don't know where I'm going (really, it's scary how people rely on nav systems for drives they do every day), a quick glance at Google maps on my phone orients me (usually before I get in the car).
I'll allow some local microprocessor control for drivability and performance, but when it comes to the creature comforts and extras, I want them simple and functional. I want my car to talk to me through the engine, not the speakers.
-Chris
You don't need to be under 350 feet for remote sensing apps. In fact, you get better coverage from higher up. That industry is safe.
-Chris
Milk and meat are around the periphery because their display cases are connected to (or close to) the bulk cold storage in the stores. It's part of preserving the "cold chain" of ensuring that products that need constant refrigeration throughout the supply chain actually get constant refrigeration.
Most of the marketing text written about grocery store layouts was developed after the layouts were already in use. Most of the layout quirks are the way they are for more practical and mundane reasons. Layout as a conspiracy makes a great story, but in general, it's just that. Yes, impulse aisles are exceptions as are some other elements in the store, but for the most part, the practicalities of storing and presenting large amounts of food determine the layout.
-Chris
One thing that gets me in discussions across organizations is how poorly the "cloud" is defined. IT often has a slightly different definition of the cloud than senior management than end users than tech support (and so on). Are we moving email to the cloud, setting up a collection of virtual servers to run our custom apps on, using Salesforce, creating a hybrid solution for redundancy? Even in those situations, the motivations and concerns are often different.
Then there's the accounting aspect. Is the shift simply to move IT from CapEx to OpEx? Does the IT staff understand the difference? Has management worked out a 3 year forecast to make sure the financials actually work out?
When making these decisions, all major stakeholders need to be involved and represented. You need to look at it from different perspectives and make sure everyone understands those perspectives. Only then can you really make an informed decision. Yes, that's much more difficult than simply believing the sales guy, but for something as important as IT infrastructure, it's what you should do.
I work on the laboratory informatics/gene sequencing side of the world and these conversations are becoming more common. To help give scientists some perspective, I've putting together some blog posts that introduce all the different angles:
https://www.lab7.io/is-your-he...
Yes, it's a bit of shameless self-promotion, but it's also relevant to the discussion (and I don't want to just cut-and-paste it here :) ).
-Chris
Taking it a step further, the core platform could be a general "market" engine that simply provides a method for posting bids and asks. Immediately on top of it could be a meta-data engine that allows market-specific parameters to be attached to the requests that refine them (e.g., location, car size, etc). Developers could then leverage this to provide vertically oriented apps for different types of end users (UberX, UberBlack, UberPool, et) that filter the bids/asks based on that specific market's needs. You could also add in some basic rules at that level as well (since markets only exist in terms of the rules that set them up).
This would also open up the possibility of developing completely new markets. Want a local chef who can come over and cook dinner for 4 kids? We can make a market for that! Want someone to paint your house? Market!
It'd make for a really interesting experiment, if nothing else....
-Chris
"On the other hand, what system would you propose to better reward drivers for working at high-demand times?"
If we want to stick with Uber's claims about simply being an app that enables a market, there's an easy solution. But first we have to be honest about one of Uber's core claims: Uber is not engaging in any form of free market capitalism. Uber sets the rates consumers pay and drivers receive. Their is no market driven supply and demand in Uber's model. Sure, they can say "but... algorithms" and confuse people into thinking this is a pure form of free market capitalism. In reality, it's just an authoritarian scheme controlled by a few people at the top. Hell, they use their massive VC warchest to rewrite regulations in their favor - you know, manipulate the market.
For Uber to really to do market driven ride-sharing, they would simply provide a bid/ask platform for riders and drivers. Riders could post what they're currently willing to pay per mile/minute/what-ever-metric-makes-sense, drivers could post what they're currently willing to work for. Transparency on both sides as to price and other factors (e.g., location, number in party, etc) would allow each to adjust their rates according to current market conditions. That's how a free market for ride-sharing would actually work and provide a natural (invisible?) method to reward/incentivize drivers during surge times.
-Chris
ISPs would go for it if Google is paying for the FI traffic. Remember, not too long ago telephone service was the cash cow for most of the big ISPs (anyone with an investment in last mile and network wires). Moving phone traffic to Fi gives them back that stream and chips away at the wireless carriers' current dominance of voice and mobile data traffic.
Google could buy bull bandwidth and put Fi connectivity into their routers. ISPs wouldn't count Fi traffic against their customers.
-Chris
That's more likely what they're doing. Seeing how far they can expand the Fi network.
Ok Batman, prove it. Using real programming languages, not toy academic ones. Particularly, prove for any program written in C, which according to other posts on this thread is the language that was used. Make sure your proof works for heavily macroed C programs with upwards of 2M lines of code developed by thousands of people over the last 30 or so years (again, see other posts for the details). Make sure any checker developed using your method completes its analysis before the heat death of the universe, too.
Then, just for completeness, prove it for all programs in the other languages I mentioned. You know, the languages people actually write software in.
And don't forget that external inputs are allowed (those pesky side effects). We're tracking airplanes here. If nothing else, a stream of inputs must be supported by your proof.
It annoys me that people like you make comments like that with nothing to back them up.
You can have poor memory management in any language.
Sure, historically C/C++ have had the been known for memory leaks due to memory that's not freed, but in Java/Python/pick-your-favorite-garbage-collected-language or using smart pointers in C++, all you need to do is have a container that keeps a reference to everything and nothing will go away. It's not hard to do this.
Based on the summary, it sounds like that's what happened. Some monitor views just kept a list of everything and the developer forgot to purge the lists when things went out of, er, scope.
-Chris
This notion that human drivers aren't that good needs to die. How many rides occur each day? How many pedestrians are hit? Yeah, a lot and very few. Computers have a very high bar to reach just to be on par with humans.
-Chris
Require more affordable parking in downtown areas.
Seriously, I live in Austin and work downtown. Most days I bike to work. The days I do drive, I spend 20 minutes circling looking for a spot that won't cost me $15. Street parking is $1/hr. Lots are typically $10-12. Garages (the most convenient) are always $15-20. They're also never full.
Cities should require all buildings have enough parking and set the rates to "reasonable" rather than "extortionate".
-Chris
First off, most of us really aren't waiting for autonomous cars. Just saying it to grab headlines doesn't make it true. I bike mostly and enjoy driving when I do. I get motion sick when someone else is driving. I could care less about a driverless car.
Second, there's no evidence _at all_ that driverless cars will lead to fewer deaths. It's just pure speculation at this point based on the notion that computers will reduce the number of errors that lead to deaths. There's also just as good a chance that driverless cars will introduce a whole new set of ways that people get killed by cars.
Finally, despite all the hype and small wins by Google, if you actually think through all the technology that still needs to be developed before this is practical, we're not going to see it anytime soon. Sure, Google has some cool tech demos and Uber's convincing scientists to leave stable jobs for high flying startup jobs, but that's just a sign of research, not development. Billions are spent on research programs that are just a "few years away" from practical application. Driverless cars are likely in this category.
Now, what will be cool for consumers and insurance companies is when some of these technologies trickle into ordinary cars. Semi-autonomous driving on highways would be great and is probably only a few years away. Better accident avoidance in cities is also likely to emerge from this. This is the benefit of these billion dollar research programs: while they rarely deliver what's being promised, some really good things do come out of them.
-Chris
While I agree with most commenters that you need to supply many more details before even beginning to narrow the options, if you do look at the storage vendors, DDN (Data Direct Networks) is really hard to beat.
I see the EMC Isilon guys posting here and need to counter. :) They are overpriced and underpowered for almost every application. Their strength is typical enterprise environments - lots of small files accessed via NFS and "enterprise" SLAs. That's almost always the wrong solution for big data applications (NFS is terrible for big data). EMC Isilon sold a lot of storage into my space (gene sequencing) and very few customers are happy, especially when they find out what the other vendors could do.
I've organized bake-offs between DDN, Isilon, and a number of other vendors. DDN always came out ahead on price and performance (every time they were half the price and twice the speed as Isilon). DDN is the most represented of the vendors on the Top 500 Supercomputing list and also power a certain streaming movie/TV service we all know and love. DDN is also a pretty ethical - if they're a bad match for your application, they'll let you know and provide recommendations.
Whatever you do, don't build it yourself. As tempting and fun as it is, given that you're asking the question, you've already self-identified as someone who won't be able to support it. I've seen many smart people go the SuperMicro JBOD route only to create support nightmares for themselves.
Also, for that much space, avoid Amazon at all costs. It's way too expensive compared to dedicated hardware.
For cost, budget around $150-250k to get started. It might seem pricey, but you'll spend more than that on manpower building it yourself (or your first few months on Amazon).
In addition to DDN, IBM, Dell, and HP all have solutions in this range that aren't terribly expensive.
-Chris
That already exists. It's called SELinux: https://en.wikipedia.org/wiki/...
-Chris
Mod parent up. TA (done by the same people as Supcom) was the Ur-game in this genre. Still one of the best games of all time, IMHO.
Agreed. As a climber (haven't done El Cap yet, but have done some long Valley climbs), this is pretty lame. The distance between the images is way too far. I want a real, seamless view that I can follow up a route and see all the details. I want to be able to look at the rock, turn the camera and see all around. Look up, look down, find the next hold, see where my feet would be. You know, all the stuff that makes climbing fun.
Trip reports on Supertopo (www.supertopo.com) are way better than this if you want to get a feel for what it's like to climb a long route.
-Chris
Python is written in C. Linux is written in C. OS X is written in C (with libraries in Objective C). Most low level software is written in C, not C++. It's very important for this exercise to differentiate C from C++. They are not the same language and haven't been since C++ stopped being implemented using macros and the preprocessor and got its first compiler.
C is a much simpler language to learn and maintain, especially if you're doing low level code. C++ has a lot of very nice features, but it's benefits really only come into play if you're willing to put the time and effort into properly learning generic programming (the foundation Boost and the STL).
But, as most people have already pointed out, starting with Python and then migrating portions over to C or C++ as needed for performance is a much better approach. You can manage IO just as effectively from Python as you can from C or C++ and your development time will be much much shorter.
-Chris
And the author hasn't looked at a relation database in the last few years, either. PostgreSQL, Oracle, MySQL, and I'm sure the other big ones all have JSON (or similar) column types now that let you attach semi-structured elements to your records. You get all the benefits of a RDBMs (ACID, referential integrity, 40 years of history) _and_ all the benefits of NoSQL.
Seriously, there's no good reason not to start with PostgreSQL and only add MongoDB if you really have a good use case for it (you know, you suddenly need to be Web Scale). Personally (and professionally), I use both, with PostgreSQL as the main DB for everything and MongoDB for read-only collections of indexed data.
My challenge to devs out there: spend the hour it takes to learn SQL and understand what you can actually do with it. And, stop pretending that an RDBMS won't scale to meet your needs (spoiler alert: it will).
-Chris
Huh? Can you back that up with some evidence? I'm not in the super wealthy class, but do know some of them. They all let their kids use smartphones and tablets. Just as I let my kids use them and so do all my friends. Sure, there are the occasional families that don't allow access or restrict access, but those are few and far between - much like the families without TVs when I was growing up in the 80s.
Yahoo rebranded MapQuest early on and then switches to a different provider before bringing maps in house 8 years ago.
-Chris
Your first job could be the best job you'll ever have and it could be your last job. But, it could also be the worst job you'll have.
Be honest with yourself. If it's not working, don't be afraid to move on. It's not worth being miserable when you're just starting your career. Don't quit impulsively, but if things don't feel right, ask some older friends if what you're experiencing is normal or not. You don't have the experience yet to know better, but your elders do.
My first job was as a software engineer at a site everyone over 30 has used (it's still around, but not as popular). It was the early days of the internet. At my 6 month review, I got "dinged" for going home one morning at 3 am when everyone else stayed through the night. This was after two weeks of 18 hour days. I was doing more harm than good coding at that point. I was being paid $33k/yr and had no stock options. I was told everyone had to do this to keep up with "Internet Time". Over the next few weeks, most of the senior developers (back when senior developers were actually senior with 10+ years' experience) quit en masse. It took me a few more months to realize that this was not normal and leave as well. I would have been much better off walking after the first month.
-Chris
Most CS professors are paid market value. You can look up salaries at public schools. You'll find that at the ones that compete with CMU, the salaries are all in the range of what the researchers would make at a company ($100-250k). Bonuses are a little harder to compete with. But, in CS at least, grants cover a ton of travel. To publish in CS, you have to go to the conferences you're publishing in, unlike the rest of science which just has journals. That more than makes up for the lack of bonuses as far as fringe benefits go.
Now, the one benefit you get from industry is that you don't have to write grants. But, you also have more job security in academia. What worries me most about this is that when this bubble bursts, Uber will be one of the first companies to go (at least, research at Uber will go quickly). These researchers will now be stuck without jobs in a market that will be very hostile towards PhDs. For their sake, I hope they all vest quickly enough to get a nest egg before things go south. (it's going to happen, it always does)
-Chris
Well, for the rock climbers and mountaineers in the audience, this is a pretty spectacular picture. It's fun to trace routes up the mountain.
Now they need to do the Eiger and update the El Cap gigaphoto.
-Chris
In Lousiville, CO, I lived in one of the few neighborhoods that was skipped over for broadband in 1999. Sprint setup a microwave service that filled in the gap. Bandwidth was awesome - I was getting 10-30 MBs regularly. The downside was the latency - 100 ms ping times were the norm. I remember trying to play Duke Nuke 'Em with friends and having the unfair "advantage" of disappearing regularly when my client didn't ping back in time. Being line-of-site, there were also issues with trees occasionally swaying in front of the dish (a pizza box attached to my roof) and snow blocking the signal.
As others have pointed out, microwave Internet isn't something new and, unfortunately, in the real world isn't a perfect solution.
-Chris