Posts by doublelayer

'Right to switch off' initiative aims to boost economy by beating burnout

Re: Hmm

Yes, there will probably be some loopholes and some problems because this is the always tricky process of trying to encode common sense into law. For instance, they'll probably have to write a patch into the law to indicate that someone shouldn't stop work at 17:00:00 even when the task they're working on could be completed in a few minutes and could cause problems when uncompleted, and if they forget, there may be some arguments about that. However, this attempt to encode common sense would not be needed if people had stuck to it in the first place. When companies have been expecting people to work at all hours even though they did not negotiate to do so, did not add to the negotiations when they expected it, and did not compensate the people being asked to work more, then it is the employer that has violated the contract that was created.

As with many other posts here, I don't mind working longer hours if the stuff I'm doing is necessary and reasonable, and I will determine whether I think it is. If they have a crisis, I'll be called in, and I will help to resolve it. If they don't have a crisis and call me in anyway, then we have a problem, and it is not enough to say that I just need to get a new job. I will consider it, but since we didn't negotiate this, putting all the responsibility on me is misplacing it.

This move is necessary because some companies have acted as if they can simply state that your working hours are all hours unless they let you take them off. If they hadn't tried to do that, we wouldn't need it. Some other companies have not tried that, and it's unfortunate that they may have extra regulatory work to deal with, but if they are being reasonable, I hope that most or all of their employees will also be reasonable and leave the execution of this law to those companies that are using their own loopholes in the contracts they've written.

Sorry, Moxie. Blaming Agile for software stagnation puts the wrong villain in the wrong play

Re: I sort of agree with some of his points

"Do we really need an enormous framework such as electron for simple applications? Honest question."

No, but I can see why people use it. Building cross-platform applications is annoying. I don't really want to spend a lot of time working on UIs, and what I'd like even less is designing UIs at least three times for different operating systems, then tying each one to the backend. Chances are that, if I try, I'm going to get annoyed and stop before all the GUIs are done, or they're going to get out of sync. That has been a problem for a while and lots of frameworks for cross-platform GUI development exist.

A lot of them have some quirks, such as not looking quite right or interacting with the system in expected ways. For example, Java's standard GUI libraries have a tendency to react oddly to keyboard commands, mostly not reacting at all when they're supposed to. That's not good. I was also looking at some software that used GTK which came with an announcement in the documentation that this would possibly work with screen reader software for the blind on Linux, but wouldn't work with it under Windows. From the sound of their warning, it sounds like a lot of users don't understand how hard that is to fix and the authors don't know how frustrating that must be for a user to hear. When considering what framework to use, you have lots of little problems like that.

Using HTML seems like a realistic option. After all, every OS can render HTML. While I don't use Electron, mostly because it uses too much JavaScript and system resources for my liking, I have often built small GUI applications by spawning a local HTTP server and opening a page rather than using something else. They're lighter on resources and I don't usually stay with that method at the end, but when I'm trying to create a UI I can rely on to work well without spending too much time on it, it's one approach that I've used. While we have problems that are that annoying, frameworks to fix it will continue to proliferate and developers who want to get something working will choose them.

Re: Where are the distributed services?

"adding a social media UI to an e-mail client - E2E encrypted social media operating user to user, without a central hub."

Most social media requires a central hub at some level, not working with user-to-user. I can't see what everyone here has written if every comment has to come from its user's computer. It wouldn't be on, or I wouldn't be known to it, and therefore I couldn't read it. Even finding the servers to ask for their messages would be a problem. The closest you can get is Mastodon, and there are still lots of central hubs involved. Not everything can work individual-to-individual.

"We need stableware - particularly a new OS that is stable for 20 years. Not updating more often than Premiership teams change their manager - updates that can break more than they fix."

The goal to just right code well once and basically never change it is not new, and it's no more realistic now than it ever has been. Things change more often than that or bugs get found, whether they have security vulnerabilities or just cause the program to do wrong things. It's true of everything we have and will be more or less true for everything that's similarly capable. To avoid it, you need to give up lots of functionality.

There are open source programs that do a lot of what you'd like to do, and it's not "corporate/government restrictions, abuse of patents, lack of interest in the VC community, and industry gatekeeping" that are keeping them from taking over. In many cases, it's users not wanting to do the extra effort that comes with self-hosting something and, to some extent, lack of the funding necessary to advance them quickly as competitors can. As The Register noted, there are barriers to open projects in users' desires and the software's design that have nothing to do with big tech abuses (there are many, but they're not always to blame) or government restrictions (they talk about banning encryption a lot, but they haven't actually done it).

Raspberry Pi 5 slims down for cut-price 2 GB RAM version

Re: Headphone socket missing though

Their first headphone socket was pretty terrible with a lot of interference to the extent that dithering was advisable to turn it from bad to mediocre. I'm not sure if they ever fixed it, and I do have many of the other versions so I could try to find out. However, after trying to use an original Pi's headphone socket for usable audio, I gave up and got used to I2S or USB audio connections. Thus, the loss of the socket in the Pi 5 doesn't concern me because I wasn't using it before.

From your comment, I'm guessing that at some point, they fixed that. However, I'm also wondering whether you can use audio over HDMI? That's always worked in my experience, so if you're using it for a media device using the HDMI interface, can you run audio over that and connect any audio systems to the other end? That should allow more channels than a simple 3.5 mm jack, and most televisions have one of those as well. It hasn't been an option for the kind of things I built, but most of those either have no screen or a small one.

AI stole my job and my work, and the boss didn't know – or care

Re: "Stored in a retrieval system"

You're problem is that you're ignoring what laws actually say. It's fine if you disagree with some or all parts of copyright law and are perfectly willing to break them yourself or to see others do it. We might disagree about whether that's ethical or advisable, but at least we'd be on the same page. An argument that "this is against the law, but I don't care about that" is easily understood.

Your argument that, because you disagree with the law therefore that's not what the law says, is not helping. Not only do we keep telling you that it is what the law says, but it can have harmful consequences. If you insist on believing that the law is what you want the law to be, you will continue to be surprised when the real laws get applied. Admittedly, those laws aren't being applied to the large AI companies because they have a lot of lawyers, but they do have dozens of lawsuits using these laws, which don't work as you describe, which will get to court eventually. What's worse, if you keep telling people that the law's not what it is, others may find themselves going "I'm fine, definitely following the laws, wait, why did the jury just say guilty?" If you don't like the laws, you have to try to change them. Pretending you already have will limit your ability to change them.

Re: "Stored in a retrieval system"

Because they have the copyright and, presumably, didn't give you permission to have it. That's how copyright works. It doesn't matter whether you got the binary or the source code; they have the copyright on both of those.

Re: "Stored in a retrieval system"

Well-corrected. Perhaps I should have written "Getting code you don't have permission to have and compiling it is copyright infringement even if I never give it away". The context was proprietary Adobe software, but as the chain of responses grew longer, that was less and less clear. If you do have permission to have it, or if it's in the public domain and thus you don't need it, then this all goes away.

Re: "Stored in a retrieval system"

Most of your critiques are unimportant. Whether the models are storing their training data because they were ineptly developed or because that was the intent, whether they are larger than a thousandth the size of their training data for good reasons or bad, these things are not important. Were they trained on stuff the trainers did not have licenses for, and do they reiterate some of that data back. Those are important. The answers are, in nearly all cases, yes and yes. Even if you can find a model, such as your image-based model which does not quote the training data, if the answer to the first question is yes, they still have a copyright problem. You do not have the automatic right to use anything you can find on the internet. Your additional arguments to try to distract from this fact do nothing to change it.

Re: "Stored in a retrieval system"

Me: Getting code and compiling it is copyright infringement even if I never give it away.

You: No it isn't. Licenses specifically govern redistribution. You can in fact do with free/open-source code whatever you want on your own computer. You may have broken licenses acquiring it in the first place, but that's nothing to do with compiling it, and all the material LLMs are trained on were scraped on the open internet.

You're correct about open source code. Unfortunately, you're wrong about the rest of it. Open source licenses specifically allow me to use the code as I like. Non-open licenses do not give me that permission, and the copyright applies to the code. If I get the code to something proprietary without permission, no matter what I do with it, I am not allowed to have it. It is already copyright infringement. Whether I compile it or not, modified or not, it's still infringement. Copyright is not only violated when you distribute a copy you don't have permission to distribute, but also when you obtain it. If you go to piracy sites but just download, never seeding a torrent, you're still infringing. You're probably going to be ignored if the lawyers go after people, but that's because there are so many people doing it and they have bigger fish to catch. They could sue you successfully, and that applies to code as well. It doesn't matter that the data was scraped from the internet. You do not have a right to do whatever you want with any data that you can get from the internet.

"So you're talking about "we know it's the same" vs "we don't know it's not the same". Except of course we do, because as I noted in the other comment, the network simply does not have the space to store more than a thousandth of its source data. So not only are the things you're asserting very different, but we also know that the thing you're asserting about DL models cannot be true for any functioning network in anything more than a fraction of possible cases."

Your example is flawed and your conclusions are even more flawed. Your example demonstrates that the model is too small to store all of the training data. However, many other models exist that are much larger compared to their training sources. Text-based models are frequently in that category. You also have misstated the benefits of compression; a model can contain more than a thousandth of the source data if it has effectively been compressed,, text is very easily compressed, and finding the patterns that make for the best compression is exactly what neural networks do well and one of the main parts of model training. A lot of the training data may no longer be in the model, as throwing out rare or unnecessary data is another core part of training these models. The part that is still there, while a small subset of the training data, is often in there with sufficient accuracy to be quoted.

Re: "Stored in a retrieval system"

The analogy is not exact, but it is closer than you're imagining. Decompilation is not as simple as it's painted. There are many ways to take a machine code file and get some source code that, when you run it through a compiler, gives you the same or similar machine code. Sometimes, even that fails. However, you tend not to get source code that you want to read, let alone modify and put back into production. There are some languages where that's different, and there are binaries that left in a lot of extra data that makes this easier, but since that data is irrelevant to the functioning of the program, we can't count on it being there.

Similarly, there's no simple way of taking a model and cracking it open to get copies of its training data. Some of the data isn't there, and what is there isn't stored in any convenient way. That isn't a guarantee that it's not present. In many cases, LLMs quote from their training data on request. That's more likely to happen with a large model than a small one, not really a surprise. Large models also tend to be the more useful ones, though. Even if that quoting is not exact, this doesn't really matter. A poorly OCRed copy of something I don't have the right to copy is still infringement.

You don't need simple byte-for-byte recovery to violate copyright. In fact, you don't need to reproduce at all, and that's where the analogy makes more sense. Getting code and compiling it is copyright infringement even if I never give it away. Chances are that if I have those things, you're not likely to catch me, but the violation doesn't cease to exist just because I got away with it.

"don't pass a law that can't be enforced. The problem with AI training is there's nearly no way to know what material it's been fed from looking at the output."

They're not asking for that. They're asking that the training data be identified from the source, which is much easier. Anyone training an LLM knows exactly what they trained it on, and the only reason they might not know where they got it is if they're being sloppy with the record keeping. Now there are a few situations where they might have an extra layer, I.E. they scraped a book from a pirated copy on a different site rather than from an original source, but they would at least be able to identify the pirated copy and its location. That can be enforced. It won't be, but it can.

CockroachDB scuttles away from open source Core offering

Cockroach is making money off selling licenses to this, but the people outside their companies who fix their bugs and add new features to the code get nothing. If their devs have to get paid, why don't the external ones? Maybe the license should be changed to say that, if you've made changes to the codebase, Cockroach needs to pay you for the length of time your code's been in there? Just as users have benefited from a database that you don't necessarily have to pay to use, Cockroach has been benefiting from people who do work for free, some of which probably worked at those commercial users.

I don't think that change is advisable, but nor do I think this one is. They have the right to do this, but it is an intentional bait and switch both to the users and to the contributors. I also know that, when it backfires as many similar decisions have, they'll have no choice but to extend their groups. Well, they could go open source again, but people who already abandoned open source rarely go back on their decision and are rarely trusted if they do. So while there's a revenue cap, which already conflicts with the "commercial use" provisioned in a confusing and possibly contradictory way, that cap will probably disappear at a moment's notice at some point.

Shots fired as AT&T and Verizon ask FCC to block Starlink's direct-to-cell plans

Re: Is Starlink disrupting or is AT&T trying to close the market?

If some Chinese company did try to sell their services in the US without the licenses, that's a crime. The US could have all the money that company holds in the US confiscated to pay the fines. So yes, if the company concerned did it by having people pay them through cash in the mail and hid the equipment coming in, it might work. If they try to operate like a normal business where you can just go to their website and buy it out in the open, it's not going to work. At that point, the company concerned isn't going to be making very much money for their trouble. Meanwhile, sticking to the license means they could actually sell in the market, normally, with all the typical legal protections, so they're a lot more likely to do that or ignore the US altogether. There are some regulations that are just not worth the effort to break.

Re: Is Starlink disrupting or is AT&T trying to close the market?

The Chinese won't be interfering with US signals because, unless they get an FCC license, they have to turn off their radios when over the US. If they don't, then the FCC will prohibit people from buying their services. So no, the Chinese will not be ignoring FCC rules over the US. Over the open ocean, probably. Over China itself, maybe but they've got mobile phone companies too and they sometimes fight.

The second example is faulty because it expresses a quantity, not a comparison. A quarter of the people agreed says that, out of x people, x/4 of them agreed. If x/4 of them agreed with statement A, and x/16 agreed with statement B, then stating that "a quarter agreed with statement B" doesn't convey the information. "A quarter of those who agreed with statement A agreed with statement B" probably misstates the groups involved by suggesting that it was a strict subset. Saying that "four times fewer people agreed with statement B compared to statement A" conveys the information. That isn't to say that it is the only or the best way of conveying it, but if it is understood, it meets the first requirement.

I have a debt of £20 and no assets. That means my net balance is -£20. Oh no, somehow my debt has gone to £180, or nine times as much. That means my net worth is nine times less than it was.

When you have negative numbers, you can have X times less. If you have positive numbers, chances are you can make negative numbers from them that mean something. You can also understand the intrinsic link between multiplication and division, and thus that y=(1/9)x also means x=9y, and saying "one ninth as stringent" is more likely to confuse people.

Re: Stupid Question Time !!!

Because, if they were allowed to do it and it did cause problems, the other carriers would probably have to prove that it was specifically the Starlink satellites doing it rather than anything else against a bunch of lawyers from Spacex trying to hobble them. In the meantime, Starlink keeps doing it. Then, if they succeed in proving this interference and the FCC suspends their license, Spacex sues the FCC for doing something wrong, whatever their lawyers can make up, and demands an injunction because they've paid for a bunch of hardware on thousands of satellites which they can't get back because their equipment can't manage -120 but only -110.6, and some judge will grant them the right to keep using it while that case is decided, which will take years. In the meantime, Starlink keeps doing it.

There is a reason why there are experimental licenses, which allow for something like that, and production licenses, which usually have to be granted before you put your equipment into operation. Otherwise, every company would do whatever they wanted until such time as someone figures out the harms it causes. In at least a few areas, radio spectrum being one of them, this is limited to prevent chaos. The FCC had some reason for thinking that -120 was a good limit, and the other carriers appear to think that raising it will cause problems. By all means have some knowledgeable people review that, but saying "I guess you can do whatever you want" whenever someone asks for changes is not a recipe for success.

Oracle's Java pricing brews bitter taste, subscribers spill over to OpenJDK

Re: FALSE

This is wonderful. We've finally found something you're not endlessly negative about.

I don't know what the authors of these tools managed to do to break it. I do know that their code is all JVM-based, because when it broke I disassembled it and identified that no native libraries other than the JRE were being used. What exactly they did inside that code I can't say. I probably wouldn't have decompiled it anyway, and the users decided not to have me either reimplement or continue to troubleshoot it. We tested it on a lot of Windows 10 machines, and it reliably failed the same way on every one of them. It doesn't mean it's Java's fault, as it easily could have been a dependency's fault, but if it was, the dependency concerned was running from the JRE and most likely written in Java.

Google is a monopoly. The fix isn't obvious

I'm not sure I understand your argument. In the situation described, most of the Google employees that are driving Android somewhere are still there, still working on Android, and still being paid to do it. Their employee records just don't say Google on them.

I don't think a consortium of manufacturers alone could manage to run Android successfully. While I think there are enough of them that would understand why they can't go off on their own, a slow process would gradually cause one manufacturer after another to try doing it all themselves in order to have software that their competitors haven't got. However, a consortium of manufacturers funding a separate company might be harder to disassemble because the manufacturer that splits off would no longer get the work funded by the others. I base this assumption on the fact that it's basically what Google already does; while I don't know how profitable the Android unit might be, they do get revenue from OEMs and they have prevented more companies from pulling an Amazon and trying a fork. Most forks of Android are one of the following:

1. Ones for China where most Google services don't work, forks I don't want to be running.

2. Custom, made by the community, not really a competitor to any manufacturer, such as Lineage or Graphene.

3. AOSP builds that only exist for unusual hardware, posing no competitive threat.

4. Something like Amazon Fire OS, which could theoretically be a competitor, but it's not being developed as quickly, so if it was truly forked, it wouldn't go very far, and since it hasn't, it has to keep coming back to get the changes to AOSP to keep itself from getting obsolete.

In this scenario, Google wouldn't exist anymore. Various pieces of Google's software would now be Android Corp property. For instance, Google Play Services would not be a Google product because it's part of Android. It would now be Anddroid Corp Play Services or something else. Many of the things you're thinking about that are missing in AOSP would still be closed-source but Google would no longer control them.

That wouldn't necessarily be true of all the preinstalled Google apps. The GMail app, the search app, the Maps app, those might have gone with other parts of Google. The ones that are foundational to Googly Android, though, would be part of the Android company that was spun off.

Android is one of the easiest ones to imagine. They already get funding from device manufacturers. The new Android Corporation would probably still have important things like Google Play Services, whatever they renamed it as, so they could continue to sell licenses to hardware OEMs and use that to fund the OS. I'm sure Google chipped in some extra funding which they won't get anymore, but Android Corp doesn't need to do any of the data collection things that Google asked for, so their workload will decrease as well. If it was failing, some manufacturers might fund the continued development so they still had software for their phones. That depends on manufacturers having gone through enough variants to know that making their own OS with their wonderful new features but without compatibility with phones made by other companies is a bad idea. It's not a guarantee, but compared to many other branches of Google, Android is one that could probably work if it was split off tomorrow.

I would put search, ads, and possibly YouTube and GSuite in that category. I would not put Chrome, Maps, Gmail (the individual one), or many of their more popular products in there. Of course, there are many more services that we could put into one category or another.

Re: Perhaps the buying and selling of businesses should be outlawed

It won't work. There are lots of situations where a company can buy another company that don't result in monopolies. The restrictions are usually placed just on buying the competition, and even then there are times where that is necessary. Many of the situations you describe probably wouldn't work out differently if buying the competition was banned. Instead of driving a company into a tricky situation, then buying them, a powerful competitor could just drive them further into the situation until they couldn't operate, then set up shop wherever they pulled out.

Regulation is needed, but it won't be something that can be easily stated in a paragraph. There is no quick fix that will work on Google, let alone all companies everywhere.

I don't think that's how it translates. Using your analogy, I'd translate it as this: "as a hostage, I don't want you to annoy the hostage-taker too much because they might split into two smaller hostage-takers each more evil than the original one, both of them holding me hostage". I suppose the analogy doesn't work very well.

The concerns are relevant. If you split Chrome off from the rest of Google, you've now got a lot of people who make a browser and no money. Google only makes a profit from Chrome due to their advertising and data collection. Both of those wouldn't be there anymore. All the Chrome developers want to keep their jobs and get paid. How can this be accomplished? A lot of the possibilities are bad, even worse than what Google does with it. Perhaps the best approach is for Chrome to simply cease to exist with the wreckage picked up by Microsoft's Edge team, whoever makes Brave, and some people can go to Mozilla or Apple to work on a different browser, but there are worse options, like everyone's data collected from Chrome sold to the highest bidder, then again to the next highest bidder, then on down the list. As bad as Google's collection from Chrome is, they're not doing that. Thus, preventing stuff like that should be part of any good breakup process to prevent the parts from causing even more damage. It's not necessary to be nice to Google, after all the whole point is that Google will cease to exist, but to limit the damage to users when it happens.

Still waiting for a Pi 500 and wondering what do this summer?

Re: Point

"What you are saying is that all computers should be based on Intel X86 CPUs and no other CPU or architecture is worth it because you have to compile an OS to run on non-X86?"

Am I saying that? I don't remember saying that. However, I am pointing out that the original critique: "with the x86 ecosystem where you can just use a generic ISO to install the OS instead of needing a custom built ROM for each SOC" is correct, and not only for Windows.

That is no reason why you can't use something else. It is one point in X86's favor, not the only thing to judge a CPU on, and certainly not a reason to ignore every other architecture whatsoever.

Also, it's not about compiling the OS. Someone has to compile the kernel to run on anything, and that's either me or the distro maker, mostly them in practice. The distinction is just with the ease of portability and modification when standard firmware is involved. The solution to this that I'd like to see is not the destruction of ARM and the use of X64 everywhere, but instead standard firmware used on ARM chips. Neither of those things are going to happen, but if standard firmware for ARM happened, I'd be happy, and if destruction of ARM happened, I'd be unhappy. For one thing, I'd probably have to turn in all my Raspberry Pis for that to happen and I don't want to.

Re: Point

You weren't actually that subtle making your suggestions that, instead of using an SSD, I run stuff from RAM:

"Run stuff from memory (up to 8GB)"

or use network storage:

"Extra storage comes over the network."

So I didn't have any problems comprehending your suggestions. I just didn't like them for use as a desktop.

Maybe you're accusing me of misunderstanding you because of this part:

"However, your response that nobody needs it kind of sounds like you also think it doesn't work and are trying to make excuses for that."

If it was, you might note that I said that it "sounds like", not it "definitely is". I'm pointing out how someone could interpret your comment when they know the benefits of SSDs. I doubt you have any experience testing whether or not the SSDs work because, from your comment, you don't need them for your uses. However, as a response to someone claiming that they don't work, this isn't very convincing and neither is being told that, since you don't need one, I don't need one either. So if that's what you had in mind, it seems the misunderstanding was on the other end.

Re: More portable

You could build something out of it, but I'm not sure how useful it will be. Unless you're willing to use a really small screen, you'll probably make the package bulkier to add a screen large enough that you're willing to use it, and a small USB keyboard is easily obtained but will make internal cable management tricky. I've built similar things out of Pis before, and they worked, but they were always more ungainly than a normal laptop. The footprint of my box was smaller, but it had to be taller to get everything in and wider if I didn't want to trail cables.

Incidentally, also from experience, the only reason you can accomplish your goal is being willing to mains power it. Pis do terribly with batteries and the Pi 5 is the most power hungry of all of them. You can use a USB battery for charging phones which will be relatively cheap and last a while if you get one of the larger and heavier options, but the Pi can't measure its capacity, so if you forget to charge it, expect power to be lost at an inconvenient time. You could instead get one of the battery systems intended for use with a Pi which will get around that in exchange for costing a ton more than the other option and generally being limited to a few 18650s which will give you a few minutes of battery life. I've wanted a Pi-powered laptop since the Pi 2 became available, and they've had them for a while, but battery life is always one of the worst features.

Re: Point

Nothing needs an SSD; I could boot my laptop off a USB disk and it would still work. However, one of the selling points of the Pi 5 was that you could use an SSD, which is sometimes relevant. One of the cases where it is especially relevant is in a desktop computer, such as the one the article is about. I don't want to hold every application I might want to run in 8 GB of RAM. That wouldn't leave me a lot of RAM for memory-intensive things. Nor do I want to get another computer to provide network storage and run a Pi as a thick client that still has to execute everything. If I'm doing that, I might as well run the computing on the server providing the storage and use an earlier Pi as an actual thin client.

Fortunately for me, I wouldn't have to, because that's one of the main reasons why NVME was added. I don't know how well it works because I haven't bought a Pi 5 (there's a cap somewhere for how many Raspberry Pis you can have before you have a problem, and I might be near it). I wouldn't be surprised to hear that elsergiovolador's summary of reliability is simplistic. However, your response that nobody needs it kind of sounds like you also think it doesn't work and are trying to make excuses for that.

Re: Point

No, that's not how it translates because of two things I think you probably already know:

1. On an X64 processor, you don't need custom images of any operating system, and you usually don't need custom kernels either. On a Raspberry Pi, you definitely need custom images, and sometimes you also use custom kernels. On other ARM boards, you always need custom images, and you often use custom kernels. The more "custom" things you have in a build, the more annoying the process can be when something doesn't work as expected. For instance, in-place upgrades from one standard distribution to another are a pretty common test target and generally work well, whereas doing that with images sometimes breaks or just isn't available for a while, and if your kernel has patches which haven't been upstreamed, you may not get to update the kernel at all unless you can find the sources and try to patch it yourself.

2. If you really do want to run Windows, the Raspberry Pi can do it. Probably better now, because the last time I tried, it was on a Pi 3B. Windows 10 didn't like the single gigabyte of RAM and, while it ran, it wasn't fun to use.

If you insist on misstating what people say, you paint yourself, not as someone who understands the distinction and has a good argument, but someone who has a pointless adherence to a product without the knowledge to explain why. There are reasons to favor the Raspberry Pi, but you haven't stated any of them.

IRS has loads of legacy IT, still has no firm plans to replace it

And for those of us who aren't, it's not exactly impossible to learn it. I have not written in Pascal and very little in Fortran, but I have written in a ton of other languages, many of which got some concepts from one of the above. I probably won't learn them because demand is lower for them, but if I were a criminal, and if I learned them I could take lots of money from the IRS, then learning them wouldn't be a barrier.

LLM-driven C-to-Rust. Not just a good idea, a genie eager to escape

Re: Why use an LLM?

Because you can't actually write code to convert C to Rust accurately, and the closest you'll get after significant effort is a program that converts most C to valid Rust without fixing any of the memory issues for which Rust is supposed to be better. Getting to that level is already a substantial effort. So because the problem is hard, someone decided to make it someone else's problem. They won't get any better results out of an LLM, in fact they're likely to get much worse results, but maybe they can get someone to give them money to try doing it.

I'm afraid that the person who came up with this idea probably does not understand LLMs or Rust, especially the reasons why Rust is believed to be better. It's only better because it makes it harder for programmers to do one class of wrong things, but without programmers in the loop, it won't help with that either.

Biden tries to cut through fog of confusion caused by deliberately deceptive customer service tricks

Re: I like how Apple makes it simple

There are a lot of services that do that, but they don't advertise it. I've had many experiences where I have a thirty-day trial, cancel it on day 27 to be safe, and get the message that it will continue working through day 30. I know people who do that with Amazon services and streaming in general, but I couldn't make a full list and it could change at any time. However, since so many people are doing it, I wonder if there is a requirement somewhere that is making them. Otherwise, I would have expected them all to cancel as soon as they got the button press.

Apple is coming to take 30% cut of new Patreon subs on iOS

Re: Make the app free

The app is already free. The app isn't the product, just the way to organize payments to others who don't have an app of their own. Anyone who wants can pay through this by going to their website instead of their app. However, they will not be able to continue to use the app and direct people to any other payment systems, either in-app or on a website. Outside the EU and South Korea, Apple has forbidden doing so. Inside those areas where it is required, Apple has placed so many restrictions on doing so that they're still effectively forbidding it but pretending that they aren't.

I'm guessing by the comparison to Rockbox that they wanted features the iPod's music player software couldn't do, such as playing formats other than the two that Apple supports or transferring music not using iTunes. Of course, then I start to wonder why they bought an iPod instead of something else they didn't have to hack. At the time, I'd have preferred an iPod running Rockbox to something generic, but if I didn't know that Rockbox would be supported, I would have bought a cheap one instead rather than deal with the limitations.

I think the restaurant shouldn't get to charge me for going to someone else's restaurant just because I have gone there in the past.

This is not about paying more for iPhones. I've done that and willingly to get the benefits of the phone, such as updates that don't stop coming after two years. When Apple does something, I am willing to pay Apple. When they don't, I am not willing to have to pay them more. Trying to tax any financial operation that involves an iPhone, even when they have done nothing at all during that operation, is not the same as charging higher prices for their own products.

Before we put half a million broadband satellites in orbit, anyone want to consider environmental effects?

Most of those areas are less populated, which means two things:

1. Geosynchronous satellite's capacity in their area isn't divided very much, so it provides perfectly fine service unlike some more densely populated areas.

2. Starlink is unlikely to serve those areas because they don't have the regulatory approval. For mountainous areas around the Andes, they have obtained some of the licenses they need, but for your "volcanic island in the middle of the Pacific not near any existing fibre links", they're not likely to get that.

For instance, Tonga's internet was taken out a while ago, so maybe people there might like Starlink. Take a guess whether Starlink has bothered to get approval to sell to that small market. They haven't. In addition to probably being beneath their consideration, the other reason for that is that being far from links also means Starlink doesn't work very well. If Tonga's link goes down, the satellites have to send a lot of data over a mesh network until they find the next ground station, which means a lot of transfers because Tonga isn't very close to other things. This is a problem that geosynchronous can solve more easily. You're overstating Starlink's functionality with your own examples.

Software innovation just isn't what it used to be, and Moxie Marlinspike blames Agile

Re: Blame........

I'm inclined to agree with you in many areas, but I think your main point still gets it wrong. There is indeed a lot of complaining, including on things that are not worth complaining about. I've pushed back on several of them already. While I haven't talked much about Agile here, and I tend not to like it, it too seems mostly irrelevant to most of the things that we're discussing.

However, this is not something where we can just articulate what the problem is, because the topic in which we'd try to find the central problem is "what is wrong with software in general, worldwide, and why". There are lots of problems in that area and almost none of them apply to everyone. When you have a question as vague as that, answers are less likely to work because most of them won't apply well to all software writing. Those that do will probably be worse, because the only way you can claim to comment on all programmers is to have ridiculously broad stereotypes (E.G. young people are terrible because not one of them learned anything other than JavaScript, old people are terrible because not one of them can write in anything other than VAX assembly). No simple statement of a problem, no matter how accurate, will make that the problem.

Re: Agreed

Now tell me: when did I recommend doing so?

You don't have to do that to use a framework. There are lots of ways to manage dependencies that don't clone a repo on invocation and just roll with it.

Re: He's right about black boxes and over-abstraction though

"Some OO languages (C#, I'm looking at you) prevent individual data items being passed by reference, thus forcing an entire objectful of data to be passed into a method rather than a pointer to the single item which is to receive a new value."

There are several problems with this description. First, it's not C# or any language doing that. It's the writer of the object labeling a member private or protected or not exposing it directly. If it's your library, you can change it quickly without breaking compatibility. If it's not your library, it leads directly to the second problem, which is that this is done on purpose for a reason. It's done because it lets the writer of the library restrict their code to defined behavior. If they don't want you manipulating an internal value without going through the setter, it probably means their setter is doing something or it might in the future, and if it does your direct manipulation might break stuff.

This is the same reason why, even though I can, I don't write to internal data of other parts of a program or dependency. Maybe it works now, but there's no guarantee that it will continue to work when something changes and if it doesn't, the failure is likely to be annoying to debug, unlikely to show up first in testing, and potentially damaging to the user's data or environment. It also makes debugging harder because, if you put something invalid there, the problem will not be detected when you do it. It will only show up when some later operation tries to work with it. Debugging will require tracing back from where it broke to where you inserted the invalid data.

Re: Tradeoffs

This probably depends on your definition of framework, but people use frameworks because they want something that is likely to work and they don't want to spend long times implementing and maintaining it. We do it all the time with operating systems. I could write something without using Linux's system calls. I know how to do it. They taught me how to and made me do several when I studied operating systems. If I'm working in something embedded, I will. If I'm not, I won't. I won't because I want my program to run later on, so if the system call gets improved, I will get the benefit. I also don't want to waste time I could be spending getting new things to work redoing something that's been done before, probably better than I will because they've got years of experience finding and fixing bugs in it. If I'm writing another platform, library, framework, or whatever else this is, then of course I'll reimplement because I'm trying to make something better than they have. If I'm trying to build something that needs such a platform, library, framework then I won't rewrite it unless their one is not good enough.

There are lots of good reasons not to use a dependency, but ascribing laziness to those who do is a ridiculously broad stereotype that does no good to anyone. Marlinspike's comments were aimed, as he says, at those who cannot implement such a thing, not those who don't. A large part of knowing how to do something properly is knowing if it makes sense to do that thing.

How to ingeniously and wirelessly inject malware onto someone's nearby Windows PC via Google's Quick Share

Re: Quick Share?

Google started it, but Android still has a place where apps could store their data and you could see and modify it. A lot of apps choose not to use that, and it's not a recent thing. Google enabled this, and almost from the start, but app developers deserve at least some of the blame when they have an option to avoid it.

Re: Quick Share?

Yes, sometimes, but not always. For one thing, there are a lot of Android apps that have worked to kill the filesystem and don't place their files in a place where you can easily find them, or sometimes, a place where you can't retrieve them at all unless you have root access. Some of those might support other forms of sharing, though.

Then you have the problem that connecting a USB cable and enabling media transfer allows the person you're connecting to to read all the files that aren't locked in the previously described way, not just the one you want to send them. You also have a compatibility issue. If you connect an Android phone to a Windows computer with a cable, things will tend to work. If you connect two Android phones together with one cable, then you have to work out how to tell both devices which one is presenting MTP over this cable and which one is receiving, and you can't go in both directions. That will take some time to figure out. I would also point out that Mac OS and Linux don't mount MTP devices (virtually every Android device uses this) as conveniently as Windows does and can't access them at all without installing other software, but that probably isn't relevant because it sounds like Quick Share doesn't run on those either.

We're thirteen years on and XKCD 949 remains a major gap.

Secure Web Gateways are anything but as infosec hounds spot dozens of bypasses

"For some of us (a minority), features like USB access are the whole point of computers. I'm willing to give up internet access to have USB access."

I don't think I understand your desires. If that's what you want, why can't you use a computer now. The browser does the internet stuff and all sorts of other things can do USB. The only point of letting the browser do USB is to let internet-based things access USB devices. If you're giving up internet, then that doesn't help you anyway. Also, in my experience, the main reason why a browser-based thing wants access to USB devices is as a profiling tool (keyboard IDs would be a pretty good fingerprint). Malicious pages have even more nasty things they could do with that access. The one use that hasn't been that evil was a serial console for a development board, implemented in Javascript, but I have plenty of native programs that can send serial over USB.

Re: The complexity of the modern internet browser

"a. I thought modern browsers ran in a sandbox?"

They don't, but they create sandboxes for the scripts that run. This means that a script will have to either find a vulnerability to escape its sandbox or get a user to do so. For instance, assembling a malware file on the user's computer, downloading it, then telling them to go open it.

"b. If the SWG can inspect SSL traffic doesn't that mean the SSL traffic isn't really secure."

Yes, in this particular case, which is what is intended. If you specifically allow the traffic to be intercepted by installing something with the rights and capabilities to supply its own certs, you know it. This requires configuration on the endpoint. If you control a network link that my computer connects to but you can't put your certificates on my computer, you'll be unlikely to be able to do the same.

US 'laptop farm' man accused of outsourcing his IT jobs to North Korea to fund weapons programs

Re: To Fund Weapons Programs

It's not private enterprise. In order to get a network connection to start doing this work, you need approval from the government to have one, often not even in North Korea. The scale of the operation and repeated statements, including from workers, managers, and government leaders have demonstrated that this operation is government-controlled. So yes, the money earned from doing it goes into government coffers. They spend it on whatever they want, including agricultural supplies, fancy stuff for the Kims, and weapons manufacture and research programs. Not in that order.

Faulty instructions in Alibaba's T-Head C910 RISC-V CPUs blow away all security

Re: Obit

Would it kill you to actually understand what people say? In this case, the comment you replied to did not say that this instruction was fine. From that comment alone, you can determine that they think RISC-V in general is bad and that this vulnerability, while bad, is better than everything else. If you need more clarification, look at the other comments posted by the same person. I don't agree that it's quite that bad, but you've taken up a valiant effort to attack a point that nobody said and the specific person you're responding to would probably disagree with more than anyone else.

Hello? Are you talking on a Cisco SPA300 or SPA500 IP phone? Now's the time to junk 'em

Re: Phones still OK on an inside non-routable network?

It depends on your setup. I'm not sure what these models look like and I'm not going to bother looking it up, but a lot of phones like this that I know have have two ethernet ports. You plug in the one cable from the wall, then you plug a passthrough cable for the computer. Now that phone has its own internal address which you can firewall and it's got access to the user's computer traffic as well. It can send traffic as the user's computer, allowing it onto that network. So if you do that, probably firewall rules won't be enough.

Re: Phones still OK on an inside non-routable network?

I suppose the theoretical attacker who has lots of time on their hands and good skill could make this really nasty by installing C&C systems on all the phones. Then, after something like a ransomware attack where the computers were completely wiped, you think they're gone because all the computers have been reimaged from a clean state, but they can come back from what looked like a dumb desk phone and do so over any part of the network in which those phones are installed. It would still require the same access you described, but that's probably the worst thing they could do with it. The risk may be low, but unfortunately the potential harm in the worst case is substantial.

Study backer: Catastrophic takes on Agile overemphasize new features

Well said. Your comment reminds me of a blog post from several years ago that gives some good examples of ways people misunderstand simplicity and its value in product design.

Re: Agile would be great if not for all the people

I have to agree here. If there's one thing that the manifesto actually does state clearly, it's that the type of mismanagement described is harmful. It doesn't say how to avoid it, but given how a lot of implementations work, I'm not sure it would matter much if it did since management would ignore it anyway. I've worked in places which were better at this, often by having a more informal team structure as Agile recommends. On that point, Agile has recommended the right thing. It should be obvious but sadly is not.

Re: You Keep Using That Word

"And on the subject of 'comprehensive documentation'. That is in the manifesto because software code IS documentation."

No, it isn't. It never has been. It never will be. Code is a set of instructions for a computer, not a set of instructions for a human, and definitely not a set of instructions for a user. A user does not care how the program does something, and they do not want to and should not be expected to have to read through in order to figure out how to use the thing.

I've worked at places where that was tried. One team went as far as to put in their readme file (all ten lines of it) RTFC. The result: weeks of wasted time trying to figure out which parts of their library worked and how. Did I mention that one of the people wasting their time figuring this out was on the team that wrote it? Because they did not document, and incidentally did not check, anything properly, their code was impenetrable. To make it worse, their library called out to another library which was written the same way. This is why you have reference documentation. What this function does. What parameters it can take. Otherwise, you too will find yourself spending time trying things over and over again because all the invalid calls return empty sets, but some valid ones have zero results so also return empty sets. Now was this one a failure or success? If only someone had written that down.

And that's in a situation where everyone involved could do that. What Agile proponents often fail to recognize is that most of the people for which software is being written are not programmers. They cannot read the code. They don't want to either, but even if you made them, they would not be able to do it. Some of them don't have the code in the first place, since not everything is open source.