Posts by doublelayer

Sure, they could have made an IPV6 that looks more like IPV4 and has longer address fields, but that would still require people to implement the new protocol, exactly like they do with IPV6. The other changes introduced when they made IPV6 have some problems, but that's not the reason it hasn't been adopted. Most places that haven't implemented it aren't saying that "If only IPV6 didn't have [insert change here], we would just use that". Either way, the change requirement would be the same and the work would only be done when it was almost too late.

That estimate is just wrong. I don't know how many addresses are in use, but there are three categories to consider:

1. Machines that are online now and respond to pings. About 6 million, evidently.

2. Machines that are online and do not respond to pings. This is the default for most machine images and firewalls. You have to take two manual steps to change your configuration to allow pings. I'm not sure why this guy assumed that 50% of users would have done that.

3. Machines that allowlist IPs and won't respond to your script no matter what their ICMP settings are. There are a lot of these out there for private networks that use the public internet to connect them.

I don't know how many are in use, but it's a lot more than 12 million.

Re: Re. There are now more devices than IPv4 addresses

The problem being that, if you want to have two servers but you only have one IPV4 address, you have to put another box in the middle to filter and direct traffic to the right one, and if you want to have twenty, that box ends up having to be a lot bigger to do work you wouldn't need if you could just give each server an address. The problem being that, when someone wants to build a point-to-point network from their own devices, they can't do it without some central server coordinating things because their ISP has multiple layers of NAT in the way. Let me guess, you don't see a problem with it because you either don't run many or any servers on the public internet or because you already have your own IP addresses? A lot of people do not have assigned IP blocks, and many countries were assigned so few that you'll virtually never get them. It's another reason that people start to use cloud providers, because there isn't much work involved getting a new instance publicly available, even though it produces a worse maintenance requirement later.

Re: Plus ça change, plus c'est la même chose

If you're being tested on how to write an essay, you need to demonstrate that you can write it. If you're being taught to use a brush, you need to demonstrate that you can use a brush. That is different from later applications of the same. If you're being tested on painting something in general, you may get to choose a tool from a set of different ones to do the job, but if they're specifically testing your ability to use a basic brush, you may not get to use a different tool, even if you otherwise would want to.

For example, there were a couple occasions in my schooling where I was permitted to select the language in which I'd write a project, but mostly I did not. If I had asked to do so, I'd have likely gotten a response like "Of course you can write this string manipulation program faster and easier in Python than in C, but this class is taught in C and we want to give you something easy so you learn how to use C". It doesn't matter that, if I had a similar task in the workplace, I would almost certainly not use C unless performance was critical, because the point was not to have the program written, but for me to learn something.

Re: Plus ça change, plus c'est la même chose

The calculator does a specific task and it is easy to decide whether having that task delegated is acceptable. If it's a child doing arithmetic tests, it is not. If it's a university student doing calculus, a calculator that can automate the insertion of terms into a formula the student derived is fine, but a program that automatically derives it is not. In the workplace, that program is probably fine as well.

An LLM is sufficiently capable that it could do a number of tasks, nearly all of which are not acceptable. The comparison to an assistant is valuable here: in school, you don't get to have an assistant. I did not get to write my code, then pay someone to write the documentation for me because I couldn't be bothered to do it myself and the graders didn't look too hard at it; I had to write that myself because that's what the assignment was.

Some of them have to realize that the homework answers generated by an LMM have a decent chance of being wrong. If you're going to cheat, there are ways to cheat that aren't as much of a throw of the dice. Sure, they take longer and may be more difficult, but if you're bothering to cheat, presumably you want to get something out of it and LMM cheating isn't guaranteed to get you anything.

Re: Linus being shouty is not really news

Leaving the realm of Linux entirely, I think you've misinterpreted the statements that led to this part:

"However, volunteers have the choice to just not volunteer anymore"

Yes, they do, which is why you generally want to stop that from happening. In many places where you have volunteers, they're not that easy to get and can be really important to whatever you're doing because, if you didn't have them, you'd either have to pay someone to do what they're doing or do without whatever they're doing. In most situations where there are volunteers involved, they are a major asset. Mistreating them can be even more harmful than mistreating an employee because the volunteer can usually just quit at a moment's notice, whereas the employee might hang around long enough for someone to apologize and fix things.

I know how frustrating a support call can be, but that doesn't change any of the harms that getting shouty can have. Even if it is entirely their fault, getting angry at them often will just extend the process. For example, in your situation, they could have accidentally called you as they were changing focus because the call system's interface makes that too easy, but they didn't know that they had done it. They were using headphones but had taken them out because they weren't on a call, meaning they couldn't actually hear you. Then they got your remote request, and having just talked to you, they accepted it because they didn't understand. A few hours later, they don't know what you're talking about with this second call idea because the call was ended without them ever looking at it. That is a possibility, and shouting wouldn't help to resolve it.

Re: Had a similar thing happen

I'm assuming you've already tried forcibly closing the app alone, not the entire phone? If so, I'm wondering how badly someone can manage to make an app that can cause a persistent crash that still goes away on a power cycle; the process isolation of Android and IOS is supposed to make that hard to do. Not that they don't manage it, but I've usually not had to power cycle mobile devices to deal with a faulty user-level program whereas desktop programs do it with some frequency.

Re: I would really like a good book on network security

The problem is that many of those questions have really long answers. Checking the settings for UFW, iptables, or Windows firewall is pretty easy. Running nmap over your network is a bit more difficult, but not too hard. Knowing that no software has a sneaky path is so much more difficult, and understanding the full risk profile of every service is a task that cannot be done the same way for any two systems. There are some checklists for blocking the easiest attack methods, and many of those checklists are getting adopted as defaults anyway, but every level of complexity that gets added brings vulnerabilities that are a little harder to exploit and also harder to detect without spending some serious effort on it. The risk of trying to write checklists for those levels is that there are too many things to list and many occasions where applying a preset configuration runs the risk of breaking something else. Even if it doesn't, the risk of giving someone a false sense of security is always present.

Re: It's time

I'm not so sure. It's easy to assume that, because they collect all sorts of data, intelligence agencies should know everything about everybody. I'm not convinced that they actually do much with the stuff they collect until after they decide to use it. They probably don't spend their time tracking down criminals, leaving that to normal law enforcement who doesn't have the massive datasets that the intelligence agencies do. I'm sure they know some identities and aren't responding for the reasons you've stated, but I expect there are many who they consider beneath their notice.

I have no problem with adding it, but the major problem is that they're not getting punished with anything. From their perspective, they're not too worried about what they would be charged with because they don't expect they'll be arrested or punished and they've often been right. So, while your logic is flawless, I wouldn't expect making that change to have any real effect on what happens, at least in the short term.

Re: Time to ban paying!

I agree with you that a ban on payments would be a good idea to pursue, but I think you're underestimating the ability for businesses to get around the rules. I don't think, for example, that "payment to a shady facilitator will look just as obvious in an audit as a payment of the ransom" because it's really easy to hide such a thing. Instead of paying the ransom directly, you pay a company who is going to provide contractors to help you clean up quickly. Those contractors might be helping you restore from backups onto fresh images, or those contractors might be taking part of your payment and paying the ransom with it. Only the contractors need to know which one they picked, and even if you know, you have an excuse for why you might not have known to get around the fraud charges.

However, I think that the number of companies doing that will be less than the number of companies paying ransoms in the clear, so I still think that banning payments would reduce the number of payments made and thus the profit in it. It won't reduce either to zero, but a lower value is still an improvement.

Re: Doh!

You can disable it entirely so it can't be activated without enabling it again. I'm not exactly sure what "nuke it completely" entails. Do you want Siri to no longer appear in the Settings so it's impossible to turn back on?

Their point appears more general than that, though, since Siri is a frontend to a set of databases that are usually available in other places. Siri's contact information for businesses, for example, is the same ones you can see in Apple Maps as well. The problem is not the voice interface, but the incorrect data it occasionally returns.

Re: US bias

That's what happens when you shove the entire internet into the training set and push the go button. These programs are not looking through the data to find out which things apply to your country, they're just guessing, and if there's more about the US in their training data, it's going to show up when it randomly looks for answers unless you've crafted your prompts to keep reinforcing your country name. Even then, it's not guaranteed to get things right, just more likely to. I'm hoping that people will eventually recognize that this cannot answer specific detail questions when those questions get past simple (I.E. whenever a simple search wouldn't turn up the answer).

Re: The Blackberry Passport...

However, if you're not clear, then both projects fail to meet your standard. Exchange is breaking compatibility by not including the rich message whatever it does, and Thunderbird is failing to be compatible by not supporting it. In this case, I think it's more Thunderbird not supporting it than Exchange not sending it, but I don't know for certain. If you ask for interoperability, I see two ways of doing it:

1. Everything must support the protocol of everything, which either means that I cannot introduce new features because it would break compatibility with anyone else or that, if I do introduce new features, everyone must adopt it. It sounds like neither of us want to do this.

2. Everything must support some standard communication system in addition to whatever protocol they were built for. You can do this, but what's the point? Anyone who uses it is presumably using it for its unusual features, which will be the reason it has a protocol other than the standard. If they just wanted another XMPP client, they have a bunch to choose from. We might as well make that standard email and tell every chat system that they'd better bolt on a mail client. Those systems having the feature won't make anything easier for the users.

Re: The Blackberry Passport...

"This is why, incidentally, I want to see all messaging vendors legally compelled to be open to existing open standards and allow connections from 3rd party client apps."

Well that's an interesting request. How do you intend your system to deal with the situation where someone makes a new chat app because they want to offer some feature that's not supported by whatever open standard you've selected? That feature could be a lot of things, from a different format of media to a new encryption strategy. Most of the apps in your list were originally made to add some new feature that previous chat systems lacked. You could deal with a few of these by embedding more and more information in the message, and old clients just dumping unsupported messages out as text. That would work for a few things, although it's not pretty. However, for anything where the architecture is substantially different, for example if they change the routing mechanism to something decentralized or start using asymmetric encryption with user-provided keys, that won't work either. So far, I have opposed similar requests because I don't have a good solution to this problem and I don't want to lose the benefits of new systems. Do you have an alternative?

Given that we don't know exactly what software they were using or what actions the monkeys' brains were activating, and that this is a person whose companies have been accused by employees of faking sales videos before, I would take that particular demonstration as perhaps not indicative of the product you get.

Re: Less "connected" means less likely to be hacked and randsomed.

What makes you think that the system that took in data on floppy disks had no network connection? Lots of systems had networking and floppy drives. Fewer systems had networking, floppy drives, and an application that was written with security in mind. I'd be more worried about how old the software that was used to process the floppy-provided files was, because if they didn't update the hardware requirements, they may not have changed the software. Keeping in mind that the software was probably written in a time when, even if you did use encryption, it was something that can probably be cracked in seconds nowadays, I don't think my concerns are groundless.

".int sounds okay to me, as it's very unlikely to ever be requested as a new gTLD."

The problem is that .int is already a GTLD, one of the relatively early ones. It's for international organizations, and it's quite strict about it. For example, the official website for the United Nations is un.int. The EU has a few of them, but they usually redirect to something.europa.eu. In practice, it's not as likely to cause a problem as using some other existing domain you don't control just because it's quite difficult to get a .int domain so it's unlikely that any other system will exist and your DNS request will just fail, but still, not the best idea.

Re: "DNS, however, can't prevent internal use of ad hoc TLDs"

Two reasons. Mostly that the land rush has come and gone. When lots of people were buying up names, there was more of a chance that that would happen, but many of those names have not proven to be the commercial blockbusters the investors were hoping for and they're busy hosting cheap domains for scammers and the occasional domain hack, but not even a fun one as was done with two-letter TLDs. Some of them have even been shut down entirely. I don't think people are still hoping to throw money into that.

The second reason is that ICANN already decided that some TLDs were not to be reserved. Back in 2018, they put several TLDs on the never list because some internal systems had used them. If .internal was already used frequently, I would expect ICANN to reject the application should someone try to reserve it after all. I don't have any objection to them doing this, but it's weird for them to make it sound like they've done a lot of work when they have no technology to set up.

Re: "DNS, however, can't prevent internal use of ad hoc TLDs"

No, it's not, because they actually do use most or all IP addresses. If we hadn't reserved the 10.0.0.0/8 block, some ISP would have asked for and been granted it, and we wouldn't be able to use it. In addition, it's quite intrinsic to the way networks are used that IP addresses be available for local use without having to request them from someone else, and private addresses permit this.

Let's consider both aspects with the .internal name. Nobody has requested .internal, and it's unlikely anyone would given how many new TLDs have been issued. Any TLD that does not exist can be created without registration, will be dropped by public DNS, and can be filtered by internal DNS infrastructure.

Re: "DNS, however, can't prevent internal use of ad hoc TLDs"

Theoretically, this could happen. Equally theoretically, they could already do this for any number of names. They could be configured to look for *.internal.companyname.co.uk and drop it. They could be configured to drop any internal domain the admins might set up and drop that. Either way, though, some admin will have to configure their internal DNS resolvers to know when they should be dropping requests that have not resolved yet and when to forward them on, and if they don't do that, the request will still go to the external DNS system. All this does is ensure that the external systems will reject it. However, since .internal didn't already exist, those external systems already would reject it.

Re: "DNS, however, can't prevent internal use of ad hoc TLDs"

Not even that. ICANN has, over years of discussion, decided to take a name and do nothing with it. A name they already were doing nothing with, that nobody had asked to use, and in a set of other names they've already decided to do nothing with. When this idea is fully implemented, nothing whatsoever will change anywhere in the world.

Re: I use....

It seems like a fine limit to me. We may not use anything that long, but having a lower limit wouldn't offer any advantages as far as I know. The 64-character limit also makes it possible to use some strange things, like the encoding of Unicode domains to ASCII. The longest domain name in use is .ファッション, which is in your expected range for length, but since it's in unicode, it's actually implemented as .xn--bck1b9a5dre4c. It's convenient that the limit makes that feasible, as a shorter limit would have required it to be truncated.

Re: Genuinely curious...

One option is that there was a script somewhere which used relative paths and moving the script somewhere else was harder than just linking in the data for it to work on. I've had the experience, in fact I'm having the experience right now, of a script that's not written well but it would theoretically be faster for me to work around its errors rather than going in and fixing it. For instance, a script I have which needs Protobuf and does not work with modern versions of Protobuf. If this were an important part of a system, it would make sense for me to rewrite the logic to use modern behavior, which shouldn't be too hard (I didn't write the initial version), but since I run it manually and on offline data once every six months, I just keep around an old copy of Protobuf in there.

Re: I, for one will not take 'advantage' of this

If they don't offer any non-app ticket options, they're already rejecting anyone who doesn't have a compatible phone. So yes, that might happen, but it's not like it's that new. I also don't think it's likely to happen because sideloading is confusing and that would prevent some people from buying tickets, so they'd like to decrease the difficulty as long as it doesn't decrease their control. Since Apple's store regulations don't prevent any of the things their apps do, I see little reason for them to want people to sideload them. Let's assume that I'm wrong about this and they decide to do it.

Their choice to do something inconvenient for you does not mean we should be barred from other choices. I'm a bit surprised that you're making an argument like that, since people can and have pointed out how the restrictions on apps create inconveniences for them, both users and developers, but you don't seem to think those are important. Why is your inconvenience any more important than their inconvenience? From a legal perspective, Apple's restrictions have an anticompetitive effect and ticket sellers, while quite annoying, generally don't restrict competition more by using an app, so the legal argument doesn't work in your favor either.