Actually, that's kind of depressing, because it means that IMO, their PMs are completely out of touch with where the major problems actually lie. The editor is really the only part of Xcode that I haven't had significant problems with. I have never once had a crash while selecting or typing. The worst bug I've found in the editor is that if you Command-/ to comment out the second line of a multiline macro, it won't let you comment out the first line. If that were the worst bug I had seen in Xcode, I would consider it one of the ten best apps on the platform. Rewriting UI code that is basically working well is a colossal waste of engineering resources that could be better spent fixing the steaming pile of hurt that lies underneath it.
It's all the other code besides the editor that basically needs to be thrown out and rewritten—the project editing, loading/saving, indexing, find-in-project, etc. all have either frequent crashes or major performance problems or both. And the "Fix Problem" part of code signing has been nightmarish for me, too, at various recent points in time. And when they replaced the simple, working concept of build platform and CPU with these crazy "schemes" a few years ago, they inflicted what is quite possibly the most unusable UI I've ever seen. It makes actions that should be simple difficult, for no obvious reason.
And the project file format and the IB file format are unholy nightmares from you-know-where for anyone who deals with version control. IB's tendency to make huge changes to files when you made zero functional changes, for example, is the sort of stupid crap that simply shouldn't be tolerated in serious software. Just looking at a nib (xib) file changes the "last saved in version" attribute, and asking it to show you a window or view as it would appear on a different device causes it to change all the numerical values for the position of every single item in every single view.
So no, hearing that they are rewriting the one piece of mostly working functionality does not make me happy. It's a bit like going to buy a used car and having the dealer say, "Well, the engine is burning oil, the brakes are metal-on-metal, and the driver's seatbelt doesn't work, but on the plus side, we were able to replace the steering wheel cover that was discolored after the last owner impaled himself on the eight-inch metal spike sticking out of the dashboard when the brakes and seatbelt failed."
Fair enough. I should have said it provides native read-write support. I'm not sure why it can't boot from it; maybe the boot loader is missing critical bits or the frameworks get confused when running on a non-HFS+ volume in some subtle ways. Either way, the point is that you don't lose access to anything. It just makes reverting a royal pain in the you-know-what.
And if it is a boot loader issue, then there's a nonzero possibility that Sierra reinstalled on top of High Sierra would be able to boot from it.
I can't see why you'd want to add HEVC, which is brand new, still having licensing issues and thus has next to zero adoption before VP9 which is already a major force.
If you can't see why, then you've forgotten the first rule of business analysis:
Follow the $$$.
Apple owns some essential HEVC patents. Therefore, it is in their financial interest to make HEVC popular. Moreover, they have a financial disincentive to make VP9 more popular, because doing so would slow HEVC adoption, thus reducing the amount of money that they will make from licensees over the limited lifetime of the patents.
Further, Apple also owns patents on H.264, and anything that increases VP9 adoption would also decrease H.264 adoption, and thus would have an immediate negative impact on their bottom line.
With that in mind, I can't see why they would want to add VP9 support just to make it easier for their competitors to avoid paying them licensing fees.:-)
Switching to a totally new filesystem is also a slick way of making sure people don't revert back to an earlier version of MacOS. The old MacOS will no longer read your drive after the upgrade.
Not true. 10.12.4 (Sierra) has full support for APFS, just not as a boot volume.
Sounds like you have bad RAM or a bad hard drive. I mean sure, buggy HFS+ implementations (e.g. in the early days of Linux on PowerPC Macs) can result in some of the most spectacular corruption I've ever seen, but Apple's implementation is *amazingly* solid. In two decades of running multiple Macs, I've only seen corruption that didn't get auto-repaired a few times, and every instance has either involved faulty hardware or a sparsebundle served over AFP (Time Machine to an ABS).
No, the big benefit of a modern filesystem is not reliability so much as the ability to take snapshots and back up those snapshots without worrying about files changing while you're backing them up. This might even be enough to make Time Machine and iCloud reliable without bizarre surprises. For example, a few years ago, a friend of mine lost his entire iPhoto library because he kept iPhoto running all the time; iPhoto keeps its library open, and Apple foolishly made the iPhoto library an opaque bundle, so when iPhoto kept the library open, it prevented not only the library metadata, but also the photos themselves from getting backed up. Supposedly that got fixed a long time ago, but I still have a fair amount of distrust towards Time Machine as a result of that incident, and the whole reason behind not backing up open files was that you couldn't reliably snapshot the bundle at a given moment in time; that epic failure would never have happened if Time Machine had been built on top of proper snapshots to begin with.
Databases have the same problem. You can safely back up a MySQL database (with InnoDB, anyway), but to do so, you have to snapshot the entire database, including its journal, all at once, not copy it a file at a time. And so on. There are entire classes of problems that go away when you have proper volume-level snapshotting capabilities. That's why not switching to ZFS was, IMO, the single dumbest mistake that Apple's senior management made in the past twenty years, and possibly in its entire history. Now that we're getting APFS (a decade later), maybe we'll finally get the robust backups that we should have had back in Snow Leopard.
Don't get me started on Xcode, though. Its problems, IMO, have less to do with a lack of QA and more to do with Xcode being what happens when you take a 16-year-old piece of software (ProjectBuilder) and combine it with a 10-year-old piece of software (Interface Builder) and then continue developing the resulting software for another nine years. It started out too complex, and when they had the chance to fix that in 2003, instead of actually simplifying the fundamental architecture, they gave it a re-skin and hid a bunch of the functionality. And then they added IB to the mix and then they started piling on all the code signing stuff and tried to cram installer package support into it and... well, the result is that "Xcode : an IDE:: iTunes : a music player", and the result is unsatisfactory for precisely the same reasons. But I digress.
It's information about who you'd likely voted for.
Which is, frankly, much worse than leaking Social Security numbers or health data. If they had leaked the SSN of everyone in America, it would force some real reform of the credit agencies, preventing them from treating an SSN as proof of identity, but overall, the public wouldn't be harmed. If anything, they would be helped by exposing the notion of "identity theft" as the credit-agency contrivance (fraud) that it is.
And the worst-case scenario for leaking health data is embarrassment if somebody got an STD, but that would quickly become uninteresting to people because it would also quickly demonstrate how many people do. You might occasionally have hiring bias by people who want to avoid their health insurance costs going up, but I would not expect that to be common (because it is quite illegal).
But exposing everyone's likely voting behavior is a grievous violation of personal privacy. Ask a Republican in a majority-Democrat region or a Democrat in a majority-Republican region, and ask them if they think that the people around them would be less likely to hire them if they knew their political affiliation. Ask them if it will affect their ability to socialize. And so on. Thus, voting data can be easily abused to pressure people into conformity.
Worse, that small-scale abuse has the potential to shift the balance of elections, which means that leaking this data potentially has a national impact as well as an individual impact. Based on that, I would argue that party affiliation and likelihood of voting for a given party is quite possibly the most private information that anyone can have about you, and that making that information available publicly is one of the worst breaches of the public's trust that a political organization can commit.
No, they brought it up-to-date. The GP asked them to keep it that way, by which I assume the GP means updating it more frequently in the future. That said, MBP users should be happy. The Mac Mini hasn't had a real upgrade since 2012. (The 2014 refresh was not an upgrade, but rather, a major downgrade. In that downgrade, it gained a better GPU, a slight speed bump, and a slight reduction in power consumption, but it lost removable RAM, the second hard drive, and half of its processor cores, which on the whole means a loss in storage capacity, performance, and upgradability in exchange for slightly better gaming; whee.)
No, no. They don't start out rounded. They start out with square corners. The random collisions on the highway just round them out over time, like a rock tumbling in a stream.
Pretty much. If they have the source code for a 16-bit DOS or Windows app, porting it to 32-bit Window is mostly trivial. It's more than a recompile, but unless it was written in 8086 assembly language, it is obviously much, much easier than reverse engineering it. With that said, given the age of the code in question, it would probably make more sense to keep the interesting core bits that talk to hardware and wrap it with a current, modern UI using modern APIs.
What makes lots of industrial stuff particularly problematic is that even if you have the source code for your bits, it often uses some closed-source compiler/uploader toolchain that only runs on ancient hardware/OSes. In an ideal world, obtaining copyright or patent protection would require making the source code available either publicly or in escrow so that when the company goes away, people who own hardware that depends on it can maintain it themselves, but I digress.
My mom went through 4 rounds of chemo for her breast cancer, which was a kind that could turn malignant...
I think the word you were looking for is "metastatic". All cancer is, by definition, malignant. That's the difference between cancer and a benign tumor or nodule.
The "solution" of course is to buy new industrial equipment to replace the old that you are controlling with that 16-bit computer.
No, the solution is to upgrade your PLCs and other hardware to more modern replacements that can be controlled by a modern computer. That doesn't mean replacing the industrial equipment, just its interface to the outside world.
So it''ll only cost a few hundred grand at best to move off of that 16-bit CNC setup.
CNC? Really? That's just about the most trivial thing you could pick. For many CNC needs, you could buy off-the-shelf control boards, plug them into a modern computer running a modern OS and modern CAD software, do some configuration, and you're done. The hard part is going to be updating the file format to be compatible, and that's still likely to be trivial.
No, it starts getting fun when you're talking about hundreds or even thousands of sensors and valves in a chemical plant that covers thousands of acres, all of which talks using an ancient protocol to software that only runs on 16-bit DOS. That's when it gets fun, because you actually have to write custom software for all of those sensors and valve controllers, on top of new enough hardware that you can usefully talk to it using a modern OS. And then you have to deploy the new setup in such a way that both old and new systems can run in parallel (ideally in lockstep) so that you can then verify that the new setup behaves identically to the old one over an extended period of time before disabling the old setup and letting the new one start running the show, so to speak. But even in that extreme example, you're still just replacing the PLCs, not the whole chemical plant.
Then they can run windows 10 too... thats an awesome operating system for industrial equipment. Honest.
The industrial equipment, realistically speaking, should run itself using PLCs or other hard-realtime systems. The Windows box typically is just a way of updating the software and/or sending new sets of instructions to it. So even if Windows 10 sucks at realtime (which it probably does), that's mostly moot, because it would typically be used as a glorified field programmer, not as an industrial system per se. At least one would hope....
These are things like the bespoke industrial-control software running a 50-ton press built in 1943, or an EDM cutter that still thinks it's speaking to an ASR-33 terminal at the other end of its RS-232 cable.
There are 32-bit ASR-33 terminal emulators available out there. And if they're still running ancient systems for controlling their PLCs, they're running on borrowed time before malware takes over those systems and causes millions of dollars in damage or worse (e.g. StuxNet). Legacy systems written decades ago simply are not designed for the world we live in today, and it is fundamentally unsafe to continue using software written so far back, period. We're at least a decade past the point where the risk of not upgrading that sort of software exceeded the risk of replacing the software, and anybody who says otherwise hasn't fully thought through the risks.
Besides, a properly executed transition is amazingly safe. I've had conversations with a former coworker whose father was doing exactly that about five years ago. Basically, you start out by running the old and new systems in parallel, with the new software in a report-only mode. Then you compare the data reported from both systems and compare what actions would have been performed in response to the signals from the newer system, and you flag any places where those decisions differ. Then you analyze those differences and fix the software. Eventually, after running for some reasonable number of weeks/months/years with no observed differences, you conclude that the old software is not necessary, you switch to allow the new software to control things, and then you tear down the old software so that its security issues can cause no further harm. It's just like any other deployment of updated programming for one of those pieces of equipment, only on a bigger scale, involving bigger changes, and probably some new hardware....
The bigger the risk, the longer it takes, obviously, but twenty-two years is an eternity.
These are hardware peripherals that would cost upwards of half a million dollars to replace, where reverse-engineering is nearly as expensive and considerably riskier.
I guarantee those presses and cutters have had mechanical maintenance over the years to keep them running, replacing parts, etc. Why should it still be running software that hasn't been touched in decades?
As for reverse engineering being expensive, that mistakenly assumes that each of these pieces of software is being used by exactly one company. If that were the case, they would have the source code, and they could upgrade it. If they don't, that means that they bought the software, and so did hundreds of other companies around the world. If it costs half a million dollars to reverse engineer the software and there are 500 companies, then we're talking about less money per company than the cost of buying a new machine to run the upgraded software on.
Yes, yes, there's still the issue of things like PLCs where you have the software that runs on them but not a 32-bit version of the software that uploads programming to them, and in those cases, it is a pain in the backside to replace the PLCs with new ones using the process I described above, but in the end, it is worth it to not be running ancient cruftware that could break at any minute.
More significantly, at some point in the not-too-distant future, I fully expect Intel to decide that emulating the 16-bit and 32-bit i386 ISA is a waste of copious amounts of valuable die space, and just cut out that feature entirely as part of a die shrink. And I would not be even slightly surprised if Apple's planned elimination of 32-bit support in OS X is in preparation for just such an optimization. If and when Intel does drop legacy mode, anybody still using 16-bit code will suddenly be racing against the clock to replace it before they find themselves unable to get replacement hardware should anything break. That's not a position that anyone should want to be in. Better to start planning for a replacement sooner when you can do so on your own terms.
You're either fundamentally missing the point or deliberately avoiding it. I can't tell which. All of those things, to the extent that they are still in use, are still in use because they are actively maintained. Nobody in their right minds is running a 40-year-old version of UNIX. They're running a recent build of Linux or OS X or whatever.
And when you say that they still support software written four decades ago, you're grossly overstating things. For example, although ostensibly you could compile and run a properly written 40-year-old piece of UNIX software today, you would at an absolute minimum have to recompiling it, because A. modern UNIX systems don't even run on the same CPUs as UNIX systems from 40 years ago, and B. even if they did, modern UNIX systems don't even have the same set of system calls under the hood; they use 64-bit system calls with 64-bit inodes, 64-bit size_t and off_t, yada, yada, yada.
And the reality is that the vast majority of software from forty years ago won't even compile because of backwards-incompatible changes in header file names, compiler behavior, etc. You end up making at least minor changes before you can even start running it.
Being able to tweak, compile, and run 25-year-old source code is fundamentally different from being able to run a 25-year-old binary unmodified. Nobody in their right minds should be doing the latter, because supporting such a model basically requires that all OS improvements grind to a halt.
Visual signals must ALWAYS win if there is a discrepancy between what the map says and what the camera says. And that means, you can just get rid of the detailed maps and just use the normal ones everyone uses for their GPS in the car.
Not necessarily. A sign could get hit by a car and bent in such a way that it appears to affect the wrong road. But yes, in general, you're correct.
That's why. There is still a TON of legacy apps out there in use that won't function properly.
At some point, you have to start asking whether the 16-bit app support exists because of the legacy apps or whether the lack of 32-bit versions of those apps is because the 16-bit app support exists.
To put some hard numbers on this, Windows 95 brought 32-bit support to the platform in 1995. So all the 16-bit software out there is 22 years old. Continuing to maintain an entire operating system platform to support software that was written before this year's college grads were even born is just plain insane. That's way too much effort for what should be almost zero benefit.
Killing support for 16-bit software will force the manufacturers, assuming they are even still in business after more than two decades, to update their software to something remotely current. And if the manufacturers no longer exist, then if there's still enough value in the software, someone will take the time to reverse engineer it and write a 32-bit version, or write code that translates the old data files to work with a modern app, or write modern drivers for old hardware or whatever. And if there isn't enough value in that software, it will wither and die. And that's okay.
That said, it could reasonably be argued that they should have done this fifteen years ago, and that at this point, so many of the companies have ceased to exist that the economic impact will be huge. If that is the case, then the right fix is to run a twenty-five-year-old copy of Windows 3.1 in a VM with just enough hardware access to do the job, then walk away.
That depends on how the computer is programmed. One could presumably change the failure mode so that it continues without changing anything until it gets valid data, which would have probably prevented the disaster. Or one could make the failure mode be an emergency descent, which would at least have avoided the stall, in all likelihood, and maybe avoided the crash, too. And a computer could ostensibly use other data like GPS to determine its ground speed and altitude, and use that data as a crude estimation of air speed in the absence of proper data, which is something a person isn't likely to think to do in such a crisis, much less be able to do the computation properly.
In other words, it's hard to say what the computer could or could not have done. A computer might have done much worse, but if they anticipated the situation when constructing the training data, it would probably have done much better. Either way, once the model is trained on such a scenario, it would almost certainly do better.
That's easy. Treat it like a long-term problem. A hard drive lasts, on average, 3 years. That's $150 per TB, which is more than the cost of 8 TB of storage. Assuming you need 8 TB of backup capacity (and really, if you don't have at least a terabyte or two of data, why aren't you using an iPad?), that means $1200 over three years. For that, you can buy eight or ten 8 TB drives. But to make the math easier, buy six.
Back up everything onto one drive, then clone the backup drive to the other five. Next, take five of the drives and store them at work, friends' houses, etc. Every two months, take your current backup drive and swap it with one of those five, proceeding to swap out each drive in a consistent order.
Now, you have better off-site storage than Amazon provides, because your data probably only exists in at most one spot with RAID redundancy at Amazon versus seven independent copies with this approach. And in the worst case, you only lose two months' work. While you're at it, you can use a cheaper tier of cloud backup software to maintain backups of any files modified in the last five months or so, automatically purging changes after about five months or so.
Or not. Whatever. Either way, $50 per terabyte is about an order of magnitude over cost. That's a high price to pay just to have it online and spinning all the time.
Try taking Southwest with kids. The inability to guarantee seating next to your traveling companions makes Southwest a major hassle, and even though sometimes people are willing to swap around to help you out, there's no guarantee that your kids/spouse won't end up twenty rows behind you.
The first airline that splits the difference between preassigned seating and free-for-all will get a lot of business—choose aisle/center/window/don't care; choose front/back/middle/don't care, and rank those two factors plus sitting near your traveling companions in order of preference. Provide info about whether you expect to bring an overhead bag to allow even distribution. Then compute the final seating arrangement right before boarding passes become available by evaluating those weighted constraints and resolving any otherwise unresolvable conflicts in favor of the person who bought a ticket first. That way, when you have a family of three, they'll end up grouped together by bumping the person who requested a window seat back just one row to the same row with somebody who chose an aisle seat (or vice versa), and that all happens before you board.
Think again, genius. Two hours in the air comes to around 750 miles (assuming that the two hours includes time to reach altitude and descend again). At highway speed that's 10+ hours of driving at highway speeds - likely more than that if you hit traffic at either end of that driving trip.
The problem is, two hours in the air comes to 750 miles, but unless there's a direct flight, half of your travel is probably in the wrong direction, and you have layovers during which you're just sitting there.
For example, suppose you want to travel from Nashville to Daytona Beach. By car, the trip is about 10 hours. By plane, you get to the airport and wait at least an hour. Southwest has the only direct flight, so if you don't want to be packed into a cattle car, you'll have a stopover in Atlanta. So you spend an hour and 10 minutes for that flight, followed by a 1.5 hour layover, then another 1.5-hour flight to Orlando.
After five hours and ten minutes, you get to the airport in Orlando and spend about an hour waiting for luggage, getting a car from the car rental place, and getting out of the parking garage. Then you drive backwards towards your destination for another hour. So it took you 7 hours and 10 minutes instead of a 10-hour drive, but for that ~28% reduction in time, you've spent a couple hundred bucks per person plus over a hundred bucks per day for a car rental, and you're still stuck driving an unknown vehicle instead of your own.
No, they aren't. In fact, it is illegal to transport even Lithium ion batteries in the cargo hold of an aircraft under current FAA regulations, precisely because the halon fire suppression system inside the cargo hold is not particularly effective at putting out lithium fires, whereas there are means of suppressing a lithium fire in the cabin of an aircraft as long as a human being can get to the fire in time. Thus, the general consensus among experts is that a Lithium fire is considerably safer in the cabin than in the cargo hold.
Why is the TSA deliberately trying to make air travel less safe?
Slashdot Mirror
Actually, that's kind of depressing, because it means that IMO, their PMs are completely out of touch with where the major problems actually lie. The editor is really the only part of Xcode that I haven't had significant problems with. I have never once had a crash while selecting or typing. The worst bug I've found in the editor is that if you Command-/ to comment out the second line of a multiline macro, it won't let you comment out the first line. If that were the worst bug I had seen in Xcode, I would consider it one of the ten best apps on the platform. Rewriting UI code that is basically working well is a colossal waste of engineering resources that could be better spent fixing the steaming pile of hurt that lies underneath it.
It's all the other code besides the editor that basically needs to be thrown out and rewritten—the project editing, loading/saving, indexing, find-in-project, etc. all have either frequent crashes or major performance problems or both. And the "Fix Problem" part of code signing has been nightmarish for me, too, at various recent points in time. And when they replaced the simple, working concept of build platform and CPU with these crazy "schemes" a few years ago, they inflicted what is quite possibly the most unusable UI I've ever seen. It makes actions that should be simple difficult, for no obvious reason.
And the project file format and the IB file format are unholy nightmares from you-know-where for anyone who deals with version control. IB's tendency to make huge changes to files when you made zero functional changes, for example, is the sort of stupid crap that simply shouldn't be tolerated in serious software. Just looking at a nib (xib) file changes the "last saved in version" attribute, and asking it to show you a window or view as it would appear on a different device causes it to change all the numerical values for the position of every single item in every single view.
So no, hearing that they are rewriting the one piece of mostly working functionality does not make me happy. It's a bit like going to buy a used car and having the dealer say, "Well, the engine is burning oil, the brakes are metal-on-metal, and the driver's seatbelt doesn't work, but on the plus side, we were able to replace the steering wheel cover that was discolored after the last owner impaled himself on the eight-inch metal spike sticking out of the dashboard when the brakes and seatbelt failed."
Fair enough. I should have said it provides native read-write support. I'm not sure why it can't boot from it; maybe the boot loader is missing critical bits or the frameworks get confused when running on a non-HFS+ volume in some subtle ways. Either way, the point is that you don't lose access to anything. It just makes reverting a royal pain in the you-know-what.
And if it is a boot loader issue, then there's a nonzero possibility that Sierra reinstalled on top of High Sierra would be able to boot from it.
Was it a 1 TB Seagate drive, perchance?
If you can't see why, then you've forgotten the first rule of business analysis:
Follow the $$$.
Apple owns some essential HEVC patents. Therefore, it is in their financial interest to make HEVC popular. Moreover, they have a financial disincentive to make VP9 more popular, because doing so would slow HEVC adoption, thus reducing the amount of money that they will make from licensees over the limited lifetime of the patents.
Further, Apple also owns patents on H.264, and anything that increases VP9 adoption would also decrease H.264 adoption, and thus would have an immediate negative impact on their bottom line.
With that in mind, I can't see why they would want to add VP9 support just to make it easier for their competitors to avoid paying them licensing fees. :-)
Not true. 10.12.4 (Sierra) has full support for APFS, just not as a boot volume.
Sounds like you have bad RAM or a bad hard drive. I mean sure, buggy HFS+ implementations (e.g. in the early days of Linux on PowerPC Macs) can result in some of the most spectacular corruption I've ever seen, but Apple's implementation is *amazingly* solid. In two decades of running multiple Macs, I've only seen corruption that didn't get auto-repaired a few times, and every instance has either involved faulty hardware or a sparsebundle served over AFP (Time Machine to an ABS).
No, the big benefit of a modern filesystem is not reliability so much as the ability to take snapshots and back up those snapshots without worrying about files changing while you're backing them up. This might even be enough to make Time Machine and iCloud reliable without bizarre surprises. For example, a few years ago, a friend of mine lost his entire iPhoto library because he kept iPhoto running all the time; iPhoto keeps its library open, and Apple foolishly made the iPhoto library an opaque bundle, so when iPhoto kept the library open, it prevented not only the library metadata, but also the photos themselves from getting backed up. Supposedly that got fixed a long time ago, but I still have a fair amount of distrust towards Time Machine as a result of that incident, and the whole reason behind not backing up open files was that you couldn't reliably snapshot the bundle at a given moment in time; that epic failure would never have happened if Time Machine had been built on top of proper snapshots to begin with.
Databases have the same problem. You can safely back up a MySQL database (with InnoDB, anyway), but to do so, you have to snapshot the entire database, including its journal, all at once, not copy it a file at a time. And so on. There are entire classes of problems that go away when you have proper volume-level snapshotting capabilities. That's why not switching to ZFS was, IMO, the single dumbest mistake that Apple's senior management made in the past twenty years, and possibly in its entire history. Now that we're getting APFS (a decade later), maybe we'll finally get the robust backups that we should have had back in Snow Leopard.
Don't get me started on Xcode, though. Its problems, IMO, have less to do with a lack of QA and more to do with Xcode being what happens when you take a 16-year-old piece of software (ProjectBuilder) and combine it with a 10-year-old piece of software (Interface Builder) and then continue developing the resulting software for another nine years. It started out too complex, and when they had the chance to fix that in 2003, instead of actually simplifying the fundamental architecture, they gave it a re-skin and hid a bunch of the functionality. And then they added IB to the mix and then they started piling on all the code signing stuff and tried to cram installer package support into it and... well, the result is that "Xcode : an IDE :: iTunes : a music player", and the result is unsatisfactory for precisely the same reasons. But I digress.
Which is, frankly, much worse than leaking Social Security numbers or health data. If they had leaked the SSN of everyone in America, it would force some real reform of the credit agencies, preventing them from treating an SSN as proof of identity, but overall, the public wouldn't be harmed. If anything, they would be helped by exposing the notion of "identity theft" as the credit-agency contrivance (fraud) that it is.
And the worst-case scenario for leaking health data is embarrassment if somebody got an STD, but that would quickly become uninteresting to people because it would also quickly demonstrate how many people do. You might occasionally have hiring bias by people who want to avoid their health insurance costs going up, but I would not expect that to be common (because it is quite illegal).
But exposing everyone's likely voting behavior is a grievous violation of personal privacy. Ask a Republican in a majority-Democrat region or a Democrat in a majority-Republican region, and ask them if they think that the people around them would be less likely to hire them if they knew their political affiliation. Ask them if it will affect their ability to socialize. And so on. Thus, voting data can be easily abused to pressure people into conformity.
Worse, that small-scale abuse has the potential to shift the balance of elections, which means that leaking this data potentially has a national impact as well as an individual impact. Based on that, I would argue that party affiliation and likelihood of voting for a given party is quite possibly the most private information that anyone can have about you, and that making that information available publicly is one of the worst breaches of the public's trust that a political organization can commit.
No, they brought it up-to-date. The GP asked them to keep it that way, by which I assume the GP means updating it more frequently in the future. That said, MBP users should be happy. The Mac Mini hasn't had a real upgrade since 2012. (The 2014 refresh was not an upgrade, but rather, a major downgrade. In that downgrade, it gained a better GPU, a slight speed bump, and a slight reduction in power consumption, but it lost removable RAM, the second hard drive, and half of its processor cores, which on the whole means a loss in storage capacity, performance, and upgradability in exchange for slightly better gaming; whee.)
No, no. They don't start out rounded. They start out with square corners. The random collisions on the highway just round them out over time, like a rock tumbling in a stream.
Pretty much. If they have the source code for a 16-bit DOS or Windows app, porting it to 32-bit Window is mostly trivial. It's more than a recompile, but unless it was written in 8086 assembly language, it is obviously much, much easier than reverse engineering it. With that said, given the age of the code in question, it would probably make more sense to keep the interesting core bits that talk to hardware and wrap it with a current, modern UI using modern APIs.
What makes lots of industrial stuff particularly problematic is that even if you have the source code for your bits, it often uses some closed-source compiler/uploader toolchain that only runs on ancient hardware/OSes. In an ideal world, obtaining copyright or patent protection would require making the source code available either publicly or in escrow so that when the company goes away, people who own hardware that depends on it can maintain it themselves, but I digress.
I think the word you were looking for is "metastatic". All cancer is, by definition, malignant. That's the difference between cancer and a benign tumor or nodule.
No, the solution is to upgrade your PLCs and other hardware to more modern replacements that can be controlled by a modern computer. That doesn't mean replacing the industrial equipment, just its interface to the outside world.
CNC? Really? That's just about the most trivial thing you could pick. For many CNC needs, you could buy off-the-shelf control boards, plug them into a modern computer running a modern OS and modern CAD software, do some configuration, and you're done. The hard part is going to be updating the file format to be compatible, and that's still likely to be trivial.
No, it starts getting fun when you're talking about hundreds or even thousands of sensors and valves in a chemical plant that covers thousands of acres, all of which talks using an ancient protocol to software that only runs on 16-bit DOS. That's when it gets fun, because you actually have to write custom software for all of those sensors and valve controllers, on top of new enough hardware that you can usefully talk to it using a modern OS. And then you have to deploy the new setup in such a way that both old and new systems can run in parallel (ideally in lockstep) so that you can then verify that the new setup behaves identically to the old one over an extended period of time before disabling the old setup and letting the new one start running the show, so to speak. But even in that extreme example, you're still just replacing the PLCs, not the whole chemical plant.
The industrial equipment, realistically speaking, should run itself using PLCs or other hard-realtime systems. The Windows box typically is just a way of updating the software and/or sending new sets of instructions to it. So even if Windows 10 sucks at realtime (which it probably does), that's mostly moot, because it would typically be used as a glorified field programmer, not as an industrial system per se. At least one would hope....
There are 32-bit ASR-33 terminal emulators available out there. And if they're still running ancient systems for controlling their PLCs, they're running on borrowed time before malware takes over those systems and causes millions of dollars in damage or worse (e.g. StuxNet). Legacy systems written decades ago simply are not designed for the world we live in today, and it is fundamentally unsafe to continue using software written so far back, period. We're at least a decade past the point where the risk of not upgrading that sort of software exceeded the risk of replacing the software, and anybody who says otherwise hasn't fully thought through the risks.
Besides, a properly executed transition is amazingly safe. I've had conversations with a former coworker whose father was doing exactly that about five years ago. Basically, you start out by running the old and new systems in parallel, with the new software in a report-only mode. Then you compare the data reported from both systems and compare what actions would have been performed in response to the signals from the newer system, and you flag any places where those decisions differ. Then you analyze those differences and fix the software. Eventually, after running for some reasonable number of weeks/months/years with no observed differences, you conclude that the old software is not necessary, you switch to allow the new software to control things, and then you tear down the old software so that its security issues can cause no further harm. It's just like any other deployment of updated programming for one of those pieces of equipment, only on a bigger scale, involving bigger changes, and probably some new hardware....
The bigger the risk, the longer it takes, obviously, but twenty-two years is an eternity.
I guarantee those presses and cutters have had mechanical maintenance over the years to keep them running, replacing parts, etc. Why should it still be running software that hasn't been touched in decades?
As for reverse engineering being expensive, that mistakenly assumes that each of these pieces of software is being used by exactly one company. If that were the case, they would have the source code, and they could upgrade it. If they don't, that means that they bought the software, and so did hundreds of other companies around the world. If it costs half a million dollars to reverse engineer the software and there are 500 companies, then we're talking about less money per company than the cost of buying a new machine to run the upgraded software on.
Yes, yes, there's still the issue of things like PLCs where you have the software that runs on them but not a 32-bit version of the software that uploads programming to them, and in those cases, it is a pain in the backside to replace the PLCs with new ones using the process I described above, but in the end, it is worth it to not be running ancient cruftware that could break at any minute.
More significantly, at some point in the not-too-distant future, I fully expect Intel to decide that emulating the 16-bit and 32-bit i386 ISA is a waste of copious amounts of valuable die space, and just cut out that feature entirely as part of a die shrink. And I would not be even slightly surprised if Apple's planned elimination of 32-bit support in OS X is in preparation for just such an optimization. If and when Intel does drop legacy mode, anybody still using 16-bit code will suddenly be racing against the clock to replace it before they find themselves unable to get replacement hardware should anything break. That's not a position that anyone should want to be in. Better to start planning for a replacement sooner when you can do so on your own terms.
You're either fundamentally missing the point or deliberately avoiding it. I can't tell which. All of those things, to the extent that they are still in use, are still in use because they are actively maintained. Nobody in their right minds is running a 40-year-old version of UNIX. They're running a recent build of Linux or OS X or whatever.
And when you say that they still support software written four decades ago, you're grossly overstating things. For example, although ostensibly you could compile and run a properly written 40-year-old piece of UNIX software today, you would at an absolute minimum have to recompiling it, because A. modern UNIX systems don't even run on the same CPUs as UNIX systems from 40 years ago, and B. even if they did, modern UNIX systems don't even have the same set of system calls under the hood; they use 64-bit system calls with 64-bit inodes, 64-bit size_t and off_t, yada, yada, yada.
And the reality is that the vast majority of software from forty years ago won't even compile because of backwards-incompatible changes in header file names, compiler behavior, etc. You end up making at least minor changes before you can even start running it.
Being able to tweak, compile, and run 25-year-old source code is fundamentally different from being able to run a 25-year-old binary unmodified. Nobody in their right minds should be doing the latter, because supporting such a model basically requires that all OS improvements grind to a halt.
Not necessarily. A sign could get hit by a car and bent in such a way that it appears to affect the wrong road. But yes, in general, you're correct.
At some point, you have to start asking whether the 16-bit app support exists because of the legacy apps or whether the lack of 32-bit versions of those apps is because the 16-bit app support exists.
To put some hard numbers on this, Windows 95 brought 32-bit support to the platform in 1995. So all the 16-bit software out there is 22 years old. Continuing to maintain an entire operating system platform to support software that was written before this year's college grads were even born is just plain insane. That's way too much effort for what should be almost zero benefit.
Killing support for 16-bit software will force the manufacturers, assuming they are even still in business after more than two decades, to update their software to something remotely current. And if the manufacturers no longer exist, then if there's still enough value in the software, someone will take the time to reverse engineer it and write a 32-bit version, or write code that translates the old data files to work with a modern app, or write modern drivers for old hardware or whatever. And if there isn't enough value in that software, it will wither and die. And that's okay.
That said, it could reasonably be argued that they should have done this fifteen years ago, and that at this point, so many of the companies have ceased to exist that the economic impact will be huge. If that is the case, then the right fix is to run a twenty-five-year-old copy of Windows 3.1 in a VM with just enough hardware access to do the job, then walk away.
Let's not waste time focusing on an obvious joke.
That was precisely my first thought when I saw this story. Apparently the UK does value human rights after all.
That depends on how the computer is programmed. One could presumably change the failure mode so that it continues without changing anything until it gets valid data, which would have probably prevented the disaster. Or one could make the failure mode be an emergency descent, which would at least have avoided the stall, in all likelihood, and maybe avoided the crash, too. And a computer could ostensibly use other data like GPS to determine its ground speed and altitude, and use that data as a crude estimation of air speed in the absence of proper data, which is something a person isn't likely to think to do in such a crisis, much less be able to do the computation properly.
In other words, it's hard to say what the computer could or could not have done. A computer might have done much worse, but if they anticipated the situation when constructing the training data, it would probably have done much better. Either way, once the model is trained on such a scenario, it would almost certainly do better.
The three most likely reasons are:
Give them enough time around airline passengers and they will.... :-D
That's easy. Treat it like a long-term problem. A hard drive lasts, on average, 3 years. That's $150 per TB, which is more than the cost of 8 TB of storage. Assuming you need 8 TB of backup capacity (and really, if you don't have at least a terabyte or two of data, why aren't you using an iPad?), that means $1200 over three years. For that, you can buy eight or ten 8 TB drives. But to make the math easier, buy six.
Back up everything onto one drive, then clone the backup drive to the other five. Next, take five of the drives and store them at work, friends' houses, etc. Every two months, take your current backup drive and swap it with one of those five, proceeding to swap out each drive in a consistent order.
Now, you have better off-site storage than Amazon provides, because your data probably only exists in at most one spot with RAID redundancy at Amazon versus seven independent copies with this approach. And in the worst case, you only lose two months' work. While you're at it, you can use a cheaper tier of cloud backup software to maintain backups of any files modified in the last five months or so, automatically purging changes after about five months or so.
Or not. Whatever. Either way, $50 per terabyte is about an order of magnitude over cost. That's a high price to pay just to have it online and spinning all the time.
Try taking Southwest with kids. The inability to guarantee seating next to your traveling companions makes Southwest a major hassle, and even though sometimes people are willing to swap around to help you out, there's no guarantee that your kids/spouse won't end up twenty rows behind you.
The first airline that splits the difference between preassigned seating and free-for-all will get a lot of business—choose aisle/center/window/don't care; choose front/back/middle/don't care, and rank those two factors plus sitting near your traveling companions in order of preference. Provide info about whether you expect to bring an overhead bag to allow even distribution. Then compute the final seating arrangement right before boarding passes become available by evaluating those weighted constraints and resolving any otherwise unresolvable conflicts in favor of the person who bought a ticket first. That way, when you have a family of three, they'll end up grouped together by bumping the person who requested a window seat back just one row to the same row with somebody who chose an aisle seat (or vice versa), and that all happens before you board.
The problem is, two hours in the air comes to 750 miles, but unless there's a direct flight, half of your travel is probably in the wrong direction, and you have layovers during which you're just sitting there.
For example, suppose you want to travel from Nashville to Daytona Beach. By car, the trip is about 10 hours. By plane, you get to the airport and wait at least an hour. Southwest has the only direct flight, so if you don't want to be packed into a cattle car, you'll have a stopover in Atlanta. So you spend an hour and 10 minutes for that flight, followed by a 1.5 hour layover, then another 1.5-hour flight to Orlando.
After five hours and ten minutes, you get to the airport in Orlando and spend about an hour waiting for luggage, getting a car from the car rental place, and getting out of the parking garage. Then you drive backwards towards your destination for another hour. So it took you 7 hours and 10 minutes instead of a 10-hour drive, but for that ~28% reduction in time, you've spent a couple hundred bucks per person plus over a hundred bucks per day for a car rental, and you're still stuck driving an unknown vehicle instead of your own.
No, they aren't. In fact, it is illegal to transport even Lithium ion batteries in the cargo hold of an aircraft under current FAA regulations, precisely because the halon fire suppression system inside the cargo hold is not particularly effective at putting out lithium fires, whereas there are means of suppressing a lithium fire in the cabin of an aircraft as long as a human being can get to the fire in time. Thus, the general consensus among experts is that a Lithium fire is considerably safer in the cabin than in the cargo hold.
Why is the TSA deliberately trying to make air travel less safe?