Lives in Bay Area and saves 200k in 6 years at 95k year? highly doubtful.
Depends. If you're in an apartment and you aren't sharing it with somebody else, then no way. If you own a mobile home free and clear (no mortgage), then it is probably doable.
$95k means probably in the neighborhood of $57k after taxes by my quick hackish math. Subtract $33k per year in savings, and that leaves $24k for living expenses. Half that will go to rent and utilities. That leaves $12k for incidentals like food, gasoline, and Internet service. If you spend $1,000 per month on incidentals, you're doing something wrong..
As far as I can tell, the biggest advantage of a desktop OS over a tablet is the ability to have multiple monitors filled with dozens of windows. I can't even begin to imagine the hell that OS X would become if, for example, Terminal.app forced all of its windows into tabs, or even used tabs by default. Imagine doing all your work in a single terminal window running screen and you're roughly in the ballpark. If you've ever done this, you know what a nightmare it is, and not just because of the control-A behavior. The cognitive load induced by hiding the state of other windows is considerable.
So I just want to make sure that it is as easy to disable the tabs feature systemwide as it is to disable the unnatural scroll direction feature. Not only do I not want tabs to be created automatically, I don't want them to be created at all. I don't want to accidentally release the mouse at the wrong time while dragging a window around and have two of my windows suddenly become a single window with tabs.
Frankly, I don't like tabs even in a web browser, much less in any app that I use to actually get work done. Tabs mean having to manage a nested hierarchy of content state. Not only do I have to remember which browser window something is in, but also which tab. And to get to it, I have to remember three different keyboard navigation shortcuts—one to choose the app, one to choose the window, and a third one to choose the tab. And the headache gets even worse when you start minimizing windows into the dock, because the dock shows you only the frontmost tab. When you go to find something later, tabs make serious computer use an absolute nightmare.
So yeah, that feature is fine for your non-power-user who is scared by having to see more than one window at a time, but it absolutely must be possible for users to kill it with fire as soon as they realize that it is hindering their workflow... because it invariably will for some people.
Fun fact: All the big players use short-lived certificates.
Fun fact: All the big players use short-lived servers. They deploy things to cloud servers frequently, un-deploy them frequently, and they run their own CAs. That's great if you're a giant cloud provider. After all, if one of those servers fails to come up because of a re-cert, the server transparently fails over to another server, and as long as the configuration doesn't propagate too far, there's no impact on anything.
That's completely different from the types of users who are in the market for a free certificate provider. Those folks usually have only a single server that has to "just work". Every extra bit of automation adds risk. Every configuration change is a risk. That risk is much higher because their services are not massively distributed. For them, limiting the rate of change is more important than the infinitesimal risk of someone compromising their server, stealing their key, and using it to impersonate their hobby server.
So no, 90 days is not a better choice. It is just a choice. You're trading higher risk of something going wrong during re-certing against a shorter period of vulnerability for clients that don't support OCSP and are actively being attacked by someone who successfully compromised your server at some point in the recent past, up until the end of that cert's validity window. IMO, the decision of certificate length should be entirely in the hands of the site admins, not forced upon them by a heavy-handed certificate authority.
Once upon a time the "certs that people pay for" lasted up to 10 years. That stopped. Can you guess why? You're probably thinking "So they could charge a lot more money" right? Nope. Because hardly any of those 10 year certificates remained in use after just FIVE years.
That's in large part because most companies don't keep servers running that long. Heck, a statistical majority of companies aren't around that long. This is not the case for personal servers, of course, but they were historically never secured with HTTPS because of the cost. That critical difference makes any statistics from that period wholly invalid when determining proper lengths for certs in this day and age.
Also, folks periodically find weaknesses in crypto technology that requires you to rekey your servers. For this reason, periods should be long enough to not be annoying, but short enough that people have to manually intervene every two or three years, to ensure that sysadmins realize that their keys are no longer strong enough and upgrade things accordingly. IMO, automated upgrades actively hinder security by making the process "out of sight, out of mind". Whether that difference matters or not remains to be seen, but it is at least cause for concern.
And my point is that it isn't their place to discourage sysadmins from monitoring their server cert upgrades. It's fine for them to encourage the various web servers to make the automatic upgrades easy so that people with no experience have an easier time, but it is crossing a line to insist that we shouldn't be allowed to be cautious.
In fact they've tried to make it easier. Most people just want to get the job done, nothing more. The "layer" of crap removes one big problem with SSL certificates: manual renewal. Usually you have to renew certificates manually, but with the program from Let's Encrypt, this happens automatically.
That's downright terrifying to me. I've had at least a few situations where a seemingly innocuous cert upgrade went horribly wrong and I had to roll back to a previous configuration to get back up and running. The last thing I want is for that process to be fully automated. There's a reason I don't automate my TLS cert upgrades, and it isn't because it isn't easy to do. It is because if anything goes wrong, I want to be abso-freaking-lutely sure that I'm right there beside the machine when it fails so that I can fix the problem quickly.
SSL Certs are good for 90 days. You get emails telling you when your certs are about to expire so you can renew them if needed.
Yikes. Ninety days? Having such a short expiration period weakens security in at least a couple of ways:
No sane person is going to be willing to babysit a cert upgrade four times a year. I've seriously considered paying hundreds of dollars for certs instead of using free certs because once per year is annoying as h***, much less four times. Therefore, everyone will store their Let's Encrypt creds on the servers themselves, making them a juicier target than they otherwise would be, because crackers can swipe those creds and create certs in the site owner's name (for other arbitrary sites).
If certs are automatically regenerated, site owners will stop thinking about the cert creation process, and thus won't periodically upgrade their keys as new weaknesses are found (unless forced to do so).
In short, what the f*** were they thinking?
I've read their statement on the subject, which claims that 90-day certs are the most common length on the web. That's true, but only because there are a whole lot of companies who give away free certs, but limit the duration to 90 days in the hopes that it will drive people to pay money for longer certs. The reality is that 100% of the certs that people pay for are a year or longer. And for that matter, I can get free 1-year certs from StartSSL, so why in the world does anybody even use those? I don't get it....
And there's also one huge problem with that scheme, which is the use of shared servers. If you're using a shared hosting provider and fifty people upgrade their SSL certs once a year, you have 50 server restarts per year for a total of probably three or four hours of downtime. If they upgrade their certs more than four times per year, that's almost a day of downtime annually, unless the ISP forcibly upgrades everybody's certs all at once, but that would mean giving your ISP the credentials to log in for you, which represents an even bigger security risk.
So even if I didn't have this latest security incident as a reason, I still wouldn't touch Let's Encrypt with a ten-meter pole....
The bigger problem, IMO, is that Apple has stopped providing any incentive to return nonfunctional devices for recycling. For example, I have an iPhone 5 with a dead power button. According to Apple, its value is zero, even though it is perfectly usable with a dead power button. You just can't reboot it without having a power supply to turn it back on. That phone is worth hundreds of dollars in repair parts, because the case is perfect, the screen is perfect, and I replaced the battery just a few months ago. Or they could fix the power button (requires soldering, unfortunately) and give it to somebody as a refurb. Despite this, Apple won't pay me a cent for it because of that one minor issue.
IMO, Apple's claims of trying to reduce e-waste are basically a sham. If there's no incentive to return a product for recycling, it is likely to sit on a shelf gathering dust, or worse, go into a garbage can, when it could just as easily be used to make repair parts more readily available and thus reduce the need for such extortionate repair part prices. Until Apple gets serious and starts giving reasonable gift cards in exchange for your dead phones, I will still consider e-waste to be a real problem, and I'll still consider their exorbitant parts costs to be a big part of that problem.
Math is used everywhere. Networking summarization across 70 sites cross correlated with attacks, and limited to particular lists, and threats.
I've never heard the term "network summarization", so I assume you mean "route summarization". Unless I'm misunderstanding you, that's IT stuff, which is usually considered part of CIS, not CS. But even if we broaden the definition of CS to include CIS, the math that you're talking about is trivial, and there are almost certainly tools that will do most of the work for you, which means that the limit of the math understanding required should be looking at a pile of numbers and saying, "Hey, those look kind of similar". If that isn't the case, don't worry, it will be true soon enough. There's no reason for IT people to do such work by hand. After all, computers are really good at simple binary math....
That's not done with a library. Programming is not Computer Science. It is but only a part, and for those who would argue, I would ask that you set your hubris and bias aside, and then answer.
I'm not arguing that programming is all of CS. I'm arguing that fundamentally, the purpose of CS is to make you a better programmer, and that unless you plan to work in academia for the rest of your life, anything that doesn't do so should be considered optional, for your enjoyment, rather than a core requirement. And I'm arguing that math falls into that category of things that are only critical to a tiny fraction of programmers, which means it should be purely elective, and taken by people who enjoy doing math, rather than being seen as some critical foundation that every programmer must have.
Well, one big difference between these sorts of designs and helicopters is that the blades are bounded. You're not worrying about rotors touching because other stuff will hit first. That's subtle, but critical at ensuring safety.
Another big difference is that presumably a computer would be controlling the blades to ensure level flight, and the vehicle would be in a fly-by-wire mode where the user controls altitude, forward velocity, and turning. Presumably the vehicles would, then, be absolutely level, even when turning.
But yeah, you're probably right about that buying you only one layer. I don't think even computers can compensate for turbulence quickly enough to deal with multiple layers at 15 foot separation.:-)
BTW, there are ways for quadcopters to continue flying after a rotor failure. It requires computers to control the speed of the rotors, but that goes without saying anyway. So they're potentially even safer than a single-blade design, but only if you have the right computer control system.
Calculus is important, but not because most people are going to have to calculate a bunch of integrals, but learning calculus trains your mind and teaches you to think analytically. The same is true for statistics and other higher level maths.
You can strengthen your muscles with steroids. That doesn't mean that body building requires steroids.
The fact that math can strengthen your brain does not make it a fundamental requirement for computer science. It is just one of a nearly infinite number of possible paths to such brain development. Besides, by the time most people take calculus, those parts of their brains are mostly formed....
That makes me sad.... Every programmer really ought to at least have a high-level understanding of those subjects. They probably won't use it much, but their eyes shouldn't glaze over.:-) That doesn't mean they really need to be able to be able to design caching hardware that minimizes synchronization issues or know how to design caching algorithms to improve the cache hit rate, but they need to recognize the sorts of programming designs that can lead to poor cache performance, like iterating an array in the wrong major order for their particular language....
Let me rephrase that. Probably 99% of people doing work in those fields do not have to use math directly. You can do some amazing 3D modeling and rendering without fully understanding how the computer does interpolation of spline models under the hood. You can compute netmasks using a JavaScript calculator. You'll never have to do network path optimization or other such math unless you're writing kernel code or designing some replacement for TCP/IP, which is maybe 1/1000th of one percent of networking people. And so on.
CS is dozens of unrelated fields that each build specialized knowledge on top of computer programming. Accounting, by contrast, is basically just one huge body of knowledge built atop a tiny subset of mathematics. The two statements are not really equivalent.
Most of the CS disciplines do not require large amounts of mathematics unless you're doing research, and even then, most of the work is not the math. That's just the final data analysis step, and you can easily grab a math major to do that. Really, only a tiny fraction of the work even in the most research-heavy CS fields involves math, which means it is absolutely not necessary for everybody to be highly skilled in those areas. It doesn't hurt, mind you, but IMO, it usually isn't nearly as useful as having a better understanding of how the computer actually works.
Knowing math sure comes in handy when you want your video game to have things like physics or graphics or interaction.
I'm not sure which part of that to comment on first—the tiny percentage of software engineers who write games or the ridiculous number of hours their employers tend to expect them to work—so instead I'll say, "Just keep telling yourself that when you reach thirty and realize that you hate your job."
Besides, even in game design, not everybody is designing the physics engine. You need other people to create models, design skins, design the overall game mechanics, write the in-game chat client, write level downloaders, etc.
Unless you want to spend your life doing academic research, if you're learning CS, you're learning it with the intent to use it writing software. So in practical terms, yes, computer science and programming are basically the same thing the moment you step off that platform with your degree in hand.
With that said, computer science includes a number of related fields. Programming is just one aspect of CS as a whole. Many of the others fields use even less math, and a few of them use more. For example:
Computational complexity involves math, but it barely even resembles traditional math.
Design methodologies (OO versus procedural versus data flow versus...) has minimal math.
Software engineering methodologies (waterfall versus scrum versus....) has minimal math (though you might want to know statistics).
Computer graphics may or may not involve lots of math, depending on what layer you're working at.
Computer security has very little math, with the exception of the crypto subspecialty, which is math-heavy.
Networking has very little math unless you're working in certain subspecialties such as routing, where you might need to know graph theory.
The idea that the old style was bad because it required "deep math skills" is wrong headed. Computer science *requires* deep math skills; computer science is a branch of mathematics essentially. The writer wants us to focus on logic, but logic is mathematics!
You're both wrong. I started writing software before I knew what multiplication meant. Computer science, with the sole exception of the statistics-heavy research that you do at grad school level, doesn't require even the most basic math skills. They're completely and totally orthogonal. The fact that the computer is doing lots of math under the hood doesn't mean the programmer needs to know or care. In fact, the fallacious belief that CS uses lots of math and thus must be hard is the primary reason that so few people take an interest in CS, even though far more people are capable of understanding CS than, for example, trig.
The reality is that writing software is nothing more than telling computers what to do, then figuring out why your instructions didn't have the desired effect. To write software, you have to be able to understand the syntax, and you have to be able to simultaneously look at small details (e.g. the code in a particular function) while putting them in the context of a larger whole (the program). You have to be able to understand how small changes in one place can have huge effects on the opposite side of the app by being able to visualize data flow from point A to point B. None of these things involve math; it's all spatial relationships and abstract thinking.
Incidentally, the student in your example is right. 99.999% of programmers won't ever need calculus. In seventeen years in the industry, I haven't used calculus even once. The highest math I've dealt with was a bit of matrix math and various transforms (e.g. DCT, FFT) between time domain and frequency domain. And even then, I can count the number of times that I did that on one hand. And not once did I ever have to actually implement the transform, because there are already implementations for such things that you can bring in as libraries. Most of the hard math is already done for you. This does, of course, mean that there must always be a few math nerds involved in writing computer software, because somebody has to create and maintain those libraries, but the vast majority of programmers just need to understand what it does at a very high level.
By contrast, every programmer needs to get good at architecting software properly. Of course, you can somewhat learn that as you go along, so long as you're exposed to good code and can use it as an example (or bad code, and can use it as a cautionary tale).
We're not trying to keep people out by being snobs, instead we're trying to stop the long slow decline of computer science and computing. There are applications of computers that require absolutely top notch people, especially as the uses of computers become more common you want computers to be designed, built, and programmed by very smart people. Do you really want to fly on a plane programmed by someone who skipped college because it was too time consuming?
Now let me turn that around. Do you really want apps on your phone written by people who are used to writing software for the avionics systems on aircraft? Those folks churn out code at a rate that is orders of magnitude too slow. Different types of software require different types of programmers. There will always be a few people who need to do mission-critical, low-level coding. The rest of the software world can then import their framework and design apps to use it, and there's nothing wrong with that.
If we lower the bar and say that we just talking about 9-to-5 programming for a basic salary with no leadership or design expectations, then maybe you don't need any math or engineering or domain knowledge. But that's not aiming high, that's aiming for an entry level job th
Then move to a remote island. In the civilized world, you do not own the public airwaves and your rights do not allow you to not cause interference for others.
You might want to read up on what happens at Oshkosh every year. That's what commuting by air would look like when everyone wants to go to/from the same place. Couple that with electric aircraft with extremely limited flight durations and the tendency of people to not refuel their cars / aircraft with the idea of a contingency situation...
As long as you limit its altitude, lack of refueling isn't necessarily a big problem. Just design it to refuse to fly more than thirty feet above the current road grade, and ensure that it is designed to automatically find a spot to land when it gets below two minutes of charge. The issue of getting a tow is, of course, still a problem, but at least you won't have it falling out of the sky on top of someone.
This sort of design would allow for two (and in some cases, three) layers of traffic instead of one, and would allow detours around wrecks without having to necessarily be precisely above the road surface, which would basically fix everything that's wrong with freeways, but without turning it into a free-for-all and interfering with normal air traffic. There would, of course, be no-fly zones, such as the stretches of 101 and 880 at the ends of the SJC airport runway, but this would also open up the use of 87 as a cutacross, so in a pinch, a lot of folks could avoid problems on the ground layer, reducing the impact of the problem.
So there are two reasons I would consider (emphasize the word 'consider') a subscription model for these apps. First is that I would like that company to be financially successful so they will continue to do significant upgrades. It is my hope that should they want me to retain a subscription they'd hear my voice more distinctly rather than hoping I'll purchase an upgrade. (I may be in fantasy-land, here.)
Yeah, good luck with that. As far as I can tell, there's even less incentive for the company to care about your needs once you're on a subscription model, because the second you stop paying them, you lose access to your files, and they know you won't do that, which means you'll keep paying them just to keep using the software, whether they improve things or not. At least with a normal sale model, they have to do enough upgrades to earn your purchase.
Products that are actively innovating are almost invariably sold, not rented; products on a subscription model are typically largely coasting.
My recollection is that the statute of limitations generally begins either when an event occurs or when it is discovered, but that the latter is generally reserved for situations where the malfeasance is not obvious until discovered. The judge and prosecutor have the same last name, so that doesn't really apply here.
Actually, I think you're all wrong. We reached peak app while back, but it has nothing to do with the apps and everything to do with platform maturity.
What we're seeing right now (or so I've read) is that smartphone sales are tapering off across all platforms. At this point, most of the people who are going to buy a smartphone have already bought one. The few remaining new adopters represent the long tail of late adopters and luddites, plus kids coming of age. Most of the new sales, then, are replacing an existing device, rather than adding a device.
Now, consider that there are only two groups of people who are likely to download a new app: people who are looking for a solution to a problem and people who just got a cell phone and don't have any apps on it yet. To reach the first group, you have to actively promote the app to that target audience. This costs money, so most app developers aren't willing to do it. And even if they attempt it, they usually do so badly, using poorly targeted ad platforms that don't allow you to skip the ad early to indicate disinterest and don't take previous clicks into account when deciding whether the person might or might not be likely to click on the ad.
This leaves the second group—the new users. The problem is, that pool is drying up. Except for platform switchers, the overwhelming majority of people who buy a new smartphone already own one, and that means they already have a collection of apps. Therefore, with the exception of apps that don't get updated and break on new hardware, there's really no impetus to make them download a bunch of new apps.
So for app growth to continue at its previous pace, either marketing must get better (read "more accurately targeted") or a new platform is going to have to come along that is so amazing that it is able to draw a sizable percentage of users away from Android or iOS. Either that or some existing (but noncompeting) platform like tvOS will have to exhibit a lot of rapid growth, and by attracting new adopters there, drag users into installing the same apps on other platforms.
Slashdot Mirror
Depends. If you're in an apartment and you aren't sharing it with somebody else, then no way. If you own a mobile home free and clear (no mortgage), then it is probably doable.
$95k means probably in the neighborhood of $57k after taxes by my quick hackish math. Subtract $33k per year in savings, and that leaves $24k for living expenses. Half that will go to rent and utilities. That leaves $12k for incidentals like food, gasoline, and Internet service. If you spend $1,000 per month on incidentals, you're doing something wrong..
As far as I can tell, the biggest advantage of a desktop OS over a tablet is the ability to have multiple monitors filled with dozens of windows. I can't even begin to imagine the hell that OS X would become if, for example, Terminal.app forced all of its windows into tabs, or even used tabs by default. Imagine doing all your work in a single terminal window running screen and you're roughly in the ballpark. If you've ever done this, you know what a nightmare it is, and not just because of the control-A behavior. The cognitive load induced by hiding the state of other windows is considerable.
So I just want to make sure that it is as easy to disable the tabs feature systemwide as it is to disable the unnatural scroll direction feature. Not only do I not want tabs to be created automatically, I don't want them to be created at all. I don't want to accidentally release the mouse at the wrong time while dragging a window around and have two of my windows suddenly become a single window with tabs.
Frankly, I don't like tabs even in a web browser, much less in any app that I use to actually get work done. Tabs mean having to manage a nested hierarchy of content state. Not only do I have to remember which browser window something is in, but also which tab. And to get to it, I have to remember three different keyboard navigation shortcuts—one to choose the app, one to choose the window, and a third one to choose the tab. And the headache gets even worse when you start minimizing windows into the dock, because the dock shows you only the frontmost tab. When you go to find something later, tabs make serious computer use an absolute nightmare.
So yeah, that feature is fine for your non-power-user who is scared by having to see more than one window at a time, but it absolutely must be possible for users to kill it with fire as soon as they realize that it is hindering their workflow... because it invariably will for some people.
Fun fact: All the big players use short-lived servers. They deploy things to cloud servers frequently, un-deploy them frequently, and they run their own CAs. That's great if you're a giant cloud provider. After all, if one of those servers fails to come up because of a re-cert, the server transparently fails over to another server, and as long as the configuration doesn't propagate too far, there's no impact on anything.
That's completely different from the types of users who are in the market for a free certificate provider. Those folks usually have only a single server that has to "just work". Every extra bit of automation adds risk. Every configuration change is a risk. That risk is much higher because their services are not massively distributed. For them, limiting the rate of change is more important than the infinitesimal risk of someone compromising their server, stealing their key, and using it to impersonate their hobby server.
So no, 90 days is not a better choice. It is just a choice. You're trading higher risk of something going wrong during re-certing against a shorter period of vulnerability for clients that don't support OCSP and are actively being attacked by someone who successfully compromised your server at some point in the recent past, up until the end of that cert's validity window. IMO, the decision of certificate length should be entirely in the hands of the site admins, not forced upon them by a heavy-handed certificate authority.
That's in large part because most companies don't keep servers running that long. Heck, a statistical majority of companies aren't around that long. This is not the case for personal servers, of course, but they were historically never secured with HTTPS because of the cost. That critical difference makes any statistics from that period wholly invalid when determining proper lengths for certs in this day and age.
Also, folks periodically find weaknesses in crypto technology that requires you to rekey your servers. For this reason, periods should be long enough to not be annoying, but short enough that people have to manually intervene every two or three years, to ensure that sysadmins realize that their keys are no longer strong enough and upgrade things accordingly. IMO, automated upgrades actively hinder security by making the process "out of sight, out of mind". Whether that difference matters or not remains to be seen, but it is at least cause for concern.
And my point is that it isn't their place to discourage sysadmins from monitoring their server cert upgrades. It's fine for them to encourage the various web servers to make the automatic upgrades easy so that people with no experience have an easier time, but it is crossing a line to insist that we shouldn't be allowed to be cautious.
That's downright terrifying to me. I've had at least a few situations where a seemingly innocuous cert upgrade went horribly wrong and I had to roll back to a previous configuration to get back up and running. The last thing I want is for that process to be fully automated. There's a reason I don't automate my TLS cert upgrades, and it isn't because it isn't easy to do. It is because if anything goes wrong, I want to be abso-freaking-lutely sure that I'm right there beside the machine when it fails so that I can fix the problem quickly.
Yikes. Ninety days? Having such a short expiration period weakens security in at least a couple of ways:
In short, what the f*** were they thinking?
I've read their statement on the subject, which claims that 90-day certs are the most common length on the web. That's true, but only because there are a whole lot of companies who give away free certs, but limit the duration to 90 days in the hopes that it will drive people to pay money for longer certs. The reality is that 100% of the certs that people pay for are a year or longer. And for that matter, I can get free 1-year certs from StartSSL, so why in the world does anybody even use those? I don't get it....
And there's also one huge problem with that scheme, which is the use of shared servers. If you're using a shared hosting provider and fifty people upgrade their SSL certs once a year, you have 50 server restarts per year for a total of probably three or four hours of downtime. If they upgrade their certs more than four times per year, that's almost a day of downtime annually, unless the ISP forcibly upgrades everybody's certs all at once, but that would mean giving your ISP the credentials to log in for you, which represents an even bigger security risk.
So even if I didn't have this latest security incident as a reason, I still wouldn't touch Let's Encrypt with a ten-meter pole....
This. If it isn't under your direct control, it isn't really yours.
The bigger problem, IMO, is that Apple has stopped providing any incentive to return nonfunctional devices for recycling. For example, I have an iPhone 5 with a dead power button. According to Apple, its value is zero, even though it is perfectly usable with a dead power button. You just can't reboot it without having a power supply to turn it back on. That phone is worth hundreds of dollars in repair parts, because the case is perfect, the screen is perfect, and I replaced the battery just a few months ago. Or they could fix the power button (requires soldering, unfortunately) and give it to somebody as a refurb. Despite this, Apple won't pay me a cent for it because of that one minor issue.
IMO, Apple's claims of trying to reduce e-waste are basically a sham. If there's no incentive to return a product for recycling, it is likely to sit on a shelf gathering dust, or worse, go into a garbage can, when it could just as easily be used to make repair parts more readily available and thus reduce the need for such extortionate repair part prices. Until Apple gets serious and starts giving reasonable gift cards in exchange for your dead phones, I will still consider e-waste to be a real problem, and I'll still consider their exorbitant parts costs to be a big part of that problem.
I've never heard the term "network summarization", so I assume you mean "route summarization". Unless I'm misunderstanding you, that's IT stuff, which is usually considered part of CIS, not CS. But even if we broaden the definition of CS to include CIS, the math that you're talking about is trivial, and there are almost certainly tools that will do most of the work for you, which means that the limit of the math understanding required should be looking at a pile of numbers and saying, "Hey, those look kind of similar". If that isn't the case, don't worry, it will be true soon enough. There's no reason for IT people to do such work by hand. After all, computers are really good at simple binary math....
I'm not arguing that programming is all of CS. I'm arguing that fundamentally, the purpose of CS is to make you a better programmer, and that unless you plan to work in academia for the rest of your life, anything that doesn't do so should be considered optional, for your enjoyment, rather than a core requirement. And I'm arguing that math falls into that category of things that are only critical to a tiny fraction of programmers, which means it should be purely elective, and taken by people who enjoy doing math, rather than being seen as some critical foundation that every programmer must have.
Well, one big difference between these sorts of designs and helicopters is that the blades are bounded. You're not worrying about rotors touching because other stuff will hit first. That's subtle, but critical at ensuring safety.
Another big difference is that presumably a computer would be controlling the blades to ensure level flight, and the vehicle would be in a fly-by-wire mode where the user controls altitude, forward velocity, and turning. Presumably the vehicles would, then, be absolutely level, even when turning.
But yeah, you're probably right about that buying you only one layer. I don't think even computers can compensate for turbulence quickly enough to deal with multiple layers at 15 foot separation. :-)
BTW, there are ways for quadcopters to continue flying after a rotor failure. It requires computers to control the speed of the rotors, but that goes without saying anyway. So they're potentially even safer than a single-blade design, but only if you have the right computer control system.
Sorry, yes, that's what I meant. The first derivative of the sales rate is decreasing towards 0 (tapering off). The sales are just flattening out.
You can strengthen your muscles with steroids. That doesn't mean that body building requires steroids.
The fact that math can strengthen your brain does not make it a fundamental requirement for computer science. It is just one of a nearly infinite number of possible paths to such brain development. Besides, by the time most people take calculus, those parts of their brains are mostly formed....
That makes me sad.... Every programmer really ought to at least have a high-level understanding of those subjects. They probably won't use it much, but their eyes shouldn't glaze over. :-) That doesn't mean they really need to be able to be able to design caching hardware that minimizes synchronization issues or know how to design caching algorithms to improve the cache hit rate, but they need to recognize the sorts of programming designs that can lead to poor cache performance, like iterating an array in the wrong major order for their particular language....
Let me rephrase that. Probably 99% of people doing work in those fields do not have to use math directly. You can do some amazing 3D modeling and rendering without fully understanding how the computer does interpolation of spline models under the hood. You can compute netmasks using a JavaScript calculator. You'll never have to do network path optimization or other such math unless you're writing kernel code or designing some replacement for TCP/IP, which is maybe 1/1000th of one percent of networking people. And so on.
CS is dozens of unrelated fields that each build specialized knowledge on top of computer programming. Accounting, by contrast, is basically just one huge body of knowledge built atop a tiny subset of mathematics. The two statements are not really equivalent.
Most of the CS disciplines do not require large amounts of mathematics unless you're doing research, and even then, most of the work is not the math. That's just the final data analysis step, and you can easily grab a math major to do that. Really, only a tiny fraction of the work even in the most research-heavy CS fields involves math, which means it is absolutely not necessary for everybody to be highly skilled in those areas. It doesn't hurt, mind you, but IMO, it usually isn't nearly as useful as having a better understanding of how the computer actually works.
I'm not sure which part of that to comment on first—the tiny percentage of software engineers who write games or the ridiculous number of hours their employers tend to expect them to work—so instead I'll say, "Just keep telling yourself that when you reach thirty and realize that you hate your job."
Besides, even in game design, not everybody is designing the physics engine. You need other people to create models, design skins, design the overall game mechanics, write the in-game chat client, write level downloaders, etc.
Unless you want to spend your life doing academic research, if you're learning CS, you're learning it with the intent to use it writing software. So in practical terms, yes, computer science and programming are basically the same thing the moment you step off that platform with your degree in hand.
With that said, computer science includes a number of related fields. Programming is just one aspect of CS as a whole. Many of the others fields use even less math, and a few of them use more. For example:
And so on.
You're both wrong. I started writing software before I knew what multiplication meant. Computer science, with the sole exception of the statistics-heavy research that you do at grad school level, doesn't require even the most basic math skills. They're completely and totally orthogonal. The fact that the computer is doing lots of math under the hood doesn't mean the programmer needs to know or care. In fact, the fallacious belief that CS uses lots of math and thus must be hard is the primary reason that so few people take an interest in CS, even though far more people are capable of understanding CS than, for example, trig.
The reality is that writing software is nothing more than telling computers what to do, then figuring out why your instructions didn't have the desired effect. To write software, you have to be able to understand the syntax, and you have to be able to simultaneously look at small details (e.g. the code in a particular function) while putting them in the context of a larger whole (the program). You have to be able to understand how small changes in one place can have huge effects on the opposite side of the app by being able to visualize data flow from point A to point B. None of these things involve math; it's all spatial relationships and abstract thinking.
Incidentally, the student in your example is right. 99.999% of programmers won't ever need calculus. In seventeen years in the industry, I haven't used calculus even once. The highest math I've dealt with was a bit of matrix math and various transforms (e.g. DCT, FFT) between time domain and frequency domain. And even then, I can count the number of times that I did that on one hand. And not once did I ever have to actually implement the transform, because there are already implementations for such things that you can bring in as libraries. Most of the hard math is already done for you. This does, of course, mean that there must always be a few math nerds involved in writing computer software, because somebody has to create and maintain those libraries, but the vast majority of programmers just need to understand what it does at a very high level.
By contrast, every programmer needs to get good at architecting software properly. Of course, you can somewhat learn that as you go along, so long as you're exposed to good code and can use it as an example (or bad code, and can use it as a cautionary tale).
Now let me turn that around. Do you really want apps on your phone written by people who are used to writing software for the avionics systems on aircraft? Those folks churn out code at a rate that is orders of magnitude too slow. Different types of software require different types of programmers. There will always be a few people who need to do mission-critical, low-level coding. The rest of the software world can then import their framework and design apps to use it, and there's nothing wrong with that.
If they had done so, it might actually have been funny—like a bad episode of South Park or something.
FTFY.
As long as you limit its altitude, lack of refueling isn't necessarily a big problem. Just design it to refuse to fly more than thirty feet above the current road grade, and ensure that it is designed to automatically find a spot to land when it gets below two minutes of charge. The issue of getting a tow is, of course, still a problem, but at least you won't have it falling out of the sky on top of someone.
This sort of design would allow for two (and in some cases, three) layers of traffic instead of one, and would allow detours around wrecks without having to necessarily be precisely above the road surface, which would basically fix everything that's wrong with freeways, but without turning it into a free-for-all and interfering with normal air traffic. There would, of course, be no-fly zones, such as the stretches of 101 and 880 at the ends of the SJC airport runway, but this would also open up the use of 87 as a cutacross, so in a pinch, a lot of folks could avoid problems on the ground layer, reducing the impact of the problem.
Yeah, good luck with that. As far as I can tell, there's even less incentive for the company to care about your needs once you're on a subscription model, because the second you stop paying them, you lose access to your files, and they know you won't do that, which means you'll keep paying them just to keep using the software, whether they improve things or not. At least with a normal sale model, they have to do enough upgrades to earn your purchase.
Products that are actively innovating are almost invariably sold, not rented; products on a subscription model are typically largely coasting.
My recollection is that the statute of limitations generally begins either when an event occurs or when it is discovered, but that the latter is generally reserved for situations where the malfeasance is not obvious until discovered. The judge and prosecutor have the same last name, so that doesn't really apply here.
Actually, I think you're all wrong. We reached peak app while back, but it has nothing to do with the apps and everything to do with platform maturity.
What we're seeing right now (or so I've read) is that smartphone sales are tapering off across all platforms. At this point, most of the people who are going to buy a smartphone have already bought one. The few remaining new adopters represent the long tail of late adopters and luddites, plus kids coming of age. Most of the new sales, then, are replacing an existing device, rather than adding a device.
Now, consider that there are only two groups of people who are likely to download a new app: people who are looking for a solution to a problem and people who just got a cell phone and don't have any apps on it yet. To reach the first group, you have to actively promote the app to that target audience. This costs money, so most app developers aren't willing to do it. And even if they attempt it, they usually do so badly, using poorly targeted ad platforms that don't allow you to skip the ad early to indicate disinterest and don't take previous clicks into account when deciding whether the person might or might not be likely to click on the ad.
This leaves the second group—the new users. The problem is, that pool is drying up. Except for platform switchers, the overwhelming majority of people who buy a new smartphone already own one, and that means they already have a collection of apps. Therefore, with the exception of apps that don't get updated and break on new hardware, there's really no impetus to make them download a bunch of new apps.
So for app growth to continue at its previous pace, either marketing must get better (read "more accurately targeted") or a new platform is going to have to come along that is so amazing that it is able to draw a sizable percentage of users away from Android or iOS. Either that or some existing (but noncompeting) platform like tvOS will have to exhibit a lot of rapid growth, and by attracting new adopters there, drag users into installing the same apps on other platforms.
In most states (according to Wikipedia), those laws don't apply to presidential elections. And even when they do, you can be certified as a write-in.