Posts by doublelayer

Survey: Over half of undergrads in UK are using AI in university assignments

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.

Critical vulnerability in Mastodon is pounced upon by fast-acting admins

Re: Trust Mastodon

You have it wrong. Other server admins can block you, not the devs*. That causes a problem, but it's not what you're implying. Since I don't use the system, I don't know how frequent that is, but at least describe it accurately.

* Technically, the devs could write the code to exclude you, but that's not what has happened.

IPv4 address rentals to mint millions of dollars for AWS

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.

Windows 11 24H2 is coming so we can all shut up about Windows 12 for another year

Re: 12

To be fair, they haven't said they're releasing Windows 12 any time soon. It's all been speculation about when they might do that and what might be in it. I don't expect it will be soon. While I'm sure it will happen at some point, it has only been 2.5 years since they pushed out Windows 11. That would already have been a relatively short gap between releases in the earlier versions of Windows (everything after XP, anyway), but compared to the seven years between Windows 10 and 11, I'm guessing the gap will be longer than average this time. Maybe 2026. That's also just speculation; while I think it would be a bad idea to release a new named version before then, Microsoft has done things that I consider bad ideas before.

Is critical infrastructure prepared for OT ransomware?

Re: Only a few percent of your military budget

That is probably true in the short term, but what you accurately describe as "drawing fire from the ransomware gangs" can also be viewed as training their abilities. If they didn't have plans to attack OT, as the article calls it, then Ukraine has given them a reason to learn how, possibly some incentives to do just that, and plenty of acceptable testing targets. If the war drags on long enough, they may have more of those skills and fewer targets in Ukraine on which to use them, which cannot be a good thing. Unless we're willing to hold the Russian government accountable whenever we're pretty sure that the attack came from a group Russia could break up, which I don't think our governments or, unfortunately, our fellow citizens are willing to do, we will want to reduce their skills and their ability to use them to make money.

Linus Torvalds flames Google kernel contributor over filesystem suggestion

Re: A better long-term approach...

You have misread it. The discussion there is about ways to replace open source with something else that would be easier to weaponize. Current open source is really quite difficult to treat that way; while Linus himself could probably prevent Red Hat from contributing to Linux, few others could do so unilaterally, and it would take a large group to do it without Linus's support. Should this happen, it would be possible for some group to fork the code and try to make that the canonical (little c) version. They might or might not succeed, but they have the ability and right to do so. There are some who would like more ability to control code to prevent people from doing things they don't like with it, but it is opposed to existing requirements of free/open source as defined by both FSF and OSI definitions and the licenses that implement them.

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.

Techie climbed a mountain only be told not to touch the kit on top

Re: Remote people might be right

If we believe the article, the problem that meant they should do something to this box was happening on a redundant box that was not customer impacting. This means that rebooting it shouldn't have dropped anyone unless the other box was also broken, and that they were doing anything at all suggests that the box concerned might already be in a state where it wasn't dealing with traffic. If the latter is true, then there's no harm in rebooting the box if the redundancy is set up correctly because the worst that can happen is that it still doesn't take any traffic. These are the kind of points that the staff should consider, and when they have, should be willing to explain. If I ask you why I shouldn't take a certain action, I expect some kind of explanation. Not just so I don't leave thinking you might be wrong, but so that I can remember it for the next time something happens.

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.

How not to write about network security – and I'm speaking from experience

Re: Goodbye OSI Layering?

The risk is that having redundant security measures on all levels of the stack means there are lots of ways for it to fail, and when it's working, it is likely significantly less efficient than it would be otherwise. If you, for example, do IP allowlisting on all the levels instead of just one, then when you need to change allowed paths, you need to work with lots of different network hardware. It prevents an attacker from easily adding themselves to the system from one compromised device, but it may make it so difficult to add anything to it that someone decides to turn it off. That's assuming that no device ever loses the configuration and locks out a device that should be listed, which can have even wider effects. Similarly, if you encrypt things at every level, you will probably end up spending a lot more money on networking equipment to perform five layers of encryption and decryption or spend less and get less throughput as cheap processors spend a lot of time on it.

You can do this, and there are some cases where you should consider it, but it strikes me as the opposite problem to the typical bolt-it-on side. The people who don't think about what they need, then try to have someone just take this code and add security usually don't get what they need, and nor do those who try to enclose everything possible in a separate layer of security and then try to make those things work well together. You have to take the more intensive and thorough approach of considering where you can put security measures before building the system that will have the most effect and the least impact on the other goals such as performance and ability to develop it well. You can add redundancy there as well, and in many cases you should.

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.

LockBit shows no remorse for ransomware attack on children's hospital

The previous extraditions of ransomware operators suggest that they already take them seriously enough to arrest them and send them to the US, which for some reason seems to be more involved in prosecuting them. I don't think changing the charge is going to increase that when the problems are often that they don't know the identities of everyone involved, so the list is pretty short as it is, and that the people on those lists are aware of it and tend to stay in countries where they're less likely to be extradited. It's pretty easy for, for example, a Russian attacker to know that if they've been named, the Cyprus vacations are out (they probably were anyway because of the war, but that used to be a popular destination), but you can still go to Dubai or the Maldives. Unless you think changing the charge will have an effect on those countries, I don't think it will do much.

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.

The FCC wants to criminalize AI robocall spam

Re: Some months ago I was downvoted

Benefit in the sense of real broad societal enhancement: nothing. Benefit in the sense that some person manages to make some money: definitely. It doesn't only include people doing illegal or unethical things, either. You could use some of this technology to make certain things more cheaply, for example using modern voice software to perform voice-over work instead of hiring a voice actor or using it to create images instead of hiring a designer. The voice actor and designer probably aren't happy with that option, but it does mean that the costs for whatever involves these will be lower, which may get passed on to you. The harms of unethical and annoying use probably outweigh this, but we don't get to choose not to have it. The technology exists and will be used for all these purposes whether we approve or not. Copyright claims may weaken the one that makes visual art for a bit, but probably not for long, and that's assuming that the side I think is right wins which isn't guaranteed with so much money involved.

Ransomware payment rates drop to new low – now 'only 29% of victims' fork over cash

Re: Time to ban paying!

My point was not that it wouldn't be illegal to do it, but that it would be possible to hide it. If law enforcement doesn't realize you did the illegal thing, they won't come after you. If they figure out that the illegal thing did happen, but you successfully get out of the charges by saying that your contractors did it without your knowledge, it also gets you out. Neither of those would be what the law intends, and, if proof that you did either existed, you would be culpable of a crime, but they are not that hard to do and hide. An audit would not necessarily indicate what actions were taken, just that someone was paid to resolve a situation and that it was resolved. There is no way for an auditor to know, from the payment to an established data recovery company, whether that company broke the law or not. That company, in turn, can run both a legitimate data recovery service and a ransom payment service. I think fewer companies will go through the effort required to do an illegal thing and hide that they have, but I won't pretend that none of them will. This does not change my opinion that a payment ban would probably be helpful on balance.

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.

Microsoft's vision for the future of work is you trusting Redmond to get AI right

Re: There are alternatives to Co-Pilot

Because, even with all that annoying crap, people aren't adopting Edge. The market share figures typically have it down near the bottom. While that doesn't technically prevent this from being ruled an anticompetitive action, it's unlikely to be brought up as one because it's clearly failing and thus it is hard to establish harm to anyone.

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).

It's true, LLMs are better than people – at creating convincing misinformation

Re: 676 sites (!)

"Embed top level domain reputation filters into browsers. Allow low reputation TLDs for experimenting developers, but keep them out of reach unless the filters disabled explicitly."

That won't do anything. to stop people from just putting their junk in an older TLD. I can get a .co.uk for pretty cheap. Sure, the name will be less clear than if I use the word of my choice because someone probably registered all the nice .co.uk domains already, but if you're blocking other TLDs, it can be managed.

Making the registration difficult doesn't help either. It might do something against scammers who like to quickly spin one up, run their scam site for about five days, then try to get a refund from their registrar, but sites intended to have misinformation stick around for a lot longer. It's also pretty easy for operators to just set up a bunch of domains, park them, and bring them online when they've got something for them to say.

Fairberry project brings a hardware keyboard to the Fairphone

Re: The Blackberry Passport...

Which, so far, I oppose for the reasons I stated. I have yet to see anyone explain how any of this is done without breaking most or all of the reasons why multiple messaging protocols exist. I thought that Liam, having expressed interest in the concept and having some technical experience, might have an answer to this. So far, if he does, I don't understand it.

The law as it's currently written basically just calls for this to somehow happen and doesn't explain how or give any criteria. As far as I know, nobody is taking steps to make it happen, and there is a distinct chance that they won't be able to manage it while keeping encryption working. I doubt that was the intended goal when the law was drafted, but I also doubt that the theoretical loss of end-to-end encryption will bother those who passed the law very much. It would bother me, which is why I'd like to see a suggestion on how to keep it and the various other advantages or the requirement reversed. I don't have a good solution myself, so I posted in the hope that someone else had thought of one and could convince me.

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.

Not the way I would do this

I admire the work that goes into something like this, but I have to wonder if the work might not be better spent making a different keyboard rather than using a specific model from an old device. I don't imagine that many Fairphone users happen to have that particular Blackberry around, and they're not cheap and plentiful on the second hand markets. This board will, for most users, provide them the ability to connect something they will never have, and that will only get worse if they do extend this to other phones.

Other open hardware projects have built their own keyboards, and I wonder if it might make more sense to try to do that or find a part that's currently in production. The creator of this hardware may be doing it because they do have such a Blackberry available to cannibalize and might not be focused on the ease for others to adopt it, but they've gone to a lot of effort that I'd like to see pay off.

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?

Elon Musk's brain-computer interface outfit Neuralink tests its tech on a human

Re: Why don't people see the bigger picture?

Their argument was not whether the technology could be significant to someone, but whether it is "the holy grail of human-computer interface design". There are a lot of technologies that are very useful to some people which mean little to others. Acknowledging the lack of general utility does not diminish its transformative effect on those who do require it.

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.

Japanese government finally bids sayonara to the 3.5" floppy disk

Re: What you are all celebrating...

You are mistaking two things. The first is that we're not celebrating it. I'm not mourning at all, but there is a middle area between sadness and celebration.

The second is more important. No longer using something obsolete is not erasing, dumping, or losing that thing. We have floppy disks and drives in archives, museums, online shops, all over the place really. We also know how they were manufactured such that, if we decided it was worth going into production again, it could be accomplished. It's not happening because there's no point, not because we can't. There is no benefit and some harm requiring people to use something ancient for a historical purpose. It won't prevent companies from no longer manufacturing floppy disks, but it will increase the cost and inconvenience of anyone who had to submit forms that way. It is also a good thing that you're not required to drive a Model T to get your passport, whether you decide to maintain one or not. There are many old things that we don't consider worth our time to maintain, and that is not automatically a bad thing.

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.

Cory Doctorow has a plan to wipe away the enshittification of tech

Re: Does old Cory know what he's talking about?

More that they were ridiculously obvious about it. While I'm sure people here have other companies they'd allege are making money by stealing, it usually takes at least one abstraction and has a contract in the middle. For example, Google makes money by stealing our data, but although I think that's true, they would argue that they have permission to get the data (I don't agree) and that they're only selling advertisements. Napster's business model was based around really obviously allowing people to download music they didn't have a right to download. They were only slightly less obvious about it than if The Pirate Bay decided to try to become big tech. You can't be that obvious about committing crimes if you don't want to get sued out of existence.

ICANN proposes creating .INTERNAL domain to do the same job as 192.168.x.x

$25,000 US per year, $185,000 for each one created, and a per-registration fee for successful domains.

".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.

One person's shortcut was another's long road to panic

Re: Genuinely curious...

I suppose you could try running your script in a chroot of the directory concerned, which depending on where the link was going might or might not prevent the program from going there as well. However, when you get to the point of involving chroot, you're also at the level where you could write explicit symlink logic. It sounds like this script had not gotten to either level.

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.

Amazon calls off $1.7 billion iRobot buy, blames regulators

I'm not sure it's an assumption. I think it's a stated opinion; he is stating that it's a fair acquisition and that regulators shouldn't have prevented it. Definitely an opinion, but not really a hidden one.

It's true that the statement doesn't give any reasons why it is a legitimate acquisition, but neither does your statement or those of others here state why you don't think it is one. The only explanation for why it's not is from the EU's statement. I somehow agree with them and still think they've gotten it wrong.

The problem the EU points out, that Amazon can restrict the online retail market in favor of its own products, is a real problem and one I think needs resolving. However, I don't see why it has much relevance to this particular product. Amazon can and, according to people who make products that Amazon's making as well, already do abuse their market position. That is a problem that will not be defeated by preventing them from buying a company that makes a different type of thing, so some effort should be spent punishing Amazon's manipulation and preventing them from doing it again. However, since Amazon doesn't make robot vacuums, buying a company that does won't, apart from that online retail argument, reduce the number of competitors in the market. On this basis, Amazon should be prohibited from buying any company that sells any product which could be purchased online. Compared to going after the abuse of their online market power, this seems like a bad plan for resolving it.

DEA nabs $150M from dark web drug lord based... in Coventry

Re: the resulting property search led to the discovery of multiple cold wallets and recovery seeds

They didn't say that they had found all the seeds, just that they found some of them. It was probably just a search to get every hard drive and SD card in the place, then looking through each of them for wallet keys or seeds. Maybe the criminal had other ones stored somewhere, at least I probably would have tried if I was a criminal with that much wealth from it, but they wouldn't know that if the criminal had been successful at hiding it.

The pen is mightier than the keyboard for turbocharging your noggin

Quote sounds wrong

I will admit that I haven't read the paper, only the article. Still, the part that they quoted sounds very wrong to me:

"As increased connectivity in the brain was observed only when writing by hand and not when simply pressing keys on the keyboard, our findings can be taken as evidence that handwriting promotes learning. Interestingly, the increased connectivity between the various brain regions seems to be linked to the specific sensorimotor processes that are so typical in handwriting,"

We have two suggestions that don't appear to have any proof. The first is that more connections means more learning. I don't think so. There are lots of ways to have lots of connections that don't involve memory or learning. You would actually need to test whether learning happened rather than saying that these areas activated, so let's assume that meant a good thing happened.

The other part of this is that the movements are linked to the increased connectivity, but that could easily be the other way around: the connections are present when writing, not because writing creates them, but because they make writing work better. For all we know, the connections are there so that the handwriting can maintain a consistent visual style which isn't necessary when you're typing and can change the font later. The point is that we can invent lots of possible reasons for that correlation to exist and, unless we have tested that sufficiently to eliminate other causes and establish a rule, it's supposition what the connections mean. They could test this by having people write stuff they already know, stuff that has nothing to learn in it, and stuff they are learning. Then they could test the former suggestion by actually testing whether people managed to achieve different learning results after writing in a different way.

Apple redecorates its iPhone prison to appease Europe

Not at all. It's a matter of position. Your perspective may be basically the same, but your ability to control the situation is a major difference. The strongest prisons will not protect you if you are a prisoner. They're not meant to protect you, but protect things from you. The people running the prison may choose to protect you, but it's not intrinsic to the structure.

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.

I'm a bit confused why the discussion of what is a computer has come up so much. However, the distinction seems obvious to me: does it have an operating system capable of and intended for installing and running multiple applications not provided with the operating system? An iPhone definitely is. Your car and washing machine are not. If you wipe out the firmware of either and install what you like, then you can try to use them that way. The car may be capable of it, though it's almost certain that your washing machine is not able to be used that way.

Re: I think I disagree, but I’m not sure…

So your definition of computer is "it's shaped like other computers"? An iPhone is a computer in every way. It has a general purpose operating system intended to run other software, with the facility to load that software at runtime (as opposed to baking it into the firmware in order to install). Its screen may be smaller, but why would that make it not a computer? It may also have a phone capability, but why would that prevent it from being a computer? Your definitions confuse me. I'm not sure that being or not being a computer is the relevant point here either.

Competition is decreasing in enterprise IT – and you’ll be poorer and dumber for it

There is a reason they do that when they do, which I think you've overstated. They're requesting it because VCs tend to want the companies they invest in to scale really rapidly. Sometimes, that's a viable approach, sometimes not, but the VCs generally expect it. This means that, if you get a hundred times as many users next month as you have this month because you spent the money on a very successful awareness campaign, the VCs really want you to be able to handle that. If your infrastructure isn't up to the demand, it takes a long time to scale it up. You have to get equipment, configure it, and set it up, but perhaps more importantly, you need the space to store it, the ability to power and cool it, and those things take a long time to expand for a startup that probably has one small office, not their own private datacenter. Even colos won't be able to instantly provide a ton of space overnight.

A startup that can convince VCs that they can scale up without having to buy a bunch more infrastructure can probably get around this, but if that's not something the startup techs are willing to promise, then the investors will ask about using cloud for scaling potential.