>which will always be the most suitable place for human habitation
Lets not make any assumptions - after a few million years of terraforming, Mars and Venus might be every bit as suitable - especially after being relocated to more hospitable orbits.
I worry about that last bit.
Planetary Systems are like fairly intradependent, gravity-wise. If we start messing with the orbits of a systems' planets, we might start a cascade-effect with the star and/or other planets in the system, that very well might start and/or accentuate "wobble" that we may or may not be able to stop/control.
Full disclosure: IANAA (I am not an Astrophysicist). But this does seem a fairly reasonable "worry".
Did you know the reason marijuana is illegal is because of the cotton industry didn't want the hemp industry to happen? Some guy told me that at a concert once. Blew my mind. Hemp is much superior to cotton. That is why people who smoke pot love hemp. They are intensely interested in material science.
With RS232, there is an entire UNIVERSE of cabling "fun" before you even get to software issues.
Problems which 99% of users never encountered. Only nerds ever had to deal with those problems, and what they got in return was a simple interface which often didn't require any drivers (since the operation was handled by the BIOS) and which could be cheaply implemented on any halfway decent microcontroller.
With USB, it comes down to "Do you have the right Driver?"
For the average user, so does serial — except they usually didn't need a driver for a serial peripheral. For the hobbyist, USB is a total PITA. It's not cheap or easy to implement, and with most microcontrollers you need an external crystal.
You're right that most users never had to deal with the problems of RS-232. That's because they just called-up their friendly neighborhood GEEK to figure it out FOR them!!!
Yes, I will heartily agree that USB is a PITA for the average hobbyist. But that's never what the target audience was, IMHO. But aren't there FTDI chips and drivers that take care of the hardware and driver nonsense for HID devices at least? I would imagine that's what 99% of hobbyists that want to interface with some USB device do these days.
He must have forgotten/s -- or else is in Advanced Selective Alzheimer's. Though... I may still have the old homemade null-modem cable I built to connect my Radio Shack Model 100 to a PC. Used it to dump text files back and forth so I could work on things while on the 2-hour commute bus ride in the Bay Area (yes, they were a thing even in the 1980s). And the M100 could easily handle 19200 while the PCs of the time were barely capable of doing 9600 without errors.
I still have my Model 102. Spectacular device for the time. Haven't turned it on in decades; but I can't bring myself to pitch it... Spent a LOT of damn money on Compu$erve CB on that thing, LOL!
What about a microswitch next to the SIM slot which can be triggered by a straightened paper clip and PHYSICALLY shuts off power to the battery?
That would require an intrusion into the case, kind of defeating the "no intrusions" design goal.
Plus they'll take the sim slot out next. It'll be embedded and you'll have to get it paired at a store. Will probably not be reversible or able to change number without a lot of time and a couple trips to the bank.
Doubt it; since Apple already sells unlocked versions of their phones, and has for some time.
They do already have a watchdog and use it, but that doesn't help if the kernel is still ticking over but the UI has frozen.
Gestures are janky, a magnet would allow anyone to reset your iPhone with a magnet and would break magnetic phone holders (which are awesome by the way).
Some phones have a squeeze sensor that works quite well now, maybe that could be used. But really you need a physical button that not only resets the phone but can put it into recovery mode. Since there is no USB^W lighting port any more it will have to have a wifi stack with TCP/IP, DHCP and some kind of bootloader, which means a brand new and much larger attack surface.
Meanwhile everyone else just fits a waterproof USB-C connector and waterproof headphone socket.
I am not surprised that Apple SoCs have a WatchDog subsystem. In fact, I would be surprised if they didn't. However, all that has to change to prevent the "lights are on, but nobody's home" (UI Frozen) is to change the way the WatchDog is "Petted", to make sure ALL of the software subsystems and Apps are "ticking over". Takes some planning; but it isn't impossible.
For example, In my early days as an embedded Dev., when dinosaurs roamed the earth, and all computers ran on kerosene, I created a system based on a small 6502-based SBC that controlled the soft-start and soft-stop of a 30 HP 480VAC "spindle" motor, plus the pneumatic "chuck" and brake, on a machine that did dynamic balancing of 4-ton (IIRC) 4 ft. diameter Flywheels for Caterpillar Earth Movers. At 1800 RPM, you simply cant afford to make a mistake about what the ACTUAL current machine-state is when a WatchDog Reset has occurred, lest you turn that flywheel into a gigantic, death-dealing frisbee!!! So yeah, you can make your WatchDog subsystem as simple, or as sophisticated, as needed. And if Apple designs a system that depends essentially exclusively on their WatchDog system being "unbreakably robust", I am confident they can step-up to that challenge without breaking a sweat.
Also, it isn't that hard to waterproof a short-travel momentary switch, like you find on the typical phone. Just have the "actuator" push on a flexible membrane that then pushes on a physical momentary switch on the other side of the membrane. Select your membrane material and design the actuator properly, and they will last past the service life of the phone. You can also use a Hall-Effect sensor, so there is no actual "flexing" membrane between actuator and "switch". That makes the switch assembly much more robust over time, at the expense of slightly higher per-unit cost.
Apple already has a well-developed and field-tested secure software update protocol for iOS devices that works over WiFi; so that part is a no-brainer. All you need is a permanent bootloader with a TIMEOUT, and enough Flash set-aside to hold both the old and new versions of Firmware; so that a failed Update process can be Restarted without resulting in a Bricked Device. But again, those are well-understood engineering challenges in the embedded world.
You're right, some other manufacturers CLAIM up to IP68 water-resistance depending on connectors with simple built-in O-Rings and such; but that only gets you so far when it comes to real-world protection (which really isn't THAT much when you factor-in transient pressure spikes caused by movement of the device while underwater). IMHO, Apple is going for a nice TV Ad where someone takes their iPhone scuba diving without a case, and can provide a real-world dust and water-resistance protection down to say, 30 m, with pressure spikes to 50 m, and essentially practically infinite dust-intrusion resistance (assuming you don't aim a beadblasting nozzle at the device). That can really only be done in a consumer-level device by eliminating all intrusions through the outer-enclosure. Yes, there are dive-watches etc. that have impressive water-resistance; but a fair amount of the cost and complexity of those things is devoted to making them that water-resistant. A
This reminds me of the joy (not!) we had when USB replaced RS232.
In "the old days", serial ports were pretty much idiot-proof, as long as you didn't have to screw with anything where dsr, dtr, cts, or rts actually mattered (besides maybe using a cable that connected one of them to ground). The universe of potential baudrates was small and finite (as a practical matter, nearly everything used 115200, 38400, 19200, 9600, 2400, 1200, or 300, with no parity, 8 bits, and 1 stop bit). After verifying that the cable was good, all you really had to do was iterate through the aforementioned 7 baudrates & there was a 98% chance one of them would work. Best of all, once you had the baudrate and bits/parity/stopbit settings right, the hardware literally worked the instant you connected the cable.
Then came USB, and everything went to hell. Drivers broke catastrophically every time Microsoft did a major Windows release. Flaky cables & poorly-designed (or excessively value-engineered) ports had endless, seemingly-random disconnects and dysfunction. And the inevitable lag between connecting a USB device & having it actually be operational made matters even worse. We traded a cheap, simple communications bus that was easy to configure and generally worked well for one that used cheaper hardware, augmented by extremely complicated software drivers that were barely understood by their own developers (most of whom depended upon proprietary vendor-supplied toolchains working literal black magic behind a curtain).
You remember RS232 a LOT more fondly than MOST people.
Case in Point: How many times have you seen an USB Breakout Box?
With RS232, there is an entire UNIVERSE of cabling "fun" before you even get to software issues. With USB, it comes down to "Do you have the right Driver?" You're just forgetting. And if you were a regular person, trying to hook up some random RS-232 peripheral, FORGET IT! Even with a simple 3 wire RS-232 interface, using XON/XOFF handshaking (or no handshaking at all) there was STILL the ambiguity regarding which particular pin (2 or 3) was being used for TXD and which for RXD. Yeah, you forget, alright...
Yes, simple serial comm. is FAR easier to implement than USB, with its book-long preamble and necessity for a Driver to get even the simplest setup going; which is why embedded Devs. Still use it for quickie Diagnostic Ports during Development; but that is in a system where the Developer already KNOWS everything about the system. Regular users typically don't have that level of insight; so for them, USB is MUCH easier (at least once they figure out which way to plug the connector in!)
But Just because Windows couldn't get their shit together on USB for years and years, doesn't mean the USB Standard, per se, was flawed. On Macs, for example, USB almost always "Just Worked", with the rarest of exceptions. You're right that USB on Windows was always (even up through XP, at least) a hell-hole, starting with "Make sure you Install the Driver BEFORE connecting..." (another problem Macs never had with USB). But again, that isn't the fault of USB, just Microsoft's inability to write software of any kind.
So, there are some methods that came to mind with about 30 seconds of thought. Think that Apple engineers can't come up with a dozen or more methods to accomplish this after a couple of weeks' working on it?
Some phones assign functions to squeezing the bezel itself:
I guess I should have spent a whole minute thinking about this, then, LOL! Just because there isn't an external physical button doesn't mean that you can't hide a pressure-sensitive switch inside the phone.
The fact of 'caught using' being a thing shows the real problem. Who cares what we use? Why it it so important to visibly be using a particular companies gadget?
When my phone or PMP had problems, USUALLY, the screen wasn't working. Eventually, I learned that by using actual buttons to RESET the thing, If I was lucky, I could get the screen working again. Later on, when I was checking out some older electronics I kept that had stopped working, I found that...even when it wasn't documented, I could quite often do a hard RESET by playing with a combination of buttons while powering it on and it would start working perfectly! Try as I might, I can't see how this can be done when all your controls are *on the screen*! The only other possibility is to remove the battery for awhile and let the unit/phone completely discharge and HOPE that it fixes it because if the screen is defective, there is no 'combination' of buttons to try as a last-ditch effort to save it. But, maybe that's what they are striving for so you have to send it in and pay a lot of money to get it working again?
Just because YOU can't think of a way, doesn't mean it isn't possible.
As an embedded Dev., a few possible methods come immediately to mind:
1. A "system monitor" ("Watchdog"), with a long-enough timeout to not false-trigger under heavy CPU load. If the main OS or an App goes off in the weeds for too long, (say, 10 secs.), the WatchDog would trigger a hardware Reset. This method requires no user intervention whatsoever, and is SOP in a lot of embedded designs. In fact, I would be VERY surprised if Apple's SoCs don't have this already.
2. A Hall-Effect sensor, similar to the "sleep" sensor that puts iPads to sleep when a magnet is brought in proximity to a certain location on the iPhone. This could be incorporated in the Charger. Kind of too kludgy for Apple; but there it is.
3. A small, fixed-code microcontroller, or a section of the main SoC, that would be responsible for interpreting a single, predetermined "gesture". This gesture would the. Trigger a hardware reset of the main SoC. This nicely fits in with Apple's design-language, in that it is triggered by a "swipe" of some kind. A hard coded confirmation dialog could be used to keep accidental triggering due to random swipes. Yes, this would only work if the screen and digitizer were reasonably intact; but let's face it, if the screen and digitizer are that scrogged, likely NO Reset-method would restore the unit to usability until that was fixed.
So, there are some methods that came to mind with about 30 seconds of thought. Think that Apple engineers can't come up with a dozen or more methods to accomplish this after a couple of weeks' working on it?
i am still realing from the 11.3 update the amount of DoneFudgedUp (DFU) device resets was a horrible and this after switching to iOS instead of droid because... "it just works" i guess the version of DFU reset will be to throw device against wall and repeat until destroyed.
Never had to do a DFU Reset on either of my 2 iPhones or iPad I've had over the years.
The most visited post on my website is instructions for rebooting a crashed iPod.
I can't imagine the iPhone is any better at not needing constant resets. Just today I had to force-reboot an iPad that had frozen on the home screen. I vaguely recall having to look up how to reboot someone's crashed iPhone X because they changed the method.
The point being that Apple's hardware is nowhere near stable enough not to have a method to force a reboot. I guess "wait for the battery to die" is going to become standard practice in the near future. I guess we finally learned why Apple refuses to put all-day batteries in their devices.
From what I have heard, due to fragmentation and zillions of versions in the field at any one time, Android is significantly harder to both Develop AND QA-for than iOS. YOMV (Your Opinion May Vary)...
Apple has hands-down the most performant mobile hardware and OS. That's not fanboyism; that's been shown year-after-year in benchmark after benchmark. Sorry! But what I was referring to is the fact that, the only reason Android's marketshare beats Apple's AT ALL is the proliferation of low-end cheap/free phones, although Apple has made some serious inroads in the past few years on that score.
I'm almost positive my cable-provider's Spectrum TV App will let me Rent Pay-per-View movies/programs for viewing on my iPhone/iPad, but running it just now, I might have to retract that statement. Hmm. I will have to do some more research...
No, I wasn't talking about Pirate-ware sites. I am not condoning those, either.
Cydia Impactor does not require a jailbroken iOS device. In fact, I think it will only work with a non-jailbroken device (but don't quote me on that).
I agree it isn't as easy as flipping a switch in Android; but it isn't horrible, either. Keep in mind that a Developer ID from Apple is FREE, unless you plan on Publishing to the App Store (that's when it is $99/yr). But here are the steps to install an.ipa file on iOS without jailbreaking, using Impactor:
I'd argue that there's some distinctions you're failing to make here.
The iOS Dev that has to dev for iOS because "that's where the money is" is probably referring to the market penetration of iPhones and iPads, not the Apple App Store which comes along with the iPhone.
Second, why do developers prefer to develop for iOS over Android? It's most definitely not because of the App Store. It's because there is only one manufacturer for iOS devices and only two product lines they have to worry about, the iPhone and the iPad. Both of which run the same or exceedingly similar versions of iOS. It significantly reduces the amount of QA they need to (or at least should) do when testing their apps.
Given the opportunity, I'd wager that many iOS Devs would jump at the chance to use a different distribution platform for their iOS apps. And, you know it's not just apps. Apple forbids any kind of third party application that even remotely resembles a marketplace. You can't rent or buy movies via the Amazon Movies or Google Play Movies Apps on an iPhone - you have to instead purchase/rent the content via another device or PC before you can stream it to your iOS device. No such restriction for iTunes though.
Valve's Steam Link App was booted off the App Store because it dared to display a list of games that looked like a marketplace - even though the games were all PC games and not software for iOS (I don't even think that they were available for purchase either).
All that does show that Apple is using their position as a hardware manufacturer and operating system developer to advantage their own software and entertainment marketplaces over those of it's competitors, either by completely preventing outside marketplaces from operating or by hampering the usage there of.
Unlike Microsoft however in the days when it got smacked around, Apple doesn't have near as much of the smart phone market share as MS had of the PC OS market share back then (which I believe was close to or over 90%). So you're not wrong in saying that consumers have a choice whether or not to buy an iOS or an Android device. But, this question is more about the developers choice of how to distribute their application. On iOS it's the App Store or not at all. So one can argue that the App Store has a 100% monopoly on distribution of iOS software. In other words, a developer that runs afoul of Apple's censors could find their app and themselves permanently banned from the App Store, flushing untold man hours down the toilet and leaving that developer with no alternatives. You also can't have anyone else start a new marketplace and say "Hey, I can provide a secure marketplace for transactions and ensure applications are trustworthy more efficiently than Apple, so I'm only going to charge a 10% commission".
First: Why not let fluffernutter speak for himself? I had seen his anti-Apple posts for quite some time, and believe me, he is not shy about posting his opinions. I don't think he needs his Mommy to fight his battles.
Having said that, I will go ahead and address your "argument".
According to everyone at Slashdot, Apple is just barely hanging-on with a miniscule market-share. So, why would Devs. be SO anxious to get their Apps placed in the iOS App Store, even though it may mean they have to invest in a Development Platform that they personally don't like to one degree or another?
I'll tell you why: Because, unlike the VAST majority of cheapskate Android owners (most of which are kids or poor adults) WON'T PAY for Apps, and only look to see what they can leech for Free, or PIRATE. Conversely, although iOS owners certainly enjoy a good, free App, they are MUCH, MUCH, MUCH more likely to reward Devs. that produce a useful App with their actual MONEY.
You will just argue that iOS owners are duped into purchasing Apps they don't like, because Apple doesn't have "Free Trials". Well, that argument ignores the fact that Apple has ALWAYS had a 14-day money-back for ALL p
Slashdot Mirror
So the Slashtard Apple-Hating Bitchfest-mobile will have some fodder upon which to spew their incessant hatred.
>which will always be the most suitable place for human habitation
Lets not make any assumptions - after a few million years of terraforming, Mars and Venus might be every bit as suitable - especially after being relocated to more hospitable orbits.
I worry about that last bit.
Planetary Systems are like fairly intradependent, gravity-wise. If we start messing with the orbits of a systems' planets, we might start a cascade-effect with the star and/or other planets in the system, that very well might start and/or accentuate "wobble" that we may or may not be able to stop/control.
Full disclosure: IANAA (I am not an Astrophysicist). But this does seem a fairly reasonable "worry".
Right. Nylon. Potheads are really interested in Nylon. And DuPont.
No, you vegetable.
DuPont had just invented Nylon. Nylon was used to make rope, like for Navy ships.
Hemp was the traditional fiber for Ropemaking.
DuPont worked behind the scenes to get Pot (and thus also Hemp) "demonized", and eventually made illegal.
1. No more Hemp for rope. No more competition for Nylon.
2. ???
3. DuPont Profits!
Don't believe me: Here's the first reference I could find to this almost forgotten bit of history:
http://www.ozarkia.net/bill/po...
From a chemical that comes from a plant that does not have any addictive qualities and a person can quit cold turkey if they want to? WOW!
Exactly.
And by first drug, they mean the first one since Marinol, the Schedule III medical grade THC right?
Marinol was completely symthetic; but yes.
Did you know the reason marijuana is illegal is because of the cotton industry didn't want the hemp industry to happen? Some guy told me that at a concert once. Blew my mind. Hemp is much superior to cotton. That is why people who smoke pot love hemp. They are intensely interested in material science.
DuPont and Nylon; but yes.
So then the Federal government should be forced to drop the Schedule C classification.
Schedule 1; but yes.
With RS232, there is an entire UNIVERSE of cabling "fun" before you even get to software issues.
Problems which 99% of users never encountered. Only nerds ever had to deal with those problems, and what they got in return was a simple interface which often didn't require any drivers (since the operation was handled by the BIOS) and which could be cheaply implemented on any halfway decent microcontroller.
With USB, it comes down to "Do you have the right Driver?"
For the average user, so does serial — except they usually didn't need a driver for a serial peripheral. For the hobbyist, USB is a total PITA. It's not cheap or easy to implement, and with most microcontrollers you need an external crystal.
You're right that most users never had to deal with the problems of RS-232. That's because they just called-up their friendly neighborhood GEEK to figure it out FOR them!!!
Yes, I will heartily agree that USB is a PITA for the average hobbyist. But that's never what the target audience was, IMHO. But aren't there FTDI chips and drivers that take care of the hardware and driver nonsense for HID devices at least? I would imagine that's what 99% of hobbyists that want to interface with some USB device do these days.
He must have forgotten /s -- or else is in Advanced Selective Alzheimer's. Though ... I may still have the old homemade null-modem cable I built to connect my Radio Shack Model 100 to a PC. Used it to dump text files back and forth so I could work on things while on the 2-hour commute bus ride in the Bay Area (yes, they were a thing even in the 1980s). And the M100 could easily handle 19200 while the PCs of the time were barely capable of doing 9600 without errors.
I still have my Model 102. Spectacular device for the time. Haven't turned it on in decades; but I can't bring myself to pitch it... Spent a LOT of damn money on Compu$erve CB on that thing, LOL!
How is that relevant? Instead of getting your sim and popping it in easy peasy you'd have to go down to the store and probably pay $200.
Why?
What about a microswitch next to the SIM slot which can be triggered by a straightened paper clip and PHYSICALLY shuts off power to the battery?
That would require an intrusion into the case, kind of defeating the "no intrusions" design goal.
Plus they'll take the sim slot out next. It'll be embedded and you'll have to get it paired at a store. Will probably not be reversible or able to change number without a lot of time and a couple trips to the bank.
Doubt it; since Apple already sells unlocked versions of their phones, and has for some time.
They do already have a watchdog and use it, but that doesn't help if the kernel is still ticking over but the UI has frozen.
Gestures are janky, a magnet would allow anyone to reset your iPhone with a magnet and would break magnetic phone holders (which are awesome by the way).
Some phones have a squeeze sensor that works quite well now, maybe that could be used. But really you need a physical button that not only resets the phone but can put it into recovery mode. Since there is no USB^W lighting port any more it will have to have a wifi stack with TCP/IP, DHCP and some kind of bootloader, which means a brand new and much larger attack surface.
Meanwhile everyone else just fits a waterproof USB-C connector and waterproof headphone socket.
I am not surprised that Apple SoCs have a WatchDog subsystem. In fact, I would be surprised if they didn't. However, all that has to change to prevent the "lights are on, but nobody's home" (UI Frozen) is to change the way the WatchDog is "Petted", to make sure ALL of the software subsystems and Apps are "ticking over". Takes some planning; but it isn't impossible.
For example, In my early days as an embedded Dev., when dinosaurs roamed the earth, and all computers ran on kerosene, I created a system based on a small 6502-based SBC that controlled the soft-start and soft-stop of a 30 HP 480VAC "spindle" motor, plus the pneumatic "chuck" and brake, on a machine that did dynamic balancing of 4-ton (IIRC) 4 ft. diameter Flywheels for Caterpillar Earth Movers. At 1800 RPM, you simply cant afford to make a mistake about what the ACTUAL current machine-state is when a WatchDog Reset has occurred, lest you turn that flywheel into a gigantic, death-dealing frisbee!!! So yeah, you can make your WatchDog subsystem as simple, or as sophisticated, as needed. And if Apple designs a system that depends essentially exclusively on their WatchDog system being "unbreakably robust", I am confident they can step-up to that challenge without breaking a sweat.
Also, it isn't that hard to waterproof a short-travel momentary switch, like you find on the typical phone. Just have the "actuator" push on a flexible membrane that then pushes on a physical momentary switch on the other side of the membrane. Select your membrane material and design the actuator properly, and they will last past the service life of the phone. You can also use a Hall-Effect sensor, so there is no actual "flexing" membrane between actuator and "switch". That makes the switch assembly much more robust over time, at the expense of slightly higher per-unit cost.
Apple already has a well-developed and field-tested secure software update protocol for iOS devices that works over WiFi; so that part is a no-brainer. All you need is a permanent bootloader with a TIMEOUT, and enough Flash set-aside to hold both the old and new versions of Firmware; so that a failed Update process can be Restarted without resulting in a Bricked Device. But again, those are well-understood engineering challenges in the embedded world.
You're right, some other manufacturers CLAIM up to IP68 water-resistance depending on connectors with simple built-in O-Rings and such; but that only gets you so far when it comes to real-world protection (which really isn't THAT much when you factor-in transient pressure spikes caused by movement of the device while underwater). IMHO, Apple is going for a nice TV Ad where someone takes their iPhone scuba diving without a case, and can provide a real-world dust and water-resistance protection down to say, 30 m, with pressure spikes to 50 m, and essentially practically infinite dust-intrusion resistance (assuming you don't aim a beadblasting nozzle at the device). That can really only be done in a consumer-level device by eliminating all intrusions through the outer-enclosure. Yes, there are dive-watches etc. that have impressive water-resistance; but a fair amount of the cost and complexity of those things is devoted to making them that water-resistant. A
This reminds me of the joy (not!) we had when USB replaced RS232.
In "the old days", serial ports were pretty much idiot-proof, as long as you didn't have to screw with anything where dsr, dtr, cts, or rts actually mattered (besides maybe using a cable that connected one of them to ground). The universe of potential baudrates was small and finite (as a practical matter, nearly everything used 115200, 38400, 19200, 9600, 2400, 1200, or 300, with no parity, 8 bits, and 1 stop bit). After verifying that the cable was good, all you really had to do was iterate through the aforementioned 7 baudrates & there was a 98% chance one of them would work. Best of all, once you had the baudrate and bits/parity/stopbit settings right, the hardware literally worked the instant you connected the cable.
Then came USB, and everything went to hell. Drivers broke catastrophically every time Microsoft did a major Windows release. Flaky cables & poorly-designed (or excessively value-engineered) ports had endless, seemingly-random disconnects and dysfunction. And the inevitable lag between connecting a USB device & having it actually be operational made matters even worse. We traded a cheap, simple communications bus that was easy to configure and generally worked well for one that used cheaper hardware, augmented by extremely complicated software drivers that were barely understood by their own developers (most of whom depended upon proprietary vendor-supplied toolchains working literal black magic behind a curtain).
You remember RS232 a LOT more fondly than MOST people.
Case in Point: How many times have you seen an USB Breakout Box?
With RS232, there is an entire UNIVERSE of cabling "fun" before you even get to software issues. With USB, it comes down to "Do you have the right Driver?" You're just forgetting. And if you were a regular person, trying to hook up some random RS-232 peripheral, FORGET IT! Even with a simple 3 wire RS-232 interface, using XON/XOFF handshaking (or no handshaking at all) there was STILL the ambiguity regarding which particular pin (2 or 3) was being used for TXD and which for RXD. Yeah, you forget, alright...
Yes, simple serial comm. is FAR easier to implement than USB, with its book-long preamble and necessity for a Driver to get even the simplest setup going; which is why embedded Devs. Still use it for quickie Diagnostic Ports during Development; but that is in a system where the Developer already KNOWS everything about the system. Regular users typically don't have that level of insight; so for them, USB is MUCH easier (at least once they figure out which way to plug the connector in!)
But Just because Windows couldn't get their shit together on USB for years and years, doesn't mean the USB Standard, per se, was flawed. On Macs, for example, USB almost always "Just Worked", with the rarest of exceptions. You're right that USB on Windows was always (even up through XP, at least) a hell-hole, starting with "Make sure you Install the Driver BEFORE connecting..." (another problem Macs never had with USB). But again, that isn't the fault of USB, just Microsoft's inability to write software of any kind.
So, there are some methods that came to mind with about 30 seconds of thought. Think that Apple engineers can't come up with a dozen or more methods to accomplish this after a couple of weeks' working on it?
Some phones assign functions to squeezing the bezel itself:
https://www.theverge.com/2017/...
Good point!
I guess I should have spent a whole minute thinking about this, then, LOL!
Just because there isn't an external physical button doesn't mean that you can't hide a pressure-sensitive switch inside the phone.
Doesn't the SIM slot already intrude into the case?
For now. I heard they were going to some sort of virtualized "SIM Card".
The fact of 'caught using' being a thing shows the real problem. Who cares what we use? Why it it so important to visibly be using a particular companies gadget?
Awww! Sounds like somebody's jealous...
We can begin to see the death of a brand and company.
In honesty, I'd love to see Apple fall back into obscurity. Their products suck and are over priced.
Then don't buy them. Simple as that.
The only Apple product I own is the White Album.
Careful! You'll trigger Yoko to file another decades-long frivolous lawsuit!
What about a microswitch next to the SIM slot which can be triggered by a straightened paper clip and PHYSICALLY shuts off power to the battery?
That would require an intrusion into the case, kind of defeating the "no intrusions" design goal.
When my phone or PMP had problems, USUALLY, the screen wasn't working. Eventually, I learned that by using actual buttons to RESET the thing, If I was lucky, I could get the screen working again.
Later on, when I was checking out some older electronics I kept that had stopped working, I found that...even when it wasn't documented, I could quite often do a hard RESET by playing with a combination of buttons while powering it on and it would start working perfectly!
Try as I might, I can't see how this can be done when all your controls are *on the screen*! The only other possibility is to remove the battery for awhile and let the unit/phone completely discharge and HOPE that it fixes it because if the screen is defective, there is no 'combination' of buttons to try as a last-ditch effort to save it.
But, maybe that's what they are striving for so you have to send it in and pay a lot of money to get it working again?
Just because YOU can't think of a way, doesn't mean it isn't possible.
As an embedded Dev., a few possible methods come immediately to mind:
1. A "system monitor" ("Watchdog"), with a long-enough timeout to not false-trigger under heavy CPU load. If the main OS or an App goes off in the weeds for too long, (say, 10 secs.), the WatchDog would trigger a hardware Reset. This method requires no user intervention whatsoever, and is SOP in a lot of embedded designs. In fact, I would be VERY surprised if Apple's SoCs don't have this already.
2. A Hall-Effect sensor, similar to the "sleep" sensor that puts iPads to sleep when a magnet is brought in proximity to a certain location on the iPhone. This could be incorporated in the Charger. Kind of too kludgy for Apple; but there it is.
3. A small, fixed-code microcontroller, or a section of the main SoC, that would be responsible for interpreting a single, predetermined "gesture". This gesture would the. Trigger a hardware reset of the main SoC. This nicely fits in with Apple's design-language, in that it is triggered by a "swipe" of some kind. A hard coded confirmation dialog could be used to keep accidental triggering due to random swipes. Yes, this would only work if the screen and digitizer were reasonably intact; but let's face it, if the screen and digitizer are that scrogged, likely NO Reset-method would restore the unit to usability until that was fixed.
So, there are some methods that came to mind with about 30 seconds of thought. Think that Apple engineers can't come up with a dozen or more methods to accomplish this after a couple of weeks' working on it?
i am still realing from the 11.3 update the amount of DoneFudgedUp (DFU) device resets was a horrible and this after switching to iOS instead of droid because... "it just works"
i guess the version of DFU reset will be to throw device against wall and repeat until destroyed.
Never had to do a DFU Reset on either of my 2 iPhones or iPad I've had over the years.
The most visited post on my website is instructions for rebooting a crashed iPod.
I can't imagine the iPhone is any better at not needing constant resets. Just today I had to force-reboot an iPad that had frozen on the home screen. I vaguely recall having to look up how to reboot someone's crashed iPhone X because they changed the method.
The point being that Apple's hardware is nowhere near stable enough not to have a method to force a reboot. I guess "wait for the battery to die" is going to become standard practice in the near future. I guess we finally learned why Apple refuses to put all-day batteries in their devices.
You're either a liar, or extremely unlucky.
From what I have heard, due to fragmentation and zillions of versions in the field at any one time, Android is significantly harder to both Develop AND QA-for than iOS. YOMV (Your Opinion May Vary)...
Apple has hands-down the most performant mobile hardware and OS. That's not fanboyism; that's been shown year-after-year in benchmark after benchmark. Sorry! But what I was referring to is the fact that, the only reason Android's marketshare beats Apple's AT ALL is the proliferation of low-end cheap/free phones, although Apple has made some serious inroads in the past few years on that score.
I'm almost positive my cable-provider's Spectrum TV App will let me Rent Pay-per-View movies/programs for viewing on my iPhone/iPad, but running it just now, I might have to retract that statement. Hmm. I will have to do some more research...
No, I wasn't talking about Pirate-ware sites. I am not condoning those, either.
Cydia Impactor does not require a jailbroken iOS device. In fact, I think it will only work with a non-jailbroken device (but don't quote me on that).
I agree it isn't as easy as flipping a switch in Android; but it isn't horrible, either. Keep in mind that a Developer ID from Apple is FREE, unless you plan on Publishing to the App Store (that's when it is $99/yr). But here are the steps to install an .ipa file on iOS without jailbreaking, using Impactor:
http://www.shoutpedia.com/use-...
Apparently, iOS 11 broke Impactor; but from what I read, it is all better now... ;-)
I'd argue that there's some distinctions you're failing to make here.
The iOS Dev that has to dev for iOS because "that's where the money is" is probably referring to the market penetration of iPhones and iPads, not the Apple App Store which comes along with the iPhone.
Second, why do developers prefer to develop for iOS over Android? It's most definitely not because of the App Store. It's because there is only one manufacturer for iOS devices and only two product lines they have to worry about, the iPhone and the iPad. Both of which run the same or exceedingly similar versions of iOS. It significantly reduces the amount of QA they need to (or at least should) do when testing their apps.
Given the opportunity, I'd wager that many iOS Devs would jump at the chance to use a different distribution platform for their iOS apps. And, you know it's not just apps. Apple forbids any kind of third party application that even remotely resembles a marketplace. You can't rent or buy movies via the Amazon Movies or Google Play Movies Apps on an iPhone - you have to instead purchase/rent the content via another device or PC before you can stream it to your iOS device. No such restriction for iTunes though.
Valve's Steam Link App was booted off the App Store because it dared to display a list of games that looked like a marketplace - even though the games were all PC games and not software for iOS (I don't even think that they were available for purchase either).
All that does show that Apple is using their position as a hardware manufacturer and operating system developer to advantage their own software and entertainment marketplaces over those of it's competitors, either by completely preventing outside marketplaces from operating or by hampering the usage there of.
Unlike Microsoft however in the days when it got smacked around, Apple doesn't have near as much of the smart phone market share as MS had of the PC OS market share back then (which I believe was close to or over 90%). So you're not wrong in saying that consumers have a choice whether or not to buy an iOS or an Android device. But, this question is more about the developers choice of how to distribute their application. On iOS it's the App Store or not at all. So one can argue that the App Store has a 100% monopoly on distribution of iOS software. In other words, a developer that runs afoul of Apple's censors could find their app and themselves permanently banned from the App Store, flushing untold man hours down the toilet and leaving that developer with no alternatives. You also can't have anyone else start a new marketplace and say "Hey, I can provide a secure marketplace for transactions and ensure applications are trustworthy more efficiently than Apple, so I'm only going to charge a 10% commission".
First: Why not let fluffernutter speak for himself? I had seen his anti-Apple posts for quite some time, and believe me, he is not shy about posting his opinions. I don't think he needs his Mommy to fight his battles.
Having said that, I will go ahead and address your "argument".
According to everyone at Slashdot, Apple is just barely hanging-on with a miniscule market-share. So, why would Devs. be SO anxious to get their Apps placed in the iOS App Store, even though it may mean they have to invest in a Development Platform that they personally don't like to one degree or another?
I'll tell you why: Because, unlike the VAST majority of cheapskate Android owners (most of which are kids or poor adults) WON'T PAY for Apps, and only look to see what they can leech for Free, or PIRATE. Conversely, although iOS owners certainly enjoy a good, free App, they are MUCH, MUCH, MUCH more likely to reward Devs. that produce a useful App with their actual MONEY.
You will just argue that iOS owners are duped into purchasing Apps they don't like, because Apple doesn't have "Free Trials". Well, that argument ignores the fact that Apple has ALWAYS had a 14-day money-back for ALL p
Location specific ads.
There are a LOT of vectors for THAT information, idiot.