No idea. I won it several times, and it kept giving me that truncated code. This was on Safari 9.1 (OS X v10.9), for whatever that's worth.
I also noticed that if I go to one of the custom levels, play through it, then start playing normally (without reloading it without the extra fragment identifier), I get to the end of the first level, reach the top of the ladder, and get stuck. The problems might be related (but probably not).
Growth*(1-CorporateTax)*(1-CapitalGains) is a fairly competitive number. If you fuck with those numbers capital will leave your economy. Adults understand this and more or less assume it's understood. You'll note that growth is noisy.
Actually, there's no historical correlation between capital gains tax rates and economic growth (source: bloomberg), at least in the U.S., which is to say that there's no evidence whatsoever that raising the capital gains tax rate to the same as earned income (or even higher) will hurt the economy in any way.
Both corporations are using these as loyalty rewards program titles.
A rewards program's purpose is to thank their customers for their loyalty. To me, this is not substantially different than a fruit company trying to trademark the word "Banana". The USPTO should have rejected the initial registration as too descriptive.
That is precisely what trademark law is here to stop.
Bzzt. Thanks for playing. Trademark law is to prevent confusion in the marketplace by allowing one company to sell products or provide services that are substantially similar with substantially similar names in a way that would confuse consumers into thinking that they were getting one product from one company and instead getting the other product from the other company.
This doesn't qualify for two reasons. First, as I stated before, the marks are very different. Second, the programs aren't at all similar. Let's look at them a little more closely:
The Citi ThankYou Rewards program is a traditional loyalty rewards program in which you can earn rewards for spending money on their credit card, and redeem them for various things at various merchants (usually at a higher cost than if you had taken a 1% cash reward).
AT&T Thanks, as far as I can tell, isn't a rewards program. It's literally just AT&T offering a bunch of special deals to say thanks. The same offers are available to all of their customers; there's no earning points, there's no spending points.
So basically, no consumer could plausibly confuse Citi ThankYou Rewards points with AT&T Thanks even if you think that those two names are somehow confusingly similar.
"Keeping your money" because you've used it in socially beneficial ways (eg, investing in a business that grows and hires people) is not much different from getting some of your money back when disaster strikes.
Some of it is not different at all—deducting stock losses, for example.
At least in the US, there are no cradle-to-grave government handouts, nor even a succession of handouts a healthy person can use to lounge in the lap of perpetual, unearned luxury.
Sure there are. There just aren't any cradle-to-grave handouts for people who are born poor. If you inherit large amounts of wealth, however, the government gives you cradle-to-grave handouts in the form of capital gains tax breaks on unearned interest/growth from that unearned inheritance.
This is the way trademark law works. You must defend the trademark or risk losing it.
This is not the way trademark law works.
The way trademark law works is that you must defend against legitimate, plausible violations of the trademark that are likely to cause confusion in the marketplace, which this isn't. "Thanks" is clearly not the same as "ThankYou", and more importantly, "AT&T Thanks" is clearly not the same as "Citibank ThankYou Rewards". The fact that AT&T uses their own name as part of their mark means that there's not a snowball's chance in you-know-where of a consumer being confused and thinking that these are Citibank ThankYou Rewards. For one thing, AT&T has heard of a space bar.
And even if AT&T didn't use "AT&T" in its mark, and even if Citi had a trademark on "Thank You" instead of a much narrower trademark on the nonstandard spelling "ThankYou", IMO, the AT&T usage still wouldn't cause confusion, because "Thanks" and "Thank You" would still be decidedly different in their formality. It would be as though Apple trademarked Bonjour (a long-ago contracted "Bon jour"), and then Google came up with a clone and called it "Yo", and Apple sued for trademark infringement....:-D
But let's pretend for a moment that there really is legitimate concern that AT&T's "Thanks" could cause confusion. Citigroup is still not required to defend the trademark with a lawsuit. They could start with a C&D, and suggest ways to tweak the usage that would prevent the consumer confusion that they believe exists (and then sue if the other party doesn't fix things). Or they could license the use of the trademark for anything from zero cents (with a "used by permission" notice) up to a trillion bucks per year. Any of these things constitutes defense of the mark.
Now it is certainly possible that Citigroup did all of those things and AT&T said no. If that's the case, then yes, their only options are to either sue or accept the possible dilution. But even if they choose the latter, it does not invalidate the mark. It takes a lot more than just one single vaguely similar name to dilute a mark to the point that it is no longer protectable.
Either way, if I were AT&T's lawyers, I'd register a trademark for "Eff You" (though the USPTO would probably reject it), and then tell Citigroup that they can tell their customers what they really think of them in exchange for an agreement to drop their frivolous lawsuit over "thanks". Meanwhile, AT&T should also petition the courts to invalidate the trademark on account of "Thank you" being hopelessly generic already, and thus squarely outside the realm of trademark protection, while simultaneously dropping their equally ridiculous trademark on "thanks". Of course, they would likely lose, because "ThankYou" is not the same as "Thank You", but they might at least get the courts to narrow the trademark protection to the closed-up form (exactly that and no more) on grounds that "Thank You" is descriptive. And if they did manage to get it completely thrown out on a countersuit, it might make Citi think twice about whether it is really worth filing such suits in the future....
(I'm assuming, of course, that AT&T's mark on "thanks" and Citi's mark on "ThankYou" aren't trademarks on stylized marks, which would render the trademarks much less ridiculous, but would also almost guarantee that they don't conflict with one another.)
1 and 2 constitute what we colloquially refer to as the ISP.
And in many cases, local caching servers for services like Netflix and YouTube and Akamai and so on, designed to keep the ISP's bandwidth bill under control. And in some cases, they may own big chunks of the backbone. For example, Comcast owns pipes that reach various parts of the U.S., so connections from Comcast customers might travel within the ISP's own network for a large portion of its route.
Either way, a good chunk of your monthly bill goes towards the connection to the backbone, and having multiple ISPs means that you'll be able to choose between the cheap ISP that underprovisions and the expensive ISP that doesn't underprovision as badly, rather than being locked in to service by whoever owns the last mile pipe.
If 1 is a municipal fiber network, then that means an ISP is just an interconnect between the fiber network and the backbone?
So to answer your question in two words, "Yes, but...".:-)
It's fascinating, really. The main reason RC is less popular is that it is available in fewer locations and has less shelf space allocated to it in the locations where it is available. Why is it available in fewer locations, you might ask, and why does it have less shelf space? Because it is less popular.
With little math knowledge your available problem scope is basically 'computer bean counting'.
What the kind of problems do you consider to not be "computer bean counting"? I've done device drivers, server-side code, end-user native apps (iOS and OS X), client-side browser code (JavaScript), data format conversion tools (custom parsers, reverse engineering of binary file formats), and probably half a dozen other things that I'm forgetting right now. I can count the number of times when I needed to perform math beyond the limits of Google calculator on one hand. Occasionally, I've had the computer do math for me, but that doesn't require you to be good at actually doing math.
I've made zero use of calculus. I think I've used statistics two or three times. And I don't think I've ever used graph theory outside the context of interview questions (and minimally, even there). And I was always good at that stuff; it isn't because I've avoided jobs where I need math, but rather because it just isn't necessary for the overwhelming majority of programming jobs.
More to the point, I've known plenty of people who were not great at math who found programming to be straightforward. And I've known plenty of people who are good at math who struggle with programming. There's just not a strong correlation there, and I say this as someone who has taught CS courses. Other educators have come to similar conclusions, so I'm not alone in that assertion. Maybe at the grad school level, in some schools, there might be a correlation, but for an undergrad CS program, as far as I can tell, the only situation in which success in CS courses is correlated with math success is when the program requires you to take a bunch of math classes; that's quite literally begging the question....
(I'll go ahead and say it, switch to EE if you can hack it.)
Knowing about the hardware does open up a number of opportunities. I'm not sure I would necessarily agree that people should do so merely because they're able to do so, though. That's like people taking CS because they're good at programming, rather than because they enjoy it. It leads to a lot of people working in jobs that they hate just because those jobs pay the bills.
Personally, I favor a very different approach; get your undergrad degree at a low-cost uni that teaches the nuts and bolts of programming and basic CS. You'll get about the same undergrad education at a school that costs $8k a year or $20k+, so save your money for grad school when you know enough to absorb more advanced stuff. Then get your Master's at a research uni and take classes in as many different areas as you can—everything you think you might be interested in, from CE and EE courses to 3D animation to data compression to storage systems to operating systems.
At all levels, focus on breadth. There's plenty of time to gain depth when you're actually working in the field in a particular area. And of course, if you get to your second year in college and decide that you're not enjoying writing code, find another degree program.:-)
FTP and SFTP are trivial user-space servers. Of course they'll work. OS X doesn't support AFS, AFAIK. I'm not surprised that Apple hasn't added NFS support yet; I hope they will, because there are many situations where SMB doesn't work very well.
As for AFP, I'm not surprised that they haven't added support. AFP is really designed around HFS+. It performs poorly on other filesystems because of things like the searchfs system call not existing or being emulated by brute force. AFP was barely usable on UFS, and aliases didn't work. Supporting AFP would likely require a lot of extra engineering, whereas most of those behaviors (aliases, searching via Spotlight instead of filesystem metadata) are at least partially supported through emulation atop SMB already, so they'd get a lot of that functionality for free.
Here's hoping they don't make APFS support case-insensitive storage. It periodically causes major headaches for developers writing iOS apps when they make some typo and create a binary that runs fine on the simulator and fails on the device. It also means that certain companies (e.g. one large photo editing app company whose names rhyme with "A Toby") don't bother testing on case-sensitive volumes, leaving users who actually need case sensitivity in a world of hurt.
I would love it if Apple jerked the rug out from under those sorts of companies and made them fix their bugs.
I suspect it has been in progress since Apple's decision to pull ZFS, which offered many of these features... and possibly longer. That's way more than 5 years; in fact, next year (the expected release year), it will have been the ten years that the GP says makes a filesystem trustworthy.
Seriously. All it would take is somebody manufacturing a version of those remote pan/tilt/zoom security cams with a single-shot gun built in. Make it so that people who are entirely outside the scope of the conflict can easily identify the perp and take him/her out without ever being in harm's way. If every store and classroom and movie theater and bar and club in America had one of these things, we would never have mass shooting incidents, because they wouldn't even get their second shot off.
The problem with the notion of concealed carry is that the people doing the carrying are in the thick of things, which makes them more likely to hit an innocent bystander, more likely to get shot themselves, and less likely to be able to see the attacker because of their vantage point. But mounted above everybody's head, a security camera can find the assailant, aim, and put a bullet through that person's skull quickly enough to end the threat from the moment the first shot is fired. Combine that with automatic gunshot detection algorithms, and technology could absolutely stop mass shootings, or at least the traditional kind.
The real question, of course, is whether it is worth the risk of someone cracking into those systems and killing innocent people with them, the risk of governments hacking them as a means of quashing dissidence with plausible deniability, etc. Maybe have them tied into the fire alarm system where the trigger can't be activated unless the fire alarm is pulled first. Or maybe make it illegal to have them be network-connected in any way. *shrugs*
Well, they're partially right. Some tasks do lend themselves to an immersive design that controls your screen. Video editing and photo editing are great examples, because they both need to control the menu bar and other stuff to minimize visual distractions. I remember when Apple made the Apple icon blue and Adobe had a coronary and made the add an API that would let them turn it grey in Photoshop....
Other tasks lend themselves to the opposite. For example, I routinely have Xcode running with two or three or four windows, editing different files in each window, along with a stack of eight or ten Terminal windows running vi in an ssh session to let me edit code on a staging server that provides content to the software that I'm writing in Xcode. If I were forced into a one-app-per-screen, one-view-per-screen world, I would be forced to run Linux as my primary desktop and relegate the Mac and Xcode to a VNC window, because that's the only way I'd be able to get work done.
And it isn't even different users. I do video editing and photo editing, too. I do rather a lot of photography, actually. My Lightroom library is approaching 70,000 photos, most of which are on a 2 TB portable hard drive because I filled up my terabyte MacBook Pro's internal drive more than once. So it isn't that I don't appreciate having better full-screen support. It is absolutely useful for some apps. But it is also absolutely crucial that such changes be optional and user-controllable, because what works in one situation won't work in every situation.
In much the same way that I would never go back and use an Apple II, I could never replace my laptop with an iOS tablet. I wouldn't survive a week if I tried that. And no matter how slowly Apple made the transition, there would eventually be a point where I'd be running a different operating system because I was no longer able to function without proper windowing. And I say this as somebody who has exclusively used Macs since 1994.
Next major they improve spaces support (potentially making an application space run in a window)...
They still don't have a usable mechanism on iOS for having more than two apps onscreen at the same time. There's no way OS X users would tolerate such a limited environment. There are definite limits to how far unification can go without driving users away, and I think we're pretty much at that point already.
Full-screen UIs are useful for some things in some situations, and are favored by people who use their computers for very limited purposes—the sorts of people who could just as easily use a tablet with a keyboard (and possibly without). Although it does no harm to make that usage model possible, it would be very harmful to make that usage model the norm.
How do I know that it would be harmful? Because I remember history. We already tried the whole "put the entire app in a single window" model. It was called Microsoft Windows. Mac OS was always an alternative to that UI abortion. That design didn't work when Microsoft did it; it would be pretty silly to believe that it will suddenly magically not suck if Apple does the same thing. It will suck almost exactly as much, and for the same reason.
Once applications can (optionally) support multiple input methods (touch / mouse / keyboard), all new apps are already using the same underlying tech (CloudKit, UIKit, etc.) across all apple OSes, and iOS apps bytecode format already runs on macOS.
That's just not realistic. The sorts of apps that folks use on OS X aren't feasible on iOS precisely because windows matter and precise pointer positioning matters. I don't think we'll ever see UIKit replace AppKit or vice versa, because they target fundamentally different types of hardware for fundamentally different types of apps.
This is not to say that they won't make it possible to run iOS apps on OS X. That would be pretty trivial; they already have a simulator that can run iOS apps if recompiled for the x86-64 or i386 platform, and with a small amount of extra effort, they could make the remaining unavailable APIs work correctly, then allow folks to submit x86-64 slices in iOS apps and add a tiny bit of code to UIKit that would cause it to open a new simulator window when you double-click the app.
That said, it has been that trivial for eight years now, and they haven't done it, which suggests that it isn't likely.
No one can argue "system integrity" AKA Rootless doesn't improve security, but it can't be argued it doesn't disable some use cases.
Which is why you can disable it. Tabs should be no different.
Example: click-to-focus. It's not possible to have focus-follows-pointer in Mac OS X. There is no option that would enable it. Apple decided that everyone should use click-to-focus, and that is the unassailable law in the Mac world.
It has been that way since 1984, though. There's a big difference when you're talking about something that they change after the fact. They at least sometimes make those optional. Not often enough, mind you, but....
How would we know? They always find "gun free zones".
Actually, no, that's not true. There's no evidence whatsoever that shooters choose gun-free zones because they're gun-free. In nearly every case, we actually know why they chose specific targets, and those reasons were typically specific to the individual shooter, rather than being based on the probability of guns being nearby. For example, if someone is going to mow down his or her coworkers in vast quantities, he or she would pretty much have to do it at work. In almost every mass shooting case in the U.S., there have been specific people or groups of people who were targeted, and the locations were chosen based on where those specific people or groups of people were likely to be.
This is a classic "cum hoc ergo propter hoc" situation. If I picked 100 random buildings in the United States that had high enough population density and a low enough exit count for a mass shooting to be plausible, probably 99 of those 100 would turn out to be gun-free zones. Most workplaces don't allow them, schools, government buildings, shopping malls... basically anywhere that you would find large numbers of people. The shooters would have actually had to go out of their way to choose mass shooting locations that weren't gun-free zones and in which their targets were still together in large groups.
The number of gun deaths per capita is lower, but the number of Murders per capita is higher in many cases.
Careful, there. You're confusing cause and effect. Nobody puts in place strict gun laws just for the fun of it. They do it because they're concerned about the murder rate being higher than you would typically expect for a city of that size. In every case, I think you'll find that the murders led to the gun laws, not the other way around.
He could sue them under ADA if they act on any medical information other than a fitness-for-duty test.
You can sue for anything, but a security guard suing over a failed psych eval would have been laughed out of court. If someone is subjected to a psych evaluation by his/her employer and shows signs of being psychologically unhinged, that absolutely disqualifies that person from being fit for duty in a job that regularly involves rationally evaluating when to use a dangerous weapon. In fact, mandatory psychological screenings are common when applying for security guard positions in the U.S. for precisely that reason.
And it took the cops three hours to storm the building while people were dying inside because they thought there was a bomb and hostages, the former due to some bad camera angles. So...for better technology in this incident, I'd go with automatic emergency lighting and web- or phone-quality cameras that could be accessed from outside the building.
That's a good start. I would say:
Fire alarms should trigger full indoor lighting until deactivated.
People should be trained to pull the fire alarm in the event of a gun attack.
Kill-bots would clearly prevent shootings if broadly deployed.:-)
Tear gas grenades could also be highly effective, particularly if you can trigger them remotely.
Above all else, though, the best thing we can do is train people how to handle these situations. Remember the three Ds: Distract, Disrupt, and Disarm.
Distract the attacker by pulling a fire alarm, suddenly changing the lighting, shouting at the attacker from an unexpected direction, throwing something at the attacker (keys, cell phones, beer bottles, purses, bricks), etc.
Disrupt the attacker by using a chair to knock the gun from his/her hands while his/her back is turned in response to the distraction.
Disarm the attacker by beating the ever-living s**t out of him/her until he/she can no longer reach for another weapon.
Remember those rules, and whenever you enter any room or building where your opportunities for escape are limited, pay attention to defensible positions, and be prepared to quickly move to one of those positions and invoke the three Ds if necessary. A few moments of preparation can make all the difference.
Actually, no, that chart doesn't prove otherwise. It shows that the gun death rate is dropping while the number of guns is increasing, but it does not prove that increasing the number of guns resulted in the decrease in gun deaths as you imply. It could just as easily be true that the increased number of guns resulted in more deaths than would otherwise have occurred, but that this was overshadowed by the sharp decline in gun deaths caused by a general reduction in crazy people, a general increase in incarceration of dangerous felons, or even the reduction of lead in gasoline.
For this reason, if you wanted to prove your theory correct, you would need more than just a vague inverse correlation in a single graph. You'd have to start by comparing the rate of gun ownership increases in various areas and the rate of decrease, to determine whether those two numbers are correlated in some way, and if so, in which direction.
Unfortunately, even that won't really prove your point one way or another, because there's every possibility that the increase in gun ownership could be caused by the increasing violence in an area. So a proper study would have to factor in the timing of changes in the slope of those lines over a long period of time at a fine-grained level.
Fortunately, a team of Stanford law professors have done that study. Unfortunately for you, they found precisely what the GP said—that every action that made it easier for people to own guns resulted in a statistically significant increase in the amount of gun violence without increasing the probability of bystanders preventing crimes.
Slashdot Mirror
Thanks.
No idea. I won it several times, and it kept giving me that truncated code. This was on Safari 9.1 (OS X v10.9), for whatever that's worth.
I also noticed that if I go to one of the custom levels, play through it, then start playing normally (without reloading it without the extra fragment identifier), I get to the end of the first level, reach the top of the ladder, and get stuck. The problems might be related (but probably not).
Actually, there's no historical correlation between capital gains tax rates and economic growth (source: bloomberg), at least in the U.S., which is to say that there's no evidence whatsoever that raising the capital gains tax rate to the same as earned income (or even higher) will hurt the economy in any way.
A rewards program's purpose is to thank their customers for their loyalty. To me, this is not substantially different than a fruit company trying to trademark the word "Banana". The USPTO should have rejected the initial registration as too descriptive.
Bzzt. Thanks for playing. Trademark law is to prevent confusion in the marketplace by allowing one company to sell products or provide services that are substantially similar with substantially similar names in a way that would confuse consumers into thinking that they were getting one product from one company and instead getting the other product from the other company.
This doesn't qualify for two reasons. First, as I stated before, the marks are very different. Second, the programs aren't at all similar. Let's look at them a little more closely:
So basically, no consumer could plausibly confuse Citi ThankYou Rewards points with AT&T Thanks even if you think that those two names are somehow confusingly similar.
Some of it is not different at all—deducting stock losses, for example.
Sure there are. There just aren't any cradle-to-grave handouts for people who are born poor. If you inherit large amounts of wealth, however, the government gives you cradle-to-grave handouts in the form of capital gains tax breaks on unearned interest/growth from that unearned inheritance.
This is not the way trademark law works.
The way trademark law works is that you must defend against legitimate, plausible violations of the trademark that are likely to cause confusion in the marketplace, which this isn't. "Thanks" is clearly not the same as "ThankYou", and more importantly, "AT&T Thanks" is clearly not the same as "Citibank ThankYou Rewards". The fact that AT&T uses their own name as part of their mark means that there's not a snowball's chance in you-know-where of a consumer being confused and thinking that these are Citibank ThankYou Rewards. For one thing, AT&T has heard of a space bar.
And even if AT&T didn't use "AT&T" in its mark, and even if Citi had a trademark on "Thank You" instead of a much narrower trademark on the nonstandard spelling "ThankYou", IMO, the AT&T usage still wouldn't cause confusion, because "Thanks" and "Thank You" would still be decidedly different in their formality. It would be as though Apple trademarked Bonjour (a long-ago contracted "Bon jour"), and then Google came up with a clone and called it "Yo", and Apple sued for trademark infringement.... :-D
But let's pretend for a moment that there really is legitimate concern that AT&T's "Thanks" could cause confusion. Citigroup is still not required to defend the trademark with a lawsuit. They could start with a C&D, and suggest ways to tweak the usage that would prevent the consumer confusion that they believe exists (and then sue if the other party doesn't fix things). Or they could license the use of the trademark for anything from zero cents (with a "used by permission" notice) up to a trillion bucks per year. Any of these things constitutes defense of the mark.
Now it is certainly possible that Citigroup did all of those things and AT&T said no. If that's the case, then yes, their only options are to either sue or accept the possible dilution. But even if they choose the latter, it does not invalidate the mark. It takes a lot more than just one single vaguely similar name to dilute a mark to the point that it is no longer protectable.
Either way, if I were AT&T's lawyers, I'd register a trademark for "Eff You" (though the USPTO would probably reject it), and then tell Citigroup that they can tell their customers what they really think of them in exchange for an agreement to drop their frivolous lawsuit over "thanks". Meanwhile, AT&T should also petition the courts to invalidate the trademark on account of "Thank you" being hopelessly generic already, and thus squarely outside the realm of trademark protection, while simultaneously dropping their equally ridiculous trademark on "thanks". Of course, they would likely lose, because "ThankYou" is not the same as "Thank You", but they might at least get the courts to narrow the trademark protection to the closed-up form (exactly that and no more) on grounds that "Thank You" is descriptive. And if they did manage to get it completely thrown out on a countersuit, it might make Citi think twice about whether it is really worth filing such suits in the future....
(I'm assuming, of course, that AT&T's mark on "thanks" and Citi's mark on "ThankYou" aren't trademarks on stylized marks, which would render the trademarks much less ridiculous, but would also almost guarantee that they don't conflict with one another.)
And in many cases, local caching servers for services like Netflix and YouTube and Akamai and so on, designed to keep the ISP's bandwidth bill under control. And in some cases, they may own big chunks of the backbone. For example, Comcast owns pipes that reach various parts of the U.S., so connections from Comcast customers might travel within the ISP's own network for a large portion of its route.
Either way, a good chunk of your monthly bill goes towards the connection to the backbone, and having multiple ISPs means that you'll be able to choose between the cheap ISP that underprovisions and the expensive ISP that doesn't underprovision as badly, rather than being locked in to service by whoever owns the last mile pipe.
So to answer your question in two words, "Yes, but...". :-)
FYI, I ran into a bug in the game where the level code it generates is just "1KE0F".
I URL-encoded the localStorage object's save1 value and saved it here in case you want to debug it. :-)
Here's a fun one....
It's fascinating, really. The main reason RC is less popular is that it is available in fewer locations and has less shelf space allocated to it in the locations where it is available. Why is it available in fewer locations, you might ask, and why does it have less shelf space? Because it is less popular.
I don't think the same applies to AMD, though.
What the kind of problems do you consider to not be "computer bean counting"? I've done device drivers, server-side code, end-user native apps (iOS and OS X), client-side browser code (JavaScript), data format conversion tools (custom parsers, reverse engineering of binary file formats), and probably half a dozen other things that I'm forgetting right now. I can count the number of times when I needed to perform math beyond the limits of Google calculator on one hand. Occasionally, I've had the computer do math for me, but that doesn't require you to be good at actually doing math.
I've made zero use of calculus. I think I've used statistics two or three times. And I don't think I've ever used graph theory outside the context of interview questions (and minimally, even there). And I was always good at that stuff; it isn't because I've avoided jobs where I need math, but rather because it just isn't necessary for the overwhelming majority of programming jobs.
More to the point, I've known plenty of people who were not great at math who found programming to be straightforward. And I've known plenty of people who are good at math who struggle with programming. There's just not a strong correlation there, and I say this as someone who has taught CS courses. Other educators have come to similar conclusions, so I'm not alone in that assertion. Maybe at the grad school level, in some schools, there might be a correlation, but for an undergrad CS program, as far as I can tell, the only situation in which success in CS courses is correlated with math success is when the program requires you to take a bunch of math classes; that's quite literally begging the question....
Knowing about the hardware does open up a number of opportunities. I'm not sure I would necessarily agree that people should do so merely because they're able to do so, though. That's like people taking CS because they're good at programming, rather than because they enjoy it. It leads to a lot of people working in jobs that they hate just because those jobs pay the bills.
Personally, I favor a very different approach; get your undergrad degree at a low-cost uni that teaches the nuts and bolts of programming and basic CS. You'll get about the same undergrad education at a school that costs $8k a year or $20k+, so save your money for grad school when you know enough to absorb more advanced stuff. Then get your Master's at a research uni and take classes in as many different areas as you can—everything you think you might be interested in, from CE and EE courses to 3D animation to data compression to storage systems to operating systems.
At all levels, focus on breadth. There's plenty of time to gain depth when you're actually working in the field in a particular area. And of course, if you get to your second year in college and decide that you're not enjoying writing code, find another degree program. :-)
FTP and SFTP are trivial user-space servers. Of course they'll work. OS X doesn't support AFS, AFAIK. I'm not surprised that Apple hasn't added NFS support yet; I hope they will, because there are many situations where SMB doesn't work very well.
As for AFP, I'm not surprised that they haven't added support. AFP is really designed around HFS+. It performs poorly on other filesystems because of things like the searchfs system call not existing or being emulated by brute force. AFP was barely usable on UFS, and aliases didn't work. Supporting AFP would likely require a lot of extra engineering, whereas most of those behaviors (aliases, searching via Spotlight instead of filesystem metadata) are at least partially supported through emulation atop SMB already, so they'd get a lot of that functionality for free.
By that point, it will be too late to fix anything they did wrong, some of which might affect portability.
Here's hoping they don't make APFS support case-insensitive storage. It periodically causes major headaches for developers writing iOS apps when they make some typo and create a binary that runs fine on the simulator and fails on the device. It also means that certain companies (e.g. one large photo editing app company whose names rhyme with "A Toby") don't bother testing on case-sensitive volumes, leaving users who actually need case sensitivity in a world of hurt.
I would love it if Apple jerked the rug out from under those sorts of companies and made them fix their bugs.
Trinity dies.
I suspect it has been in progress since Apple's decision to pull ZFS, which offered many of these features... and possibly longer. That's way more than 5 years; in fact, next year (the expected release year), it will have been the ten years that the GP says makes a filesystem trustworthy.
Ooh. I know this one.
Spoiler: They turn into Reavers.
Four words:
Remote-controlled sniper-cams.
Seriously. All it would take is somebody manufacturing a version of those remote pan/tilt/zoom security cams with a single-shot gun built in. Make it so that people who are entirely outside the scope of the conflict can easily identify the perp and take him/her out without ever being in harm's way. If every store and classroom and movie theater and bar and club in America had one of these things, we would never have mass shooting incidents, because they wouldn't even get their second shot off.
The problem with the notion of concealed carry is that the people doing the carrying are in the thick of things, which makes them more likely to hit an innocent bystander, more likely to get shot themselves, and less likely to be able to see the attacker because of their vantage point. But mounted above everybody's head, a security camera can find the assailant, aim, and put a bullet through that person's skull quickly enough to end the threat from the moment the first shot is fired. Combine that with automatic gunshot detection algorithms, and technology could absolutely stop mass shootings, or at least the traditional kind.
The real question, of course, is whether it is worth the risk of someone cracking into those systems and killing innocent people with them, the risk of governments hacking them as a means of quashing dissidence with plausible deniability, etc. Maybe have them tied into the fire alarm system where the trigger can't be activated unless the fire alarm is pulled first. Or maybe make it illegal to have them be network-connected in any way. *shrugs*
Well, they're partially right. Some tasks do lend themselves to an immersive design that controls your screen. Video editing and photo editing are great examples, because they both need to control the menu bar and other stuff to minimize visual distractions. I remember when Apple made the Apple icon blue and Adobe had a coronary and made the add an API that would let them turn it grey in Photoshop....
Other tasks lend themselves to the opposite. For example, I routinely have Xcode running with two or three or four windows, editing different files in each window, along with a stack of eight or ten Terminal windows running vi in an ssh session to let me edit code on a staging server that provides content to the software that I'm writing in Xcode. If I were forced into a one-app-per-screen, one-view-per-screen world, I would be forced to run Linux as my primary desktop and relegate the Mac and Xcode to a VNC window, because that's the only way I'd be able to get work done.
And it isn't even different users. I do video editing and photo editing, too. I do rather a lot of photography, actually. My Lightroom library is approaching 70,000 photos, most of which are on a 2 TB portable hard drive because I filled up my terabyte MacBook Pro's internal drive more than once. So it isn't that I don't appreciate having better full-screen support. It is absolutely useful for some apps. But it is also absolutely crucial that such changes be optional and user-controllable, because what works in one situation won't work in every situation.
In much the same way that I would never go back and use an Apple II, I could never replace my laptop with an iOS tablet. I wouldn't survive a week if I tried that. And no matter how slowly Apple made the transition, there would eventually be a point where I'd be running a different operating system because I was no longer able to function without proper windowing. And I say this as somebody who has exclusively used Macs since 1994.
They still don't have a usable mechanism on iOS for having more than two apps onscreen at the same time. There's no way OS X users would tolerate such a limited environment. There are definite limits to how far unification can go without driving users away, and I think we're pretty much at that point already.
Full-screen UIs are useful for some things in some situations, and are favored by people who use their computers for very limited purposes—the sorts of people who could just as easily use a tablet with a keyboard (and possibly without). Although it does no harm to make that usage model possible, it would be very harmful to make that usage model the norm.
How do I know that it would be harmful? Because I remember history. We already tried the whole "put the entire app in a single window" model. It was called Microsoft Windows. Mac OS was always an alternative to that UI abortion. That design didn't work when Microsoft did it; it would be pretty silly to believe that it will suddenly magically not suck if Apple does the same thing. It will suck almost exactly as much, and for the same reason.
That's just not realistic. The sorts of apps that folks use on OS X aren't feasible on iOS precisely because windows matter and precise pointer positioning matters. I don't think we'll ever see UIKit replace AppKit or vice versa, because they target fundamentally different types of hardware for fundamentally different types of apps.
This is not to say that they won't make it possible to run iOS apps on OS X. That would be pretty trivial; they already have a simulator that can run iOS apps if recompiled for the x86-64 or i386 platform, and with a small amount of extra effort, they could make the remaining unavailable APIs work correctly, then allow folks to submit x86-64 slices in iOS apps and add a tiny bit of code to UIKit that would cause it to open a new simulator window when you double-click the app.
That said, it has been that trivial for eight years now, and they haven't done it, which suggests that it isn't likely.
Which is why you can disable it. Tabs should be no different.
It has been that way since 1984, though. There's a big difference when you're talking about something that they change after the fact. They at least sometimes make those optional. Not often enough, mind you, but....
Actually, no, that's not true. There's no evidence whatsoever that shooters choose gun-free zones because they're gun-free. In nearly every case, we actually know why they chose specific targets, and those reasons were typically specific to the individual shooter, rather than being based on the probability of guns being nearby. For example, if someone is going to mow down his or her coworkers in vast quantities, he or she would pretty much have to do it at work. In almost every mass shooting case in the U.S., there have been specific people or groups of people who were targeted, and the locations were chosen based on where those specific people or groups of people were likely to be.
This is a classic "cum hoc ergo propter hoc" situation. If I picked 100 random buildings in the United States that had high enough population density and a low enough exit count for a mass shooting to be plausible, probably 99 of those 100 would turn out to be gun-free zones. Most workplaces don't allow them, schools, government buildings, shopping malls... basically anywhere that you would find large numbers of people. The shooters would have actually had to go out of their way to choose mass shooting locations that weren't gun-free zones and in which their targets were still together in large groups.
Correlation is not causation.
Careful, there. You're confusing cause and effect. Nobody puts in place strict gun laws just for the fun of it. They do it because they're concerned about the murder rate being higher than you would typically expect for a city of that size. In every case, I think you'll find that the murders led to the gun laws, not the other way around.
You can sue for anything, but a security guard suing over a failed psych eval would have been laughed out of court. If someone is subjected to a psych evaluation by his/her employer and shows signs of being psychologically unhinged, that absolutely disqualifies that person from being fit for duty in a job that regularly involves rationally evaluating when to use a dangerous weapon. In fact, mandatory psychological screenings are common when applying for security guard positions in the U.S. for precisely that reason.
That's a good start. I would say:
Above all else, though, the best thing we can do is train people how to handle these situations. Remember the three Ds: Distract, Disrupt, and Disarm.
Remember those rules, and whenever you enter any room or building where your opportunities for escape are limited, pay attention to defensible positions, and be prepared to quickly move to one of those positions and invoke the three Ds if necessary. A few moments of preparation can make all the difference.
Actually, no, that chart doesn't prove otherwise. It shows that the gun death rate is dropping while the number of guns is increasing, but it does not prove that increasing the number of guns resulted in the decrease in gun deaths as you imply. It could just as easily be true that the increased number of guns resulted in more deaths than would otherwise have occurred, but that this was overshadowed by the sharp decline in gun deaths caused by a general reduction in crazy people, a general increase in incarceration of dangerous felons, or even the reduction of lead in gasoline.
For this reason, if you wanted to prove your theory correct, you would need more than just a vague inverse correlation in a single graph. You'd have to start by comparing the rate of gun ownership increases in various areas and the rate of decrease, to determine whether those two numbers are correlated in some way, and if so, in which direction.
Unfortunately, even that won't really prove your point one way or another, because there's every possibility that the increase in gun ownership could be caused by the increasing violence in an area. So a proper study would have to factor in the timing of changes in the slope of those lines over a long period of time at a fine-grained level.
Fortunately, a team of Stanford law professors have done that study. Unfortunately for you, they found precisely what the GP said—that every action that made it easier for people to own guns resulted in a statistically significant increase in the amount of gun violence without increasing the probability of bystanders preventing crimes.