Posts by doublelayer 10312 publicly visible posts • joined 22 Feb 2018
To some extent, it is relevant because they are trying to show that Apple frequently tries to use its market dominance to disadvantage competitors. It isn't core to their point, as they're talking about a different alleged anti-competitive step, but they want to indicate that it's a pattern of behavior by Apple which harms its customers (users and developers respectively). That is the purpose to their discussion.
I don't understand your complaint. While I don't know very much about them or their games, it seems like the one I've heard of, Fortnite, is supported on all those platforms except Linux. From Wikipedia:
Platform(s): Windows, macOS,[b] Nintendo Switch, PlayStation 4, PlayStation 5, Xbox One, Xbox Series X/S, iOS,[b] Android[b]
If you're asking why they don't put those on disks instead of downloading them, the answer would be that most computers don't have optical drives at all and most which do are traditional DVD readers which probably aren't big enough to store modern games compiled for five platforms. Also, I don't know if the various consoles have a disk format which allows universal disks.
Perhaps the better question though is why this matters to anything? Is their point against Apple any better or worse because of this lack of disks?
I am predicting that, should this become available, the price of the equipment necessary to transmit to it and the usage charges will make it impractical for most use cases, and that power requirements will eliminate most of the remaining ones. Most of the similar systems I have seen are very expensive and charged per device. A small place with a few devices will probably reject it because the base price is exorbitant, whereas a large place with many sensors would not use it because it requires purchasing thousands of connections, one per sensor. In order for this to be useful, they will have to do something to improve the cost and power usage over things like LoRa to a central station which relays it through a different mechanism.
"Having verified that it was actually from my company, I clicked the link - and they claimed I "fell for it" and automatically signed me up for remedial infosec training. Never mind that I *knew* it was from the company, and didn't provide any personal details, etc - apparently all it takes to compromise their entire corporate network is for a lowly employee to click a single link, so the employee must be at fault, right?"
Here's some more training. Don't click suspicious links. Clicking links and entering information is certainly worse, but just clicking the link can be a problem. It exposes you to whatever the page might have, including an attempt to steal an SSO token or even a possible (though very unlikely) zero-day in the browser. They were right to treat clicking the link as a partial failure.
Just because someone did it doesn't make it the company's decision or authentic. If I decided to mess with my colleagues by sending them such an email, my company didn't agree to do what I made up. For the same reasons, the security test can involve things without requiring other parts of the company being obligated to do something that was clearly not intended.
Yes, if the complainants can prove that IT used an internal domain, then the complaints are more justifiable. I haven't seen that, but I'm doubting that was the case. This sounds like some people got annoyed that they were caught and now want to punish those who caught them.
You are being simplistic to the point of incorrectness. The attacks where spam is sent to massive lists use that tactic to try to filter out people at the first stage--if they're going to balk after interacting with the scammer, they've just wasted the scammer's time. When the list of targets is shorter, like the employees of a company, or when the goal is faster to attain, like just getting credentials, they want more people clicking right now. They can write well to get that to happen. They do this frequently and it works on occasion. Training must include this.
"For phishing to be any use it has to look dodgy; contain spelling mistakes, a really obviously bad url. Should staff have known a bonus was beyond reality and that was the clue?"
Have you ever seen phishing? Not the kind that gets sent to billions of addresses, but the more tailored kind? If they're sending it to a small number of people, they'll work on that. They'll figure out your name. They will figure out where you work and what their emails look like. They'll copy pages exactly. They'll identify who your boss is and impersonate them before sending instructions about where to redirect the payment. You have to figure this out by certain less obvious details. I have received such messages. I haven't fallen for them. There are people who need training that such messages can happen and that vigilance is necessary. You might be one of those people.
The method used in this case was regrettable, and people who fell for it and had expectations are understandably unhappy. Unfortunately, it's exactly the kind of phishing that people might try. I've seen COVID-themed phishing and it didn't do me the courtesy of being badly written.
I listened to the video, mostly because I wanted to hear how piercing the alarm was (spoiler, it's not even in the video). However, while listening, I found it a little strange that the system is using an American accent when reading out the message. The system is perfectly able to imitate received pronunciation and still sound simultaneously angry and bored, so maybe Android should use that when the user is in the UK.
"It is very difficult to hire engineers to work on any software, so is a company going to spend that rare resource on open source? Maybe if the open source is your product and the openess is a marketing tactic. But things that are difficult to monetize like open SSL or BouncyCastle?"
What would they do if those things didn't exist? They would still need the library. Someone would be hired to write it. Likely several companies would need it and hire developers to write their own custom versions. In this case, it's a lot easier to contribute with smaller donations because those can be pooled and the library created for everyone who needs it.
Being an open source developer does mean there's a lot of unpaid work, but companies use the software all the time. If it wasn't available elsewhere, it would have to be created by someone, which would be at least as costly and likely a lot more so for all the users.
Of course this is a risk. There are three solutions to this: 1) put more people on it so you don't have that much of a risk, 2) give the people more money so they're harder to tempt, or 3) don't rely on it because you need something maintained by more people. Just going commercial doesn't fix this, as the company can still give the project to a small team.
"HOW the HELL is it CHEAPER for someone else to host the servers, pay the electric bills, maintain it AND make a profit than it is to do it yourself?"
You know this. It's a scale thing. The same reason it is usually cheaper for someone else to generate your power rather than building a plant next to the office. At some point, the benefits of having your own power generation are high enough that you'll buy the equipment and hire a maintenance team, but most places choose not to. The costs of running systems on-site are lower so more places can save money by not using cloud services, but there are places who either don't have enough equipment to justify the cost of on-site installation or who want things that the cloud can do more cheaply. For example, it's easy to have identical servers on multiple continents using a cloud service, but much more expensive to have maintenance teams in multiple countries to do it yourself. That's how.
"So if I decide to use a spreadsheet to do my business forecasting, you suggest if I can't do the same by hand on paper that I should hire a developer just in case?"
No, I suggest you review the spreadsheet program you are using. What is the likelihood that the company that makes it stops supporting it? What will you do in that case? If it's Microsoft Excel, then the likelihood is very low and you have alternatives which support the format. If it's Excel365, the likelihood of trouble is higher so you should ensure the data is also available on-site, but the format is still open so you have alternatives. If it's LibreOffice, then it probably won't get dropped, it will keep working for a bit if it does get dropped, and it can export to common formats. And if it's somebody else's spreadsheet program which doesn't use common formats, then you should at least know what you will do if you need to move elsewhere. It's crisis management. Just like a plan for what you will do if your office power fails, you should have a plan for anything critical to business operation if you are responsible for managing that.
This is an important point. Proprietary software can die in a number of ways. Since examples are fun, I'm throwing another one in. There was a piece of proprietary software which I wanted and purchased. Unfortunately, it was software with a small market and many of the people who wanted it chose to pirate it instead. The company concerned dealt with this by releasing an update which contained two additions: A) it didn't crash on the weird Unicode characters anymore and B) it checked online for the validity of your license and would stop working if you stayed offline or were found to use a pirated license. People still pirated it. So they went out of business and the licensing server shut down. I was left with the option to use the old version and deal with the crashes or not use the software at all. The older version was only an option for me since I had kept it in a backup; those who purchased later would have had a harder time. Another option was to try to break the licensing server requirement, essentially pirating it myself and breaking the EULA. I had paid them money for it, but it wasn't enough for them to continue supporting the software.
Most businesses do not have the ability to immediately pick up the source of something that has been dropped. No businesses have the ability to do that with something that doesn't have source available. This is the core difference. It doesn't make open source perfect, and it isn't, but it does mean there are some options available. Only if commercial software has a significantly longer life would the comparison work.
Unfortunately, it does not. Proprietary software gets dropped all the time. It's very frequent that some business doesn't think a product is worth supporting and cuts its funding. Just because it was charging for it doesn't mean they have the money to afford continued support or were using the money for that purpose. If the company goes bankrupt, cancels the project, fires the workers, doesn't replace the workers when they quit, or anything similar, the software dies. The user of the software has to balance the cost of the support contract with their estimate of whether the developers will continue to support it. I don't have the same confidence you do that a small team with few resources, even producing commercial software, will continue to support it long-term.
It does. That's how .gov.uk works. A scammer can't impersonate a .gov.uk site, but they can register a normal something.uk address and see how many people will spot it when told to go there and enter in their tax information. You can't really do anything to prevent that from working, but you can work a lot harder to take it down later or even detect it before starting.
"One day of one IP is worse then all of your devices using one single IP for the duration of your DHCP lease how, exactly?"
In IPV4, all my devices use the same address so my network can be tracked. This is annoying, but there's little I can do about that. In IPV6, my network will assign addresses in the subnet allocated to me, so the same system can still track my network by looking at that prefix. My network is trackable either way. However, with individual addresses allocated to devices, the tracking can also track those devices. In addition to knowing they came from my network, they can also know what else they've done that day. It also lets them correlate a fingerprint on one activity to all activity from that device.
For example, with NAT if they fingerprint a browser running on one of my devices, they won't be able to identify traffic from another program on the same device. For all they know, that program is running on a different device in the same network. With individual addresses, they know exactly which device used it, and they can use that fingerprint to identify devices when the addresses change assuming they have a method which persists across days.
"The one with the best bandwidth is chosen as the lead server and the rest of the participants each maintain one connection with the lead."
This is a lot like the original situation. It solves some of the problems encountered at first in the situation, but can still be insufficient. For a small group of people, with a participant who has a reasonable connection, it works. If all participants have poor connections, then there won't be someone with enough bandwidth to make this function. If everyone has a high latency, then using this model will increase everyone's latency significantly. If the group gets large enough, then the processing power needed to aggregate all the feeds will likely not be available using the machine of the person with the best network.
Once again, the idea isn't bad. If you want to have a videocall among five people with reasonable network, then this method will work well enough subject to the other problems I listed earlier. However, it doesn't scale very well so it will encounter problems if you ask for too much from it.
Great plan. Now I have to know where your desktop is, how to send requests to it, get your mobile's address, then send my message, then find that the address is old because you went offline, run a loop to check your desktop until you send another one, not get one because your mobile came online and still has the same address, but I didn't send another message because I thought you were still offline. That's the situation with the fewest things breaking. If your desktop goes down, your mobile is cut off as well. If your desktop is attacked, your mobile's communications can be redirected. And perhaps most importantly, there are very few people who are willing to go to the effort of bouncing requests for direction to communicate with you routinely. If we're evading a sophisticated adversary and we need to hide our communications, let's do that. If I'm checking if you want to get together for lunch, I'm not doing all of that when perfectly functional alternatives are available where I just need to know your email address or phone number.
This is a good feature, but there are two problems with it. First, networks can be configured to reject it and supply the dangerous address which embeds the MAC address. Most users won't have a clue how to check for it--for that matter, most users won't have a clue what it is. Second, even if you are using a temporary address, it usually changes every day or so, which is long enough to correlate information if servers are tenacious enough. Also, you need only one session to persist across days for the new address to be linked to the old one. The privacy extensions are very needed, and if used they help solve the largest problem, but they're not perfect.
"Also, as I keep mentioning... IPv6 will herald the direct communication revolution and the rise of peer-to-peer messaging will happen once again"
I doubt it. P2P is useful in a variety of cases, but most of those cases are already covered just fine by existing systems. It will do little for Facebook. P2P communication is great only when you want communication between two devices who already know how to find one another. Deviate from that path and you'll have difficulty proportional to the distance from it. Here are some examples:
Videocalls between two people over 2P work very well. The only issue is finding one another, but the users can figure that out if they want. A videocall among ten people doesn't work so well. Under the current system with a centralized server, each user only needs to maintain one bidirectional connection, with the server either constructing the feed for each or at least aggregating the encrypted feeds if it's a secure one. With ten on a group P2P call, each person would have to maintain connections to nine other systems, meaning a lot more bandwidth is needed.
Now what happens when devices don't know how to find one another? Why do we use centralized communication systems now? It's not because we couldn't send P2P messages. A lot of the time, it's because our devices don't work as well for it as they did in 2003. In 2003, the computer was a desktop and could be left on to receive messages and keep up a connection. In 2021, we have devices which move a lot and have inconsistent access to the network. If I am using a laptop on the go, the address will change frequently and I'll be offline for long periods. A centralized server can find me when I come back online and can store my messages in the meantime. A P2P system can do neither. The solution to this problem is usually a central server which stores only usernames and current addresses, which helps with the first problem but does nothing for the second.
How about Facebook? Yes, some people use Facebook to send direct messages. Most people, however, use Facebook to publish information to anyone who wants to read it. P2P is completely useless in this regard unless you're going to host your own website (they won't). If you want to send a picture to any friends who read your feed, you need to host them somewhere. This is no longer simple communication. It's publishing and it requires the infrastructure of publishing. I therefore think that IPV6 will do nothing to weaken Facebook's business model. As much as I would like that to happen, it won't work.
If you don't have NAT, you have a firewall doing what it does anyway. Opening ports to anyone who asks is risky if you don't understand the risks, and unfortunately there are many who don't understand the risks. The benefit of NAT is that it makes the process of opening a port harder, meaning more people will check whether they want to, but that's not very important. The real security benefit of NAT is aggregating data from a network into a single outbound IP address meaning that tracking individual devices by IP doesn't work as well. For that reason alone, I will continue to use NAT on my IPV6 network for all the devices which don't offer public services.
But it is not a nation-state attacker who took it down this time. This reminds me of a person I used to work with whose attitude toward security was that every attacker was either someone too stupid to figure out anything where the password wasn't 123456 or a coordinated effort by at least three countries, therefore basically anything was fine because the Chinese military or NSA could figure a way in. He was wrong. You can accept that a system cannot ever be perfectly secure and still secure it to a level where it's a lot harder for them to get in. If the nation-state attacker had to launch a sneakernet attack to shut down the pipeline, this ransomware gang wouldn't have gotten in and it would be working today. It would also be a lot less likely that a nation-state attacker would do that, because such attacks are costly for them so they won't do it as often.
"Beyond that, I mentioned the potential for using NFCs to track copyright registration on a post a few days ago - if everything has an NFT embedded in it at the point of creating or updating it, then you could potentially have a system where every item contains a record of the IP which went into it."
Unless someone wants to violate the copyright, in which case the expensive mechanism does nothing for them. Use someone's sample and don't include the NFT part, and they'll only find out if they hear it. Just like today. Meanwhile, it assumes that all the things that someone might want are already packaged up ready for resale, which would take a lot of chopping out pieces which nobody actually wants. Furthermore, it makes it very hard to figure out fair use uses, such as quoting something which has an NFT stamped onto it.
The system could work, but it would be more expensive than the current one, no more restrictive of illegal activity than the current one, and more complex than the current one. I don't see much benefit in attempting it.
"But gosh, doesn't "non-fungible" mean "cannot be turned into cash"?"
No. Non-fungible means that individual tokens are not identical to one another. If both of us have one and we exchange them, we each leave with different things. It is different from cash because cash is fungible, but nothing prevents you selling a non-fungible item for fungible cash. We do that all the time and people do that with these as well. They're mostly worthless, but you have the reason wrong.
Apple gets benefits from app developers, namely that people stay on their platform because apps are available. We've seen how it works without developers on board. Windows Phone was a platform that worked, and many people here have posted praise for it as a good one (I never used it myself). It's dead now and one of the major reasons is that many apps were not available so people didn't buy the devices. Should Apple be rewarding developers for providing this assistance to their platform and keeping them competitive?
Developers and Apple are supporting each other with users providing a flood of money for Apple already. Meanwhile, most of Apple's work helps the individual users who pay for Apple's hardware. Why is it the developers which have to give Apple gratitude in the form of a bunch of cash when Apple doesn't have to do the same for the benefits they get?
"Each of the above run their own private copies of WebKit or Blink on my Windows machine, wasting tons of RAM while simultaneously weakening security."
That's a problem with people using those engines to do their GUI work. If your OS had one of those as the only option, it wouldn't prevent the machine spinning up separate copies for each app. The main reason why is that you want them separated for security reasons, exactly opposite to the problems you think you have. If a bug is found in your browser's rendering engine, they can't get your Teams engine to cough up data because they're not the same unit. There's one good reason they should stay separate.
"Linux probably fares a bit better thanks to system wide libraries for all distro-shipped packages but when Flatpak takes hold, the situation will be far, far worse... probably worse than on Windows...."
The only downside as far as rendering engines are concerned is that there may be multiple copies of the files. That's more disk space than you need to use, but it doesn't do much else.
"Adobe Flash was banned from iOS because its wonderful rendering engine killed off the battery. That's the kind of world you can look forward to with arbitrary browser engine installation."
Lots of apps kill the battery. That's not against the rules. You can either discard them as bad apps or decide that you like them even though they won't let you run very long. That's not Apple's decision to make, and they repeatedly don't make it when it's a different kind of app. They didn't like Flash because: A) Adobe didn't port applications to OS X until after a long delay and Steve Jobs held a grudge, B) it killed the battery and they didn't like it, and C) they didn't like the structure and wanted to encourage adoption of other alternatives. I agree with their reasons B and C, but that doesn't mean it should be their decision what I'm allowed to run on my hardware.
"There *are* Apple competitor apps on the App Store, for example numerous email clients, so the "nothing that competes with something we do" policy is all in your fevered mind."
They have banned apps which compete with other parts of their system repeatedly. See the screen time feature and all the apps which did it and got banned for another example. So they didn't bother when it was a mail client. That doesn't mean they always allow it. They don't.
"WebKit is a core component shared by multiple apps on iOS."
Correct. That's just fine. Any app that wants to use it can. No argument here.
"If Apple allowed arbitrary browsers to have full control of the networking stack"
They wouldn't. Same access as any other app.
"and rendering capabilities,"
Sorry? "Full control of rendering capabilities"? What does that even mean?
"you'd end up with browsers like full-fat Chrome on iOS that use decidedly privacy-hostile web standards."
Agreed. I wouldn't be installing it.
"Apple can't permit that at the same time as advertising that they protect your privacy."
They could ban any app that tried under their privacy rules, not the rendering engine rules. You don't have to ban specific kinds of apps if you can just say that tracking without permission is forbidden whatever app is used to do it.
It's Python. It's slower than native code, definitely. It is likely to be accurate though, so if you need very large numbers with arbitrary precision and you're willing to deal with the performance problem, that's a way to do it. Like most other systems, you have to know what you're doing while using it, since Python also has floats which work equally badly as everybody else's floats so you need to know when not to use them. A lot of possibilities would have avoided this bug. It just takes some consideration about possible inputs so the programmers store things in a type which can handle them.
This isn't striking me as a particularly intelligent action on their part. I would have imagined big numbers to be an important test case for the code before it got used at all. Even at the stage of throwing random data at the code to watch it work I think they could have found that. If they just theorized a test stock which increased in value geometrically, they could have tested the limits in a few seconds.
And if they said uint64 instead of uint32, the system would have worked. Or if they used one of the many languages which have an integer class which can resize itself when it needs to. Or if they tested some big numbers, because this is not really that big a number. Cobol also has big integer functionality, but so does basically everything in existence today. You still have to remember to use it or work in a language which doesn't give you a choice not to. Cobol isn't a panacea to this problem.
Most likely, they represent users who don't read the comments on the source. A lot of users don't ever intend to edit it, so they ignore it. It doesn't mean they don't care, it means they didn't see it. For example, until I read it here, I didn't see it. I use Audacity on occasion, but I don't monitor its repo because I don't use most of the advanced functionality. I have other programs for that. Therefore, I wouldn't know either.
You may not have read my feelings about Audacity's move. I do not like it for exactly those reasons. I don't use Google because I feel the same way you do; all opt-in telemetry from my code (most of which is people who agreed to use the beta builds and send it) is sent to and processed by my own infrastructure. More work, certainly. The only respectful way to treat the users, yes.
Only some of the time. As a developer, there are plenty of cases where I would like to collect some telemetry about use. That's not just bug reports, but also information about how it is used. For example, I have a project where I'd really like to know how many people are using old versions and not updating, because that would give me some information about how important it is that I maintain compatibility with older versions. I don't think that particular datum is going to provoke many negative reactions.
Still, I don't collect it unless someone has opted in, and I don't use any third-party system to collect the data. I don't do those things because I respect my users. While it's not harmful for me to collect versions, it may be for me to collect metadata such as the IP address they used to tell me. There's lots of other information that would be more sensitive. It should be the user's choice whether they are comfortable sending that to me, and it is my responsibility to ensure that they can do that without my divulging data to others. I don't object to opt-in data collection if it's done clearly and by a responsible organization. I view the use of Google and Yandex as the actions of an irresponsible organization, and the change in ownership makes me believe that the process will become unclear in the future. Therefore, I do not like this.
If we're doing it right, it goes more like this:
You steal a piece of territory from a Chinese government, which gets torn down by its citizens, replaced with another Chinese government, which gets torn down by a section of its citizens while another section of its citizens try to defend it, then that new Chinese government kills a lot of the citizens who supported it, then they demand it back, then the power which stole the territory looks at the people who live in that territory and do not want to be given to China, then turns them over to China anyway. The U.K. isn't covered in glory from this operation, but the people living in Hong Kong got the worst end of everything. They were handed over to a dictatorship against their will which did exactly what they feared it would do.
The terms should have been set by Hong Kong's residents, and they weren't. Of course, they probably would have said something along the lines of "Not with China. In fact, let's see if we can somehow move the island farther away." You can easily blame the U.K. for being a colonial power which committed a large array of atrocities, but using that argument to argue that China's actions are in any way justified is wrong.
That's never going to happen. If you're faced with a criminal who is willing to cut your finger off, they can also just use the cutting implement to threaten you until you use the fingerprint to unlock the system. Then they're in. Or they can similarly threaten you until you give them the backup password, which basically everything has, and they've achieved the same. If the theoretical criminal wants access to something, they will be satisfied with a password because nobody wants to carry around a dismembered finger unless they absolutely have to. Even if the finger would work, if there's an alternative which there is, they'll use that.
If they're threatening you with violence, just give them the pin anyway. I haven't seen a device which accepts fingerprints and doesn't have a backup pin for when you've recently washed your hands thoroughly or are wearing gloves. If they want it unlocked, that's more reliable and less painful for you.
Some of that is due to cheap touch elements. I have that problem, and I'm quite young. I only have it on a old and very cheap device I keep around for ... actually I don't know why I keep it around as it does nothing useful and is a pain to use. Well anyway it's here. The older and cheaper panels can lack precision which means they don't frequently register finer movements. For example, on this one, it will register taps well enough but it is not very good at registering movement of the finger. Scrolling frequently doesn't work because it thinks I'm just tapping on something.
"Here's a suggestion to ISPs: supply non-configurable routers."
They already do that. It doesn't fix anything, but it does have the extra feature of making me sad when I see it. For example, the one supplied to my parents wouldn't let me change the DNS servers to a pihole, or set firewall rules, or actually do very much at all. Fortunately, the advanced section (three options) contained the UPNP off setting, so it wasn't a total loss. I could have turned off its WiFi and used a downstream router (fortunately it doesn't redirect DNS queries) but that would have been another possible point of failure that I couldn't easily fix since I don't live nearby.
The problem is that the BBC headline, though somewhat misleading, is completely factual. Here's the relevant portion of the Register article:
However, the Oversight Board criticised the extraordinary nature of the ban, which was not rooted in precedent, but rather a reaction to the events happening in Washington D.C.
“It was not appropriate for Facebook to impose the indeterminate and standardless penalty of indefinite suspension. Facebook’s normal penalties include removing the violating content, imposing a time-bound period of suspension, or permanently disabling the page and account,” it said.
It has ordered Facebook to revisit the decision within the next six months and re-issue a penalty that’s based on ”the gravity of the violation and the prospect of future harm,” as well as precedent.
So it did order Facebook to rethink the decision, but specifically to decide on a different penalty. Of course, from their list of accepted options, it seems Facebook could just suspend for a fixed length period of sixteen centuries and that would meet the requirements.
Maybe you like privacy? Or maybe you are a criminal of the type that asks for democracy in a country which doesn't like when people do that. Various reasons for wanting privacy in financial transactions exist which aren't just committing crimes. A lot of them aren't allowed under the current system to make committing those crimes more difficult, but they do exist. You can easily argue that they are insufficient reasons to have anonymous transactions and shouldn't be permitted, but you'll need to recognize what they are first.
I wonder about this. Apple hasn't been getting very much money from me even though I still have an IOS device. All the apps I bought were purchased years ago. I don't use them for subscriptions. Most apps I have downloaded recently are free apps for some service I'm using. I wouldn't be surprised to hear that app revenues are concentrated on a small group of people who play a lot of mobile games and frequently buy things in them, which would mean that most users are not providing them very much at all.
"And honestly, when buying something which is 50% cheaper, do you really expect to get the same level of after-support service? The money for that support has to come from somewhere..."
You are correct. No, I don't, at least I wouldn't if the ones that cost the same or more had comparable lifetimes. They don't, so this particular argument doesn't work very well. If the Android ecosystem consisted of the landfill devices which wouldn't get support, the mid-range ones with three years, and the flagships with six or more years, then the comparison would work. Otherwise, if Android devices were all much cheaper than Apple devices with the difference in price accounting for the difference in support time, that would make some sense too. As ridiculous as Apple's prices are, Android manufacturers have prices in the same ranges.
I can take this one:
"Your 5+ year old iPhone,"
SE, 2016.
"With the latest software update does the phone still perform nicely or has it slowed down considerably?"
That's not a problem here. The performance is reasonable on the most complex tasks I run. Admittedly, there are even more complex tasks I don't run, so I could see it being a problem, but for my usage, including navigation and a variety of apps, performance is fine.
"Does the battery still reasonably work and hold a decent charge?"
This is the big problem. The battery is inconsistent. Sometimes, it will hold a charge for two days. Other times, it will fail in five hours. I attempted to have Apple replace it but they have refused due to the age, so I will be trying to replace it myself and see if that fixes things.
However, hardware reliability isn't the full story. If the battery replacement fixes things, I have a device running the latest OS version including security updates. If I have an Android device of a similar age with a new battery, I still have a compromised device. Whether Apple is perfect is not really the question (they're not even close). The question is where they stand compared to the competition. They stand ahead of it.
In addition to being more expensive, you don't really know the motherboards will be better. I can go get a motherboard from a variety of sources from companies that nobody's heard of because they started up last year. You have to trust that your technicians aren't just doing that. That's not the main issue though. Self-building works fine for desktops, but a lot of buyers and users don't want desktops. Laptops have a lot of convenience, and now that their processors aren't hampered compared to the needed office workloads, they're quite suitable. I have rarely seen a successful self-built laptop, let alone one that people would really want to carry.
I like Python, but there are several issues that at least have to be acknowledged, even if we're going to decide we can deal with them.
The syntactic whitespace got us here, so let's start with that. It's annoying because the boundaries of control flow are no longer clear. An expression could be inside or outside a block just because someone forgot to change the indentation. In languages which use braces to mark blocks, that will result in a compiler error under most cases. This makes errors more likely. It also makes copying and pasting code harder, because there's a chance the person re-indenting something which does not originally align will make a mistake which won't be caught until runtime starts to go surreal. I don't exactly mind syntactic whitespace if only because it makes others indent properly, but that's not usually a good enough excuse for it.
There are a few other design decisions of Python which can be counterproductive. It has almost completely eliminated pre-runtime checks of any kind. That makes the interpreter simpler, but it makes simple typos or incorrect thinking harder to resolve. A few language features complement this problem. For example, the fact that objects and classes are completely open and that variable creation and variable binding (assignment) are syntactically identical. This opens new classes of typos because nobody will check that the variable you want exists until right when you ask for it. Fuzzing is therefore more important in Python just to catch things another language would get during compilation.
These issues are not shallow, but nor do they eliminate Python as a useful language. I think it's great for prototypes or for various tasks which other languages make painful. I would much rather use Python to do string parsing than most other languages. And a well-tested Python program can be a core component in something without problems. Still, it's imperfect in various ways.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
