Posts by doublelayer

Supreme Court to hear TikTok's appeal against law that would force it to shut, or sell

That principle doesn't work. Otherwise, why couldn't I, who control a majority of the seats in the Congress, simply ban any site that doesn't take you down if you post things I don't like. You are allowed to say whatever you want on the sites I allow to exist. It's not my fault that most of those choose not to let you say it?

Whether that's a valid argument against this is another question, and it is not the legal argument I would have guessed to be their best option. Then again, I'm not a lawyer, and I assume they've got several who came up with this plan. If it fails, it won't be your argument that does it. The ease of abuse from an interpretation like the one you've made is too obvious unless you're planning to set up a dictatorship.

Don't fall for a mail asking for rapid Docusign action – it may be an Azure account hijack phish

Re: Can these attacks trigger a browser to supply the credentials?

It depends on the quality of the password manager in question. Most of them store passwords with a specific domain name, so they won't autofill if the domain is wrong which it is in this and most other cases. Some more basic ones just give you a menu of passwords, so if someone's using one like that, it's back to hoping they don't take the manual actions necessary to put it in. There is also the third option of a site that is so convincing that someone manually overrides their password manager to fill in the password it wouldn't do automatically, which is possible.

As for the victim assuming a broken link, most phishers have found ways to deal with this risk because they want to have access long after the victim provides the credentials. Popular tactics include:

1. Using those credentials to make an active session and redirecting the user to it, most complex, but sometimes the most convincing.

2. Direct them to a page giving them some ostensible result of the lure you gave them. For example, if the lure was saying they got charged for something, give them a page with a cancel button that makes them think they've done what they had to.

3. Just redirect them to the real login page for the service, and they will assume they entered the password wrong and try again, gaining access to the normal thing.

$800 'AI' robot for kids bites the dust along with its maker

That's a bit of an oversimplification. Many maintenance costs are not linear per device. For example, if they were going to have some developers write a new feature that runs on the device, then the cost to develop that feature is the same whether they run it on one device or a million. There are some costs that scale per device, like support for the new feature, but the highest one is constant. That means that maintenance cost is very different depending on how many of those you sold.

A company like this, though they probably did operate in an environment where they knew they wouldn't be able to continue, does not have fixed maintenance costs that they know about when they sell the product. They have estimates, but those can be wrong in several ways. I have a feeling their estimates didn't indicate that they would go bankrupt this quickly. Either they did and someone took all the money and ran with it, or more likely they thought they would be able to continue this for longer than they actually could.

You're right in theory, but every idea has to make it past the ideal stage and the practical stage. My comments are about what I think will happen if someone tries to put that into practice. A lot of small companies start with an idea which they think will be profitable in a couple years, but if they have to pay for ten years of costs before they can sell a single item, they're not going to be able to. I think the first two options I described are how those companies that survive this will deal with that problem and the third one is how those companies that didn't start because of it will kill it.

The idea isn't bad, as it significantly reduces the risk to the purchaser of an item. It comes with the theoretical downside of companies that would be able to stay solvent not forming because they can't afford the bond they're required to have, and we could debate whether it is worth that. I'm afraid that, even if we decide it is, the bigger problem will be in evasion and avoidance to say nothing of getting it passed in the first place.

It's possible. Many times, things like this fall into two groups, with almost nothing in the middle:

1. Everything goes in plaintext to a single server, possibly a Raspberry Pi, which responds back with simple responses with no security anywhere.

2. Everything is encrypted so nobody can repurpose the hardware, because if they repurposed the hardware, that would result in effectively free money because they just bought your hardware, cut themselves off from your recurring costs or you have an excuse to cut them off if you need to, and invalidated their warranty by replacing the software so you don't have to repair it if they break it, and we just can't have that.

Re: Subscriptions?

They won't. They've existed for as long as ongoing costs have, and they will continue to. The important thing to me is that companies be required to be explicit about the existence of subscriptions. If they tell you about a subscription up front, you can decide whether to have the thing or not. The problem comes when they don't bother to tell you, but they impose the restrictions on you anyway.

Re: Subscriptions?

Quite frequently, the price of the servers isn't high enough to concern them about this, because they can afford to run the servers quite a long time from a high purchase price. What they can't afford to do for as long is continuing to run the rest of the company. At the end, they don't have the money to run the servers either, but it wasn't the servers that did it. That's often how the calculations arise. When the server costs are high enough that it's appearing as a primary concern in the financial plan, they tend to make the subscription part of the product by default, which doesn't guarantee that they'll stay solvent either.

Some things work really easily with that model. Unfortunately, there are many businesses that take software that can run just fine on the computers their users already have and insist on running it elsewhere anyway for extra lock-in potential and data to mine. However, some things work not as well and some things hardly work at all. For example, I don't know what this AI bot did, but I'm guessing it was running some large bit of software, maybe even an LLM. Building a robot with an LLM running locally in it is possible if you don't mind the robot needing to be tethered to a wall and coming with some fans, effectively a desktop computer in a fancier case. If you want something small or mobile, you will probably not have enough processing power to run something that big locally, which is why you would connect it over a network to something running the software. Most buyers aren't willing to have that something else be a separate machine they have to store and keep online. This type of preference tends to make a lot of companies with hardware like this run that software on their servers. This is in the "not as well" category, since it is certainly possible but it is unpopular.

Other services work even less well on a local computer. Generally, these are ones which rely on a lot of public access to something where self-hosted solutions work fine if you have the resources, primarily fast and unlimited home internet and the ability and willingness to be your own system admin. If you don't have those things, they become security holes, maintenance nightmares, or undeployable because public access also cuts off your ability to use your connection. This is where the challenge becomes harder and where new techniques are tried to try to make it easier for people to deploy. Not everything falls into the first category.

Which will mostly not work because small or startup companies can't pay ten years of maintenance costs in one go. We might prefer that those which cannot just don't operate in the first place, but we don't get to make that choice. Instead, this situation will be resolved in one of three ways:

1. Companies will specify a lower maintenance cost, for instance, just the cost to run the servers on which the code runs, but not updates to keep the code working, get updated data on which the code relies, hardware repair, or paying necessary employees. If they go bankrupt, the group that inherits the bond is going to find that they cannot possibly run with the funds they have. They can use the money to provide full support for a shorter time or to run some basic, partially functional support for the specified time. Either way, the users and the new operators are going to be disappointed.

2. Companies will find a way of not complying, for example acting as a local subsidiary of a different manufacturing company, even if they actually designed the product. If the law doesn't allow that by putting the costs on the local sellers, then they may instead try to have the product sold by something operating internationally. Either way, unless the enforcement is strong, they can find ways to not comply, and by the time that people are checking whether they did or not, it is too late. This happens to some extent for nearly any type of regulation, but one that provides ten years of costs is so expensive that evasion is going to be really popular.

3. Companies will argue that the bond requirement is restricting innovation and get someone to remove that requirement or limit it in a way that is easier to comply with because users aren't getting a lot.

I'm guessing that there may be more steps required to take these over than grabbing a domain name. Without their backend software, which I doubt they're releasing, you might need to put a lot of effort into reverse engineering their protocol and building your own backend, and that's if they haven't included some burned-in encryption keys which could make it infeasible.

Even Netflix struggles to identify and understand the cost of its AWS estate

Re: Competition ?

Depending on what you're doing and how it's architected, those services can in fact be a competitive option. Specifically, if you would ordinarily be buying normal VMs from the big cloud providers. If your AWS bill is just EC2, S3, and bandwidth, or for the sake of not having a monopoly in this sentence your Azure bill is just VMs, storage accounts, and bandwidth, then these other companies can probably be used in the same way without too much difficulty. If there are more things on that bill that you intend to keep, it is not as easy.

The large clouds aren't just renting out servers. They're also renting out lots of software running on those servers. That software is used to develop and scale things. You could build similar functionality yourself, but development time and financial costs increase and inevitable bugs become a serious problem for those developers. Larger companies often have the resources to do that themselves and small projects often don't need it, but the medium-sized products are where there are significant reasons why people choose to design with those features, and sometimes those medium-sized companies become large ones and, although they may well eventually build it all themselves and stop using the cloud providers, they have enough inertia that it takes a long time to do so. Managed databases, functions as a service, notification systems for distributed applications, load balancers, and many other things are popular with some people. Individually, you don't really need the cloud provider to charge you to run each of those, but if you're using a lot of them, it can be costly to do it yourself. If you're running the servers in your own building or renting them from an IaaS company like the ones you mentioned, you are still doing that part yourself.

That's almost certainly one of the costs. It's the cloud equivalent of "What's that server? Does anybody know? Has anyone logged into this thing in the last five years? Could anyone log into this if we needed to?", but you pay every month for the server, not just the power and cooling.

Re: Then... there are the 'exit' costs

I don't think they're relying on AWS for storage of important things. All their video assets have copies on their self-built CDN nodes, and almost certainly on massive storage systems that are at a scale where renting them doesn't help. The pain in trying to leave is taking all the services that are built on AWS components and trying to run them somewhere else. That doesn't happen if they only rented IaaS with everything custom above that, but from their description, they use other services that you can't easily just move. For data egress, the stuff they would have to pay to copy is likely a bunch of logs of every customer's every action, and those are probably quite large files, but not compared to all their videos.

Re: accounting codes

Oh, that happens. That's how you have companies with a hundred AWS accounts for each division. Sometimes, they also separate dev, test, and prod into different accounts, so make that three hundred. IAM becomes a headache then, but I think IAM is nearly always that way.

Re: Amazing

It doesn't take a massive service to predict the bill. It takes a massive service to figure out where all the bill came from. To some extent, that's not unique to cloud services either. The thousands of different products that AWS or someone else offers makes it a bigger task, but you can have hideous snarls with any other large system. Trying to figure out who is using what kind of server resource can be complex even if you own the servers. Either you have clustered them and individual teams can provision resources, in which case you know when you're taxing them and need to expand but you don't necessarily know how it is being used or how necessary each load is, or you require them to plan this out for specific machines, in which case you know what everyone is using but it makes each increase in resources a drawn out process whenever teams need to expand.

The sweet Raspberry taste of success masks a missed opportunity

Re: Print #X where X is channel (file descriptor, window number).

Your question about similar results confuses me. My objection to Scratch is that you can't really get results because, unless you write JavaScript for it, all you can do is move pictures around the screen. Of course, they've attached that to lots of concepts used in programming so you can choose to move a sprite as a result of a mathematical or logical operation, but your ability to build something else is hideously limited. Unless all you ever want to do is move sprites, you will need to do something else, and as with many graphical, block-based "languages", the limitations on what is possible are so severe that trying to teach those operations through it is more difficult than it would be using a language like Python.

As it happens, a book I learned Java from did indeed have a graphical thing because they also thought I might like to move some pictures around. I remember making it into a sort of game with their sample code handling graphics rendering because, unlike Scratch, I could take user input while the graphics moved. It wasn't a very good game. That was, admittedly, after writing many programs that were text only and I was 10-11, so somewhat outside your age range. That doesn't make those languages the best choices for everybody, but it is at least partially why I wouldn't automatically consider them unsuitable.

And your other question, neither of those libraries. I was self-learning things from books, websites, and an older child who agreed to teach me a couple things, so it was quite unorganized. The standard libraries and later, the proprietary example code out of a book was what I used to start with. There are certainly ways to do it better.

Re: Print #X where X is channel (file descriptor, window number).

The major difference between Scratch and Python as choices is that Python can do things and is used elsewhere and Scratch can't do anything useful and isn't. That is why Python is an acceptable choice and Scratch is not.

I find Python an acceptable choice. It has some downsides, notably its approach to typing. A language that requires you to state your types avoids confusion. If they used something like JavaScript that lets you treat any type as another type and doesn't complain, at least they'll get something out. Python's lack of explicit type declarations while being strict about what the types actually are can be a point of confusion. While I think this slows down the process a little, I don't mind it as it means they're still going to learn things. Python also has the benefit of letting people write useful software using a lot of libraries, so that is one thing in its favor. I think you assumed that I was a supporter of Microsoft's Basic thing, when in fact I have never used it and think it probably doesn't meet my standards. I just think an object-oriented structure is totally fine to have in an introductory language.

That doesn't make other languages difficult to teach people. I first learned C++ and Java. It was not hard to start with the idea that all my code had to go between the "public static void main() {" and the "}". The person explaining it to me managed to make me understand this very quickly: "The program runs the code in the main function first. Functions are a way of having different pieces of code which you can reorganize. Right now, you won't use more than one. You'll write multiple functions in two weeks." And I did. It wasn't hard to explain the concepts. Public and static got explained later. That was an informal instruction from a friend. A teacher can probably do even more.

Re: Print #X where X is channel (file descriptor, window number).

"In every other area of education you start small and build on previously learnt knowledge, so why should software be any different from that?"

Because many of the starter languages, probably including this one, have annoying limitations which hamper the education process in two ways:

Right up front, they can be incapable of some task that an actual language is capable of. If a student wants to write a program that actually performs a task but their language is incapable of it, it puts them off. If they are incapable of writing it yet because they don't know enough, then they can either be motivated to learn more so they can or someone more knowledgeable can abstract out some things for them. If their language just can't, they'll get frustrated by knowing that their tool will never do what they're trying to accomplish. It's not just that most of the things you do with Scratch involve moving a picture around the screen, but people may discover that that's all they're going to be able to do* and lose interest.

After that, you're making them start over and learn a language that gets actual use. If you taught them well and maintained their interest, they will have transferable skills, but they're not yet at your or my level. For us, learning a new language is probably not a big deal. The syntax will not take very much time, and we'll learn the standard libraries as we get to them. That's not the case for someone starting out. They've learned one language, and if it's Basic-inspired, they'll have learned a language that teaches them some harmful habits. I'm with Dijkstra on goto, and Basic tends to use it frequently. Even without that, students are learning a lot of things that were deliberately left out to try to simplify the language, but if that simplification actually resulted in cutting out the ability to do things and removing good program structure, it is not helping as much as it hurts.

* Technically, you can add some of your own behavior in Scratch. However, this isn't supported by the normal server, and if you are doing it, you're just writing in JavaScript.

No, that's not what it is called. You know that already, I think.

Whether I can replace things is not related to whether GNU tools are in there. For example, OpenWRT lets me access any part of the system from the bootloader on up if they can, and they usually can. There are no GNU tools in it. You can also have GNU tools atop a Linux that I can't replace with firmware that's been locked down as long as those tools can be replaced. You also seem to have your GPL V2 and GPL v3 mixed up, since it is v3 that requires installation information and Linux is v2. You also blame Linux developers for allowing people to violate the license (for a violation that isn't possible) when those violations that do exist are not due to any failing from the developers. It's true that the things V2 requires of device manufacturers are sometimes, even often, not done, but it is those manufacturers that are at fault.

"What on earth is a "full Linux environment"? - you either have Linux as the kernel, or you don't"

I grant that it's not a technical term, but what it usually means, and what I'd appreciate a term for, is a Linux environment in which you are allowed and able to modify things with ease. Primarily opposed to boards or devices that run Android, where there's most definitely a Linux kernel under there, but you first have to wrestle with things to unlock the bootloader, then manually make or patch something so you can replace it, then any attempt to remove mysterious things causes the device not to boot anymore, and only after you fix those three things can you actually start modifying the environment. To some extent, it also means that software intended to run under Linux can run on the environment, which offers a variety of options for how severe you want to be.

Re: Everything has become so complicated

I granted them that having to set up the window themselves would be a problem, but their one line looks nothing like the one you made up. It is much more similar to your three acceptable versions with the difference that "TextWindow.WriteLine" is more bytes. It's still one function call with one parameter which, according to them, didn't require extra setup. Also, I don't like your options equally. Print is a common one for that. Write can work, but since we're also going to have functions for writing to files called write, it doesn't make sense for a global function called write to guess this for us. Type is a terrible name because a program does not type a message onto a console.

The problem with your example is that you insisted on adding irrelevant things when the things we're actually considering don't have them. Yes, to teach someone the basics of programming in C, you have to include something and have a main function before your fprintf(stdout, "Hello") works. However, the function they are writing takes only two parameters and they can and should be explained. What standard output is does not take a lot of technical knowledge to get across to a student. It doesn't require you to fiddle about with locales or memory allocation errors or any of the other specious examples you care to include.

That doesn't mean you have to start with C, and I generally wouldn't recommend starting with it. I advise against it because, after they learn some basics mostly involving calculating and printing numbers which is about as easy in every language, they're going to want to start doing some small useful things. C makes most of those things hard and can put them off when they find it difficult to achieve anything they want to do. Python is popular because the vast number of libraries makes this simple, but several languages, can also do it. From your list, I would say that C# is relatively easy to do and Java can be used although there is a lot more boilerplate and JVM work that they will need to simply trust at the beginning which isn't ideal.

Hobbyists have done both of those things. I have done both of those things. The small Eee PC was well-known for having internals ripped out to serve as brains for something else. It isn't ideal, which is why the Pi was a popular product. Industrial users tended to get products which were similar to a Pi, but more custom and thus more expensive. In both cases, the availability of SBCs improved the situation, but it did not invent something that nobody had ever seen before. That improvement is why SBCs are going to continue to be made, even if the Raspberry Pi people somehow failed. However, it's not correct to say that it took three decades to get it (I'm also not sure what we had in 1982 which started that clock). It's as inaccurate as saying that we didn't have smartphones until Apple made the iPhone or we didn't have digital audio until the MP3 algorithm got written. Those were improvements but not the first version of a technology.

They did say that, but that was not the only thing they said. They made a specific claim that Office files could not be opened in things other than Office and then claimed that this was the case because Microsoft deliberately designed it that way. The former is false, as demonstrated by the fact that LibreOffice, whether people choose to use it or not, can in fact open, view, edit, and save documents in those formats, as can Apple iWork, Google Docs, OpenOffice in whatever state it's in now, and several other programs. The latter is also false, because Microsoft could, subject to legal risks, break those formats and prevent software other than theirs from reading them.

"once you've been locked into the office/windows monoculture, thats it. thats all you'll use, again because m$ make sure that stuff created in office can only be opened in office."

How little credit you give LibreOffice these days. I thought it was mostly Microsoft fans who thought it couldn't open anything. In your zeal to condemn Microsoft, you are not giving LibreOffice and other tools the credit they deserve for opening most documents just fine, but you're also just being wrong because the Microsoft Office formats are relatively open and static such that they are relatively backward and forward-compatible and can be opened by lots of software.

Re: Everything has become so complicated

Oh no, they turned one line into one line. There's a good reason to have syntax that works like that: it lets you handle lots of objects instead of having only commands. Having one print command is great as long as you only have one place where printed text can go. If you have a GUI, then being able to say things like StatusBar.WriteLine or Button.Label.WriteLine or AutofillOptionBox.WriteLine are useful. Not just useful, but effectively required, so teaching students about functions has a reason to take precedence.

If the hello world program required setting up the text window first, you might have a valid complaint. In the absence of that, I'm reminded of the people who thought it was terrible when Python changed "print string" to "print(string)". Sure, you might prefer one syntax over another, but is that really the most important part of language design to you? The syntax of Basic-type languages was built for constraints different from those we work with today, which is why new syntax, for example the common C-derived syntax, is more common.

Re: Cheap

Since the Raspberry Pi components are priced in dollars, I'm using those.

Pi 500: $90

Power supply and peripherals: included with desktop kit, increases above price to $120

Pi monitor: $100

Raspberry Pi 64 GB SD card: $12

Total: $232

Unlike the $90 Chromebooks, which exist but I wouldn't want to use them, $232 will add many options to the list, options with better specs. They also come with a useful feature: portability. People like that. If we tried to make the Pi portable with a battery, we would have to spend more to get a battery and we'd still end up with a much less elegant package.

The Pi is cheaper only if you have some of those things already.

"The Pi is great but what makes me worry is why we had to wait almost three decades for something like it to come along."

Because, for all of the Pi's advantages, it's not like you couldn't do the same things with a laptop. Once Linux got mature enough that it mostly worked on hardware you had access to, you could use a laptop with the same software the Pi had. It didn't work so well for RISC OS because RISC OS had, and still has, a lot of ARM assembly in it which doesn't work very well on anything else, which is why it also doesn't run on most ARM SBCs out there either. Most other things were as or more functional with hardware available to the hobbyist, with the largest exception being the convenient GPIO pins and hardware designed around them. The former were available but more expensive, but a lot of the convenient peripherals were only made after the Pi proved that people were willing to buy them.

Many interested people were building systems around old computers running Linux or BSD before they got a Pi to make it quieter and smaller. Others would take embedded devices, often old networking gear, and hack those to make them a platform for things that worked under resource constraints.

As for the future, I think it's been clearly demonstrated that people use and are willing to buy SBCs. If the Raspberry Pi ones somehow crashed, it wouldn't stop the many competing manufacturers. They all provide at least the basics of a hobbyist-available board with a Linux base. Some of them do a better job than others at having updated images or mainline support (Raspberry Pi tends not to), and if Raspberry Pi ceased operating, then one of them would likely try to move into their market and succeed.

Re: Everything has become so complicated

"Compare that to now."

"Throw some general purpose programming language on top (C#, VB.Net, Java etc). All of a sudden you have this massive amount of knowledge needed just to get started"

No, you don't. You have a lot of things to learn to understand others' code, but simple code often remains simple, in fact, often simpler than older languages. Basic and variants made simple programs simple at the cost of making complex programs maintenance nightmares. Not that people can't still use Basic, but they tend to use the languages that others use in production.

"Then you have to work out how to make the Linux firewall open ports."

As compared to before, where you didn't have to worry about that, free of the responsibility, because you couldn't write a program that would interface over a network because your computer didn't have any networking. The complexity involved, which mostly is going to involve one line, is directly related to having features which weren't available before. Eventually, the student will learn what happens when they type "ufw allow 8080", but there isn't much complexity when they learn how to perform the action.

Re: Cheap

More useful, yes. Someone may be along to argue the utility of the Chromebook's Linux mode, but I'm not going to be that person. I'd much rather have a Pi 500 than a Chromebook.

Cheaper, no. Chromebooks can be really cheap. Some can be less expensive than the suggested $90 US retail price of the 500, though I'm guessing those are not very fun to use. Even when they're not, it ends up being similar, because you still need other things for a 500 to work. Add in the cost of a high-current power supply, sufficiently large and fast SD card, and display, and you've possibly doubled your costs. You may have some of those things already, but since the Chromebook includes that and a battery together, cost comparisons that compare like with like are going to include them. Some people who are considering a cheap Chromebook will not have an HDMI monitor just sitting around because they didn't have a desktop before, and while they're more likely to have an HDMI television, that's not their desired workspace setup.

"what do you think a Raspberry Pi does better than a second hand ThinkCentre at half the cost?"

To me, the primary advantages are size/heat/noise, availability, and versatility (of a specific kind). The first one is easily explained. A Pi is easier to fit somewhere because it doesn't need a large footprint or a noisy fan and it doesn't make power usage soar.

Availability is one of my primary disagreements with you. I don't have lots of secondhand desktops at half the price of a Pi. I assume you're using the normal retail price of one, as opposed to the scalpers who still have their aspirational prices but don't sell many, but at those prices, about £/$/€25-45, the secondhand machines I can find are mostly unimpressive and old boxes which would probably work fine, but would not be very efficient.

Versatility is one I need to explain a little more. Of course, most of the things you can do with a Pi can also be done with a normal machine. The ease of switching from one environment to another, though, is something I find useful. Sometimes, if I need a temporary machine and would like more hardware access than a VM would provide, I can just take a card out of a Pi, use a fresh one for my temporary purpose, then put my old card back and that machine resumes its previous purpose. I can do the same with another hard drive in a desktop, but the convenience is a little lower.

Depending on what you're doing with it, it is possible to write too much to cards. People do that all the time. I'm not sure how successful your ramdisk approach would be for most people because, until the Pi 4, there wasn't a lot of memory to spare, and even with that, reserving lots of RAM for ephemeral storage will often limit the ability to run software that would otherwise fit well into the Pi's resources. I think their criticism is flawed, and yet your method for avoiding it is not very functional for most users.

Re: BBC Micro..

"And yet the BBC went for the micro:bit instead. Really don't understand that."

It's the rather common tradeoff between low-level and high-level. Some, like me, think programming education works best when you start with something that looks like the environment in which actual programming is done. That means that students get full operating systems, languages that get used in production, and we don't stop them from using libraries. You could describe this as top down, where it's totally fine that their first program that accesses a remote server uses someone else's libraries for HTTPS. They can and will learn later how that library did it. Before they are professional programmers, they will have to build their own subset of a TCP stack, enough that they could build a fuller one from the specs if they wanted to, but I'm not going to make them start there before they can use the network.

The other option is bottom up, where students are given small building blocks and they should put them together. It should theoretically give them a better understanding of how and why everything works at the cost of limiting the kind of things they can build with only a little skill and experience. The Micro:bit is designed to make it relatively easy to do basic things without giving them an OS stack, and it is closer to a bottom-up tool with some simplifications to try to eliminate the most annoying aspects of that philosophy. It is not my favorite approach, but they have a reason for it.

"I would love to see a BASIC interpreter capable of interacting with web data courtesy of an extended command set (BBC BASIC was ported to the PC)."

You could write that without too much difficulty, but you will always be chasing the power of other languages. You can easily make an HTTP_RETRIEVE command that fetches a document, but are you going to make them parse the JSON themselves character by character? Or will we have a JSON_DECODE command? When they want to do something that's not HTTP, are we building in specific commands for different protocols or should they POKE their data through a socket? A lot of languages are more complex semantically because there isn't enough structure to give you the power you need there.

"And games produced in assembler."

You can if you want, but I don't know why that is a goal for you and I'm not sure you understand the problems likely to be encountered by those who try it.

"A PC case compatible mobo would have made it easier for people to build out their own Pi PC. And a PC equivalent needs better advertising so that non-geeks can buy them."

What it needs is a reason for others to buy them, and especially if you don't like Linux, I'm not sure what that reason is. People can install Linux on machines they already have, but they don't. To convince them to buy a machine that can't run the things they are choosing is harder. To do that when you don't even have Linux, with existing GUI applications that do the same things as the applications they want to use, means that, even if I pay for all your advertising, you have to include in the adverts an explanation of why "non-geeks" would buy it. I don't have that answer, and I'm not seeing it in your proposal.

Just how deep is Nvidia's CUDA moat really?

Re: Antitrust?

They could try, but it likely wouldn't work. There are already open standards. Someone mentioned OpenCL. That's still around, there's your open standard, and the chips already support it. Every manufacturer can claim compliance on that. It's not their fault that people are not writing for it. Having an open standard doesn't do anything if people choose to write for the closed versions. If you try to forbid the closed versions, then you'll get a lot of complaints from all the people whose code you've just disallowed if they don't just ignore you.

Nvidia upgrades tiny Jetson Orin Nano dev kits for the holidays

Re: The advertisement lacks some details

You could check these things. Let's take your questions out of order:

"Does it have digital handcuffs that stop you from replacing the proprietary software with free software?"

Good question. That kind of thing can be really annoying. The answer is: no. You can erase the firmware, which, unlike things like the Raspberry Pi, is a standard UEFI version, and write whatever you like in its place. You can also write any operating system you like to the boot media. There are docs for both. That means that, if you have software of your choosing which can handle the hardware, you can run it.

"Can it be used without proprietary software?": Define used. I can take out the software they include and it looks like it will still run an OS of my choice, but not all the options of the GPU may be available to me depending on the status of open source drivers. I don't have a board, so I don't know the full list of things that only work with the ones they wrote. The license they have on the main components is not an open source license, but it is freer than you imagined. If I don't use that software, I can still do things with this board, so by that definition, yes it can be used. I might still be better off with a different board because why spend the extra money if I'm not going to use what I'm paying for?

Coder wrote a bug so bad security guards wanted a word when he arrived at work

Re: You can't write a bug

Of course you can write a bug. I can agree with your definition that intentionally writing something that you're going to say is a bug is not "writing a bug", it's writing an intentional flaw. However, writing something that has a bug means you have written that bug. You just didn't want it there. In the same way, if you're an author and write an inconsistency in a work of fiction, you probably didn't want it but you still wrote it.

There are three options that would have spotted this. I don't find it implausible that one of them happened. In decreasing order of how ideal it is:

1. Someone manually checks a couple basic things, such as the weekly total, and when the weekly total started having a billions digit and probably a tens of billions digit, that person alerted others.

2. Some software has a feature to detect things that are unusual and flag them for review. When they noticed a customer's bill jumping by orders of magnitude, they pinged someone in the finance department to confirm this and the person alerted others.

3. Everything was automated and there were no checks until the payments got to the bank. Banks manage large amounts of money but what they probably don't manage many of is any payment that looks like a recent Unix timestamp. If you really are sending or receiving over a billion currency units in one transaction, they are probably handling that much more manually. So when they started receiving such things, they block the connection and have someone on their end review it and contact the company.

It's not surprising that this got detected. If you added 10% to every payment, you could avoid the safeguards and have a situation that only the customers notice is wrong. When you're charging billions, you don't need very good safeguards for them to go off anyway.

Re: Defects appearing like magic

I think the original order is correct. A schemer may try to create schemes of their own, but when someone deliberately sets up a set of incentives, often with a balancing set of negative consequences, lots of people start to scheme their way around it. If you have a schemer, you'll get their schemes. If you have your schemes, you'll find that lots of schemers start appearing, even from people who you don't think of as schemers. I've certainly been a schemer in such scenarios, finding ways to optimize odd circumstances to my benefit, though in my mind always in a way that didn't hurt the people creating the scheme.

Re: Defects appearing like magic

Yes, but the developer was probably planning on people not checking. As the comment demonstrates, they weren't even smart enough to match the timestamp to a plausible discovery time, so they would also be either unaware that the history could catch them out or assuming that the people wouldn't check the history. It probably worked the first few times. If I had reported something and someone told me it had already been discovered, I'd usually believe them and be reasonably happy because they're already on it and I don't need to do anything. Only when it became a pattern would I wonder about the history.

Jury trial kicks off Arm's wrestling match with Qualcomm

Re: Screw loose?

I'm pretty sure both of them started this process with exactly the same assumption, I.E. Qualcomm assuming that they can violate the terms of the two licensing agreements because ARM needs them and ARM assuming that they can charge a lot to give them the needed licenses because Qualcomm needs them. Of course, that only works if they eventually figured out a solution, which was apparently not something they are very good at.

Guide for the perplexed – Google is no longer the best search engine

I hope your results have been better than those reported by others. Many posts have included examples of queries where the wrong answers and poorer results have been returned.

I ran some tests of my own. The first one I tried was looking for information about updated firmware for a device whose manufacturer isn't great about telling people when they've updated the firmware. If I search for information about whether an update has been released on a normal search engine, I get updates, but not necessarily the latest version. Let's see if perplexity is better at finding such things. The result is... no. It simply refuses to find any information or sources at all and makes a generic suggestion that I look at the manufacturer's website. It doesn't even tell me where that is. Not a great result for test number 1.

Test number 2 involved a search for details about a product. Company A produces products 1 and 2. I am using product 2, but it doesn't have as many options as product 1. Can Perplexity tell me what options I have as a user of product 2? The result is... no. It confidently told me that product 2 had options that are only present in product 1. The source it cited for this was the documentation for product 1. It did not cite anything related to product 2.

I then tried something simpler, looking for a specific answer that's easily found on several sites. In this case, Perplexity was able to get the correct information, although its presentation could have been better. Still, it managed to weed out some outdated information which I would have had to do myself if I had used another search engine, so I'll give it a point for that.

Still, at the end of the process, I find myself not convinced that this is any better. I might use it if I failed to find information through normal search engines, but my hopes would not be high that this would do any better.

American cops are using AI to draft police reports, and the ACLU isn't happy

Likewise, that is not of much interest. When they need to, someone will look through the video and find the weapon. A lot of the videos concerned are not that long and the weapon not that hidden, so it doesn't take very long. Custom software to search every video for weapons will be unnecessary most of the time, and it risks false positives on all sorts of objects which someone will have to identify even though the incident potentially involving nonexistent weapons has already ended.

When a company is selling software, the question that generally gets asked is how much time or money, usually derived from time, will the software save. The answer is often based on optimistic assumptions of the software's quality and ease of use, but it still has to have an ostensible point. One that searches for weapons can be sold as saving the time of a human reviewer when there is public outcry. That doesn't happen often, and when it does the problem is important enough that they probably want a reasonably extensive human review anyway. Time saved is thus somewhere between little and zero. With one attempting to identify abuses, time saved is higher because it can be used more often, whenever a review is called for, but it only generates negative, costly results and manual review will be needed to deal with people who say the software didn't identify the incident they're complaining about. One that writes reports has a clear time saving as described by the author of the article, so it is easier to sell than either of those. The fact that you have a much higher chance of being able to write either of those and getting somewhat accurate results is not something that is considered in the initial sales process.

But that's not the selling point for the software. Police departments are not willing to pay extra for software that might make it easier to find abuses, but in the case of negatives, don't prove that there weren't abuses. Most of the time, that doesn't help anyone, and the few times when it does, it's not the ones paying (whose budget it comes out of, anyway). This software is designed to save time and money on the writing of reports, which is an obvious cost to the department, and therefore they see many benefits. As long as they can be tricked into assuming that the software is able to do it or that inaccuracies will not be their problem, then they are motivated to buy it. That is why the AI you mention, the purely advisory detector of specific, narrow, and thus more reliably identifiable events, did not get developed and something useless but probably lucrative did.

Re: "red wine" is a collocation in natural language processing

In this case, you can say that human interaction both caused and solved the problem. The computer would not have come up to a reversed name because it wasn't a match. In the case of a full collision, the computer is more likely to check for that because collision identification is much easier and very common in programming tasks. Trying to make a broad conclusion from this incident is unlikely to help.

Of course, and some people will do that and get released on successful completion. Some of those people will be guilty. Meanwhile, some people who are innocent will not have lawyers capable of poking sufficient holes in that evidence or will try it with a judge or jury that refuses to understand that, even though a massive company sold this to thousands of law enforcement organizations, that doesn't prove it's accurate. Those innocent people will fail and be incarcerated. It's bad from both directions.

That has happened for lots of dubious evidence before. People who actually committed the crimes they were charged with have gotten off because inappropriate tactics were used against them while innocent people were condemned using the same tactics. To some extent, success is correlated with the calibre and expense of the lawyers they have with them, but sometimes, it's pure luck. If it happens enough, enough case law will be built up that the evidence as a whole is inadmissible. That's happened several times, nearly always to the benefit of justice, but a lot of people got harmed in the process to get there and the cycle never ends. The best we can do is try to preempt the next type of bad evidence before it is used.

Contrary to some, traceroute is very real – I should know, I helped make it work

Responding to headlines never helps

This article's author goes to great lengths to argue against another post based on that post's admittedly bad headline. The reason for that is simple: the author has seen the "isn't real" bit of the headline and jumped to bad conclusions. It's not literal, but it's also not satire a la "birds aren't real". The article itself explains what they mean with the frequent claims that traceroute "doesn't exist":

From a network perspective, traceroute does not exist. It's simply an exploit, a trick someone discovered, so it's to be expected that it has no defined qualities. It's just random junk being thrown at a host, hoping that everything along the paths responds in a way that they are explicitly not required to. Is it any surprise that the resulting signal to noise ratio is awful?

I would have phrased this differently, without the hyperbole, because that clearly causes problems. This response makes no point relevant to the network administration consequences of a traceroute command that is pretty much only usable by people with a lot of knowledge about the topology of any networks they're tracing through and plenty more about what that command is actually doing. Where it does respond, specifically the viability of traceroute in MPLS, it simplifies the problem by pointing out that you can, if you desire, manually implement the TTL field, then goes on to describe the many different ways you can choose not to, ways that everyone chose to use. It is fair to say the author of the anti-traceroute article got it wrong when they claimed that MPLS couldn't support it, but in practice, "couldn't support" looks very similar to "doesn't because they deliberately chose not to". It is similar enough that it doesn't invalidate the author's main point, that traceroute is a command that is dangerous in the hands of people who aren't good at understanding why it doesn't give them as much information as they think it does.

Firefox ditches Do Not Track because nobody was listening anyway

Re: If it's optional why is anyone surprised?

They will come up with their own way that they claim is informed and test that in court if you challenge them. They may lose on that basis. If they do, it will be irrelevant to whether you had DNT on or not. Having it wouldn't help prove that the consent was not informed, but pointing out that they had hidden terms would.

Musk's lawyer asks SEC to quit pestering the shy and retiring billionaire

Re: Securities Extortion Commission?

Given their policy of not directly commenting on open cases, no, they wouldn't just deny it. Of course, the article does quote another source who does deny it, though not in specifics. Maybe that other source is just lying, I can't prove they're honest, but maybe Musk's lawyer is the one who is lying. You have already come to your own conclusion about what the truth is from no more and potentially less evidence than the rest of us.

Android beefs up Bluetooth tag stalker protections

Re: Protections

The harms caused by a stalker are more extreme and more evident. Several people and groups have called for these to be banned entirely because of those risks. The manufacturers of them have decided that restricting them, even if it degrades their usefulness, is more likely to prevent them from being banned. They are probably relying on purchasers not understanding that the devices are more limited in functionality than they appear. There is not a good answer, but the chances are that these will not be useful anti-theft devices after restrictions are finalized. You will have to choose whether they're still useful when they only protect against loss.

BOFH: Don't sell The Boss a firewall. Sell him The Dream

Re: That reminds me of "The Plan"

Wrong. It is an encrypted HTTPS connection with an invalid certificate. Clues to this include the URL, which is right there in the post, starting with "https:", the content of the error message, and the posts from others correctly explaining the message.

Open source maintainers are drowning in junk bug reports written by AI

Someone smart enough to do that successfully and benefit from having done so can do something actually useful to get into a project. Fix a few actual bugs and work well with the community and you can get into a much better position than submitting nonexistent vulnerabilities.