Almost solved. Any app that supports independent touches on particular parts of the screen still won't be fully usable (e.g. on-screen pianos). Unless, of course, this means Apple is finally building a laptop with a touchscreen.
To be fair, that is running CocoaTouch compiled natively for x86_64. I would assume this would have an ARM emulator (until everyone had recompiled and shipped their iPad apps to contain an x86 target)
Well, they could do that, but why would Apple spend months of effort building a sufficiently fast emulator, just so users can run ancient iOS apps that nobody cares enough about to maintain? If they cared about keeping old apps running without recompiling, we would still be able to run 32-bit iOS apps on iOS itself. Besides, they've already culled most of those old apps, which means that almost everything that you can download from the iOS App Store today is properly maintained.
No, if they do this, I would imagine it will consist of:
Tweaking Xcode so that universal builds include a simulator slice.
Removing all device-only restrictions that prevent using certain features in the simulator (and adding macOS support for the features, where necessary).
Adding code to the Mac App Store to make it talk to the iOS App Store, showing only apps that have a simulator slice.
Modifying the iOS App Store to not reject binaries that contain a simulator slice.
Modifying the simulator and underlying iOS bits so that you can have multiple apps running in multiple windows, sharing underlying storage, ideally with each app having its own menu bar and showing up independently in Command-Tab/Dock/*.
Optionally adding menu bar classes to iOS so that iOS apps can modify their menu bar when running on Macs, and optionally making that available on actual iOS devices as well.
Telling developers to rebuild and resubmit their apps.
And the problem of not having x86_64 simulator slices will take care of itself within three months without having to develop an arm64 emulator. The only way I could see Apple building any sort of emulator would be if they decided to do the reverse—allowing Mac apps to run on iPad Pro.
By a fairly large margin. They spent two entire years doing basically nothing but fixing bugs. It was a two-year, essentially zero-feature release cycle. If Apple did that with iOS and OS X again, they would end up with an amazingly solid OS on which to build new features. Of course, it remains to be seen whether they'll have the courage to delay their annual release cycle for even half a year, much less two years.
That's the way people who worked at Apple through the transition often jokingly described it. The current macOS is, despite your protestations, almost entirely derived from NeXT + new code. It shares almost no code with Mac OS 9 and earlier. Basically, NeXT acquired Apple's name and marketing department, and then slowly integrated Apple's engineers over the course of half a decade.
Regarding your five points specifically:
1. (Perot) Out of NeXT's board, Apple kept the ones with actual computer industry experience (SJ and Avie). Perot was just a financier, which Apple had no need for at the time.
2. (Marketing) Why would they change marketing focus? Apple was actually making money. The value of the reverse acquisition was in the Apple name and marketing, rather than in the tech.
3. (Display Postscript) Nor does it use any of the windowing and display management code from Mac OS 9. OS X's WindowServer tech was a ground-up rewrite, AFAIK.
4. Apple stopped being monochrome-only with the Macintosh II, way back in 1987, almost a decade before the NeXT reverse acquisition. The last monochrome Mac was the Classic II, which was discontinued in 1993, about three years before the NeXT reverse acquisition.
5. Carbon is only still around because of Adobe and a few other holdouts. Otherwise, it would have been gone by 10.2 or so. It was always intended to be temporary. As it stands, all but a few low-level bits of Carbon are unavailable in 64-bit apps, and will go away when 32-bit support goes away. Either way, using Carbon as proof that NeXT engineering didn't completely take over Apple's engineering is approximately equivalent to saying that two cars are the same because they use the same cupholders.:-)
Well, yeah, there's that. But it would still probably be somewhere in or near California even if they had to build one from scratch. Building Teslas in Detroit wouldn't make much sense (except, perhaps, from an ease-of-poaching perspective).
Hey dude, you might want to revisit your basic math & physics:
You might want to revisit your basic reading comprehension.
Yes, but that relationship isn't strictly linear with respect to volume
a commensurate increase in thickness results in ZERO change in ratio of active volume to total volume.
You're the one claiming that the ratio of active volume to total volume must be constant. I said that this isn't true, and proved it with real-world examples of hardware where your claims don't hold true even in the consumer space.
inane volume data of AAA,D
wasted space
Obviously wasted, because you didn't bother to read it.
bigger cells typically have slightly more power per unit volume than smaller ones
at least try to get power and energy right
Meh. Your pedantry doesn't impress me.
For a cell that's going to sit inside a permanent pack for the rest of its life and won't be individually handled after assembly, the need for any sort of mechanical strength is even less
has no relevance on the fact that larger form factor require thicker casing
Repeating inaccurate information over and over doesn't make it true.
Less government, more free market is only helpful when there's competition in the free market. Back in the 3G days and before, there was competition (GSM/TDMA, CDMA, DAMPS). 4G saw all the carriers adopting LTE.
You're confusing market fragmentation with competition. The two are actually mutually exclusive. Using the same standard means you can buy one phone and change carriers freely at any time, which is a prerequisite to any meaningful competition.
There was a small amount of competition at the chipset manufacturing level, but that doesn't translate to competition at the service provider level. That might in theory make phones cheaper (but not in practice, given that very little of a phone's cost is the cellular chipset), but it certainly didn't make cellular providers any less horrible.
Meaningful competition between cellular carriers only really started when Apple's phones (and, to a lesser extent, Samsung and others) stopped being subsidized (eliminating one cause of carrier lock-in) and started working well enough across the various carriers (eliminating the other cause). That's when we started seeing the return of unlimited data plans, for example.
Close. It will be built at government expense and access will be licensed only on a nationwide basis, for an amount that barely covers the infrastructure costs over a period of time. This ensures that all four of the major cellular providers can afford to use it, but that the price for access remains out of reach for smaller companies, who will be forced to continue being MVNOs for one of the four major cellular providers.:-)
Which commands to get it to grab the new credentials? I've been struggling with this exact problem. I have letsencrypt set up with auto-renewal, the certs added to the keychain, but I can't for the life of me get it to use the credentials. Was considering dropping the built-in web service and going with a self-contained MAMP install.
What I'm doing is this:
openssl pkcs12 -export -inkey/etc/letsencrypt/new_server.key -in "$FILEPATH" -out "temp.p12" -passout pass:pass
sudo/usr/bin/security import "temp.p12" -f pkcs12 -k/Library/Keychains/System.keychain -P "pass" -T \ /Applications/Server.app/Contents/ServerRoot/System/Library/CoreServices/ServerManagerDaemon.bundle/Contents/MacOS/servermgrd
sleep 60 # Allow time for the certificate to actually get installed, because the security tool lies.
sudo serveradmin stop web
sudo serveradmin start web
On my actual system, I have the "security" command wrapped in a shell script so that I can have a sudo policy for the letsencrypt user that allows running only that script, rather than arbitrary use of/usr/bin/security. (I don't allow third-party code to run as root unless absolutely necessary, and letsencrypt certainly doesn't rise to that level, so it gets its own low-privilege user account.) But it should work the same either way.
IIRC, the critical parts are allowing some extra time before restarting the web server and using Apple's tool to do it instead of apachectl.
No, the managing computers and users is not the "bit nobody uses", its the whole damn point of OSX server. Almost everywhere I've seen OSX server deployed, its to provide directory and authentication services to macs on a corporate network. Its basically a mac AD-like domain host.
The potential market for easily configured web serving includes hobbyists. The potential market for AD-like domain hosts does not. So if that really is the most commonly used feature, it can only be because Apple epically failed to deliver on the other functionality, either price-wise or quality-wise.
You run Apache on a Mac?! For god's sake, why?! You can get fully configurable hosted versions for less than the monthly depreciation of a Mac mini, and the free completely automated sandbox/deploy, A/B systems out there remove any barrier on that side.
Two words: disk space. Hosting companies like to charge through the nose for it.
It's a server app, with all the server functionality removed. Staring at this list, I'm struggling to think of anything that wasn't removed. Apparently, they kept the user and device management — the part that for 99% of Server.app users is the least useful, but admittedly also the only part that's at all Mac-specific.
That said, Server.app sucks. Always has. The Apache functionality has been a constant struggle even to get it to do basic things like update certs programmatically (they bizarrely store them in the keychain, then require some weird custom commands to force the server to grab the new credentials, and they're basically undocumented as far as I can tell). And heaven help you if you try to import any existing Apache config. You're pretty much guaranteed to end up with something nonfunctional.
The only reason I even install Server.app at all is so that the software updates for Apache and BIND happen without me having to pay attention to the CERT mailing lists. And even then, I don't let the app configure *anything*, using a separate launchd plist with a different identifier and a separate config file so that none of Apple's code has any effect on the actual operation of the server.
I guess with this change, there's no reason to bother installing it ever again, since I don't manage a network of users. This, of course, also means I have one less reason to keep using Macs as servers, but I digress.
Except the bigger form factor generally require a commensurate increase in casing thickness to attain the same structural strength (unless you propose that the AT&T Cowboys Stadium use the same tent poles for structure as you used on your camping trip).
Yes, but that relationship isn't strictly linear with respect to volume even for cells designed for general consumer use:
AAA battery: 3.9 mL, 1.3-1.8 wH
D cell: 55.8 mL (14.3x), 18-27 wH (13.85-15x)
It's close, but IIRC, bigger cells typically have slightly more power per unit volume than smaller ones, assuming all else is equal. And again, that's for consumer-grade cells, designed to be handled roughly by humans.
For a cell that's going to sit inside a permanent pack for the rest of its life and won't be individually handled after assembly, the need for any sort of mechanical strength is even less. After all, most modern personal electronic devices these days use thin, soft pouches for their batteries, because the device itself provides adequate protection against damage by itself, without the need for any sort of shell at all.:-)
Besides, AFAIK, Musk didn't say that the batteries were more dense purely because the cells were bigger. He just said that they were bigger and more dense. Technology improves.:-)
Yeah. As soon as they ask for that, a sane person should probably ask, "If you don't know who I am, I guess you can't kill me, then," and ignore all further emails.
WARNING: SARCASM AHEAD. DO NOT ACTUALLY DO ANYTHING SUGGESTED BELOW.
That said, if you want a response that would be far more entertaining (for anyone observing from a sufficiently safe distance), one could always up the ante. For example:
Scammer: For $2,800, I'll give you the information about the person who hired me to kill you.
Victim: I'll give you [some significantly larger amount], under one condition: First you have to bring me the severed head of the person who hired you to kill me.
This is likely to provoke one of two reactions: A. They're the FBI. You spend a few months in a jail while your lawyers smack them around for entrapment, and if you're really unlucky, you spend the rest of your life with a cellmate named Bubba. B. They think you're the FBI. They flee to another country that lacks an extradition treaty with the United States and never contact you again.
However, there is always the risk that you might come home one day to find a head-sized box on your porch. So one should probably have a passport ready before contemplating such a response, along with a plane ticket to a country that lacks an extradition treaty with the United States.:-D
The truck will probably be roadable for another couple of years - I got rid of it because of towing requirements. That's 20 some odd years for an ICE - what more do you need?
For it to pass a California smog check.:-) It's not the engines that are the big problem (usually). It's all the emissions crap that they have to tack on—vacuum lines that get clogged by carbon deposits and cause the engine to run lean, O2 sensors that fail, and so on.... And all of those things, if bad enough to be detected by the computer, will make you fail the smog test. And at some point, you realize that every repair costs half the value of the car, and it is false economy.
No other major manufacturer has these types of delays for new models. They simply make the cars, build them, and sell them. Maybe they don't have a color or trim available. Consumers deal.
Tesla's problem is mostly a lack of $$$. They announce cars before they're ready to build them, and they do that because they have to start bringing in revenue, or else they won't have the money to do the tooling to build the cars. Were it a larger car company, they would simply wait until all of their manufacturing capacity was ready to produce that car, and then announce it. If there were delays, you would never know it, because they have enough cash reserves that they don't have to start booking revenue for each new model while they're still building the plant to mass-manufacture it.
There's nothing magic about this. The reason for the higher density is that some portion of each cell is necessarily used for the casing to provide physical support for the structures inside. The bigger the cell (in either direction), the lower the percentage of its volume that is wasted on the casing, and thus, the higher the cell's energy density is (by volume), assuming all else is equal.
You can sell these cells for consumer electronics, too; with large cells, your potential shrinks.
Not really. Most consumer electronics haven't used round cells for well over a decade. The energy density (by volume) of round cells is just too low, so pretty much the entire industry uses lithium polymer soft packs now. But for automobiles, that doesn't matter as much, and round cells are cheap because nobody wants them anymore, so why not?:-)
Or at least swallow the watch that Kif gave her.
Almost solved. Any app that supports independent touches on particular parts of the screen still won't be fully usable (e.g. on-screen pianos). Unless, of course, this means Apple is finally building a laptop with a touchscreen.
Well, they could do that, but why would Apple spend months of effort building a sufficiently fast emulator, just so users can run ancient iOS apps that nobody cares enough about to maintain? If they cared about keeping old apps running without recompiling, we would still be able to run 32-bit iOS apps on iOS itself. Besides, they've already culled most of those old apps, which means that almost everything that you can download from the iOS App Store today is properly maintained.
No, if they do this, I would imagine it will consist of:
And the problem of not having x86_64 simulator slices will take care of itself within three months without having to develop an arm64 emulator. The only way I could see Apple building any sort of emulator would be if they decided to do the reverse—allowing Mac apps to run on iPad Pro.
Yeah, but Dr. Who got the last room.
By a fairly large margin. They spent two entire years doing basically nothing but fixing bugs. It was a two-year, essentially zero-feature release cycle. If Apple did that with iOS and OS X again, they would end up with an amazingly solid OS on which to build new features. Of course, it remains to be seen whether they'll have the courage to delay their annual release cycle for even half a year, much less two years.
*shrugs*
That's the way people who worked at Apple through the transition often jokingly described it. The current macOS is, despite your protestations, almost entirely derived from NeXT + new code. It shares almost no code with Mac OS 9 and earlier. Basically, NeXT acquired Apple's name and marketing department, and then slowly integrated Apple's engineers over the course of half a decade.
Regarding your five points specifically:
1. (Perot) Out of NeXT's board, Apple kept the ones with actual computer industry experience (SJ and Avie). Perot was just a financier, which Apple had no need for at the time.
2. (Marketing) Why would they change marketing focus? Apple was actually making money. The value of the reverse acquisition was in the Apple name and marketing, rather than in the tech.
3. (Display Postscript) Nor does it use any of the windowing and display management code from Mac OS 9. OS X's WindowServer tech was a ground-up rewrite, AFAIK.
4. Apple stopped being monochrome-only with the Macintosh II, way back in 1987, almost a decade before the NeXT reverse acquisition. The last monochrome Mac was the Classic II, which was discontinued in 1993, about three years before the NeXT reverse acquisition.
5. Carbon is only still around because of Adobe and a few other holdouts. Otherwise, it would have been gone by 10.2 or so. It was always intended to be temporary. As it stands, all but a few low-level bits of Carbon are unavailable in 64-bit apps, and will go away when 32-bit support goes away. Either way, using Carbon as proof that NeXT engineering didn't completely take over Apple's engineering is approximately equivalent to saying that two cars are the same because they use the same cupholders. :-)
Any chance it was a PAL version of the game console, where the clock divider is different, and thus it shows fewer frames per second?
*shrugs*
This strategy worked well for Apple/NeXT, where NeXT bought Apple for negative $429 million. I'd imagine Icahn would approve. :-)
Well, yeah, there's that. But it would still probably be somewhere in or near California even if they had to build one from scratch. Building Teslas in Detroit wouldn't make much sense (except, perhaps, from an ease-of-poaching perspective).
Hey dude, you might want to revisit your basic math & physics:
You might want to revisit your basic reading comprehension.
Yes, but that relationship isn't strictly linear with respect to volume
a commensurate increase in thickness results in ZERO change in ratio of active volume to total volume.
You're the one claiming that the ratio of active volume to total volume must be constant. I said that this isn't true, and proved it with real-world examples of hardware where your claims don't hold true even in the consumer space.
inane volume data of AAA,D
wasted space
Obviously wasted, because you didn't bother to read it.
bigger cells typically have slightly more power per unit volume than smaller ones
at least try to get power and energy right
Meh. Your pedantry doesn't impress me.
For a cell that's going to sit inside a permanent pack for the rest of its life and won't be individually handled after assembly, the need for any sort of mechanical strength is even less
has no relevance on the fact that larger form factor require thicker casing
Repeating inaccurate information over and over doesn't make it true.
It's all f**ked. Thanks for noticing.
You're confusing market fragmentation with competition. The two are actually mutually exclusive. Using the same standard means you can buy one phone and change carriers freely at any time, which is a prerequisite to any meaningful competition.
There was a small amount of competition at the chipset manufacturing level, but that doesn't translate to competition at the service provider level. That might in theory make phones cheaper (but not in practice, given that very little of a phone's cost is the cellular chipset), but it certainly didn't make cellular providers any less horrible.
Meaningful competition between cellular carriers only really started when Apple's phones (and, to a lesser extent, Samsung and others) stopped being subsidized (eliminating one cause of carrier lock-in) and started working well enough across the various carriers (eliminating the other cause). That's when we started seeing the return of unlimited data plans, for example.
Close. It will be built at government expense and access will be licensed only on a nationwide basis, for an amount that barely covers the infrastructure costs over a period of time. This ensures that all four of the major cellular providers can afford to use it, but that the price for access remains out of reach for smaller companies, who will be forced to continue being MVNOs for one of the four major cellular providers. :-)
What I'm doing is this:
openssl pkcs12 -export -inkey /etc/letsencrypt/new_server.key -in "$FILEPATH" -out "temp.p12" -passout pass:pass /usr/bin/security import "temp.p12" -f pkcs12 -k /Library/Keychains/System.keychain -P "pass" -T \
/Applications/Server.app/Contents/ServerRoot/System/Library/CoreServices/ServerManagerDaemon.bundle/Contents/MacOS/servermgrd
sudo
sleep 60 # Allow time for the certificate to actually get installed, because the security tool lies.
sudo serveradmin stop web
sudo serveradmin start web
On my actual system, I have the "security" command wrapped in a shell script so that I can have a sudo policy for the letsencrypt user that allows running only that script, rather than arbitrary use of /usr/bin/security. (I don't allow third-party code to run as root unless absolutely necessary, and letsencrypt certainly doesn't rise to that level, so it gets its own low-privilege user account.) But it should work the same either way.
IIRC, the critical parts are allowing some extra time before restarting the web server and using Apple's tool to do it instead of apachectl.
The potential market for easily configured web serving includes hobbyists. The potential market for AD-like domain hosts does not. So if that really is the most commonly used feature, it can only be because Apple epically failed to deliver on the other functionality, either price-wise or quality-wise.
Two words: disk space. Hosting companies like to charge through the nose for it.
It's a server app, with all the server functionality removed. Staring at this list, I'm struggling to think of anything that wasn't removed. Apparently, they kept the user and device management — the part that for 99% of Server.app users is the least useful, but admittedly also the only part that's at all Mac-specific.
That said, Server.app sucks. Always has. The Apache functionality has been a constant struggle even to get it to do basic things like update certs programmatically (they bizarrely store them in the keychain, then require some weird custom commands to force the server to grab the new credentials, and they're basically undocumented as far as I can tell). And heaven help you if you try to import any existing Apache config. You're pretty much guaranteed to end up with something nonfunctional.
The only reason I even install Server.app at all is so that the software updates for Apache and BIND happen without me having to pay attention to the CERT mailing lists. And even then, I don't let the app configure *anything*, using a separate launchd plist with a different identifier and a separate config file so that none of Apple's code has any effect on the actual operation of the server.
I guess with this change, there's no reason to bother installing it ever again, since I don't manage a network of users. This, of course, also means I have one less reason to keep using Macs as servers, but I digress.
Yes, but that relationship isn't strictly linear with respect to volume even for cells designed for general consumer use:
AAA battery: 3.9 mL, 1.3-1.8 wH
D cell: 55.8 mL (14.3x), 18-27 wH (13.85-15x)
It's close, but IIRC, bigger cells typically have slightly more power per unit volume than smaller ones, assuming all else is equal. And again, that's for consumer-grade cells, designed to be handled roughly by humans.
For a cell that's going to sit inside a permanent pack for the rest of its life and won't be individually handled after assembly, the need for any sort of mechanical strength is even less. After all, most modern personal electronic devices these days use thin, soft pouches for their batteries, because the device itself provides adequate protection against damage by itself, without the need for any sort of shell at all. :-)
Besides, AFAIK, Musk didn't say that the batteries were more dense purely because the cells were bigger. He just said that they were bigger and more dense. Technology improves. :-)
Wait... power tools are considered electronics now? Did I miss a meeting?
Yeah. As soon as they ask for that, a sane person should probably ask, "If you don't know who I am, I guess you can't kill me, then," and ignore all further emails.
WARNING: SARCASM AHEAD. DO NOT ACTUALLY DO ANYTHING SUGGESTED BELOW.
That said, if you want a response that would be far more entertaining (for anyone observing from a sufficiently safe distance), one could always up the ante. For example:
Scammer: For $2,800, I'll give you the information about the person who hired me to kill you.
Victim: I'll give you [some significantly larger amount], under one condition: First you have to bring me the severed head of the person who hired you to kill me.
This is likely to provoke one of two reactions: A. They're the FBI. You spend a few months in a jail while your lawyers smack them around for entrapment, and if you're really unlucky, you spend the rest of your life with a cellmate named Bubba. B. They think you're the FBI. They flee to another country that lacks an extradition treaty with the United States and never contact you again.
However, there is always the risk that you might come home one day to find a head-sized box on your porch. So one should probably have a passport ready before contemplating such a response, along with a plane ticket to a country that lacks an extradition treaty with the United States. :-D
For it to pass a California smog check. :-) It's not the engines that are the big problem (usually). It's all the emissions crap that they have to tack on—vacuum lines that get clogged by carbon deposits and cause the engine to run lean, O2 sensors that fail, and so on.... And all of those things, if bad enough to be detected by the computer, will make you fail the smog test. And at some point, you realize that every repair costs half the value of the car, and it is false economy.
Tesla's problem is mostly a lack of $$$. They announce cars before they're ready to build them, and they do that because they have to start bringing in revenue, or else they won't have the money to do the tooling to build the cars. Were it a larger car company, they would simply wait until all of their manufacturing capacity was ready to produce that car, and then announce it. If there were delays, you would never know it, because they have enough cash reserves that they don't have to start booking revenue for each new model while they're still building the plant to mass-manufacture it.
Tesla Model Soylent 3 is people!
There's nothing magic about this. The reason for the higher density is that some portion of each cell is necessarily used for the casing to provide physical support for the structures inside. The bigger the cell (in either direction), the lower the percentage of its volume that is wasted on the casing, and thus, the higher the cell's energy density is (by volume), assuming all else is equal.
Not really. Most consumer electronics haven't used round cells for well over a decade. The energy density (by volume) of round cells is just too low, so pretty much the entire industry uses lithium polymer soft packs now. But for automobiles, that doesn't matter as much, and round cells are cheap because nobody wants them anymore, so why not? :-)