Posts by doublelayer

Spam blocklist SORBS closed by its owner, Proofpoint

Re: Spamhaus

That's like saying that Microsoft reporting a file as malicious and automatically deleting it isn't blocking it. Imagine, for the sake of argument, that they did that to the Libreoffice installer. Now a Microsoft fan could point out, correctly, that you could disable Windows Defender and the file wouldn't be deleted, or that you could go into the settings and disable the automatic deletion function, then click through a couple warning screens, and that would work. From the perspective of most users, that decision would still be intended as and implemented as a block.

When people use these spam lists without thinking, they're partially responsible for the problems, but people who are labeled possibly spammers by an overeager algorithm will tend to blame the algorithm, especially when a lot of receiving MTAs remove the "possibly" before deciding whether to allow the message in or not. I do not know this case, and I have not had to deal with this in a long time, so I cannot say whether this case did involve a bad decision by the list creator. I don't think it's hard to imagine that there could at times be those bad calls.

When I have run my own mail servers, I found that various lists either blocked or warned about every IP address that could be rented. Since you can get a cheap VPS, so can a spammer, and it's cheaper to block the entire range than to come up with some method of trying to tell the two apart. There is a reason why I stopped running these. It's not that I can't, but the work involved in depolluting an IP addresses is annoyingly sporadic, depending on the goodwill of people who may or may not have any interest in helping you.

When I was looking into this, it seemed that the easiest ways would be to have a corporate network or host in a colo. Their static addresses weren't on lists. Unfortunately, both are expensive and make it harder to host a low-traffic server for a project. Several ended up using registrar-hosted email instead, which wasn't my first choice, but substantially reduced the concern that I would wake up one morning to find that messages were no longer arriving.

New York Times source code leaks online via 4chan

Re: Cheery

"BTW it's time companies started putting their stuff in long-term storage (i.e. tape, [...] That'll make it a lot harder for miscreants to nab it. Most of the stuff isn't needed online anyway."

They should consider using that for backup, but it does little to help with security. Most of that stuff is needed online, or so much of it that they probably need a hot copy. Your repos are much less useful if programmers and sysadmins have to keep asking to get tapes mounted so they can work with the thing. The only thing you can remove from hot storage is the stuff you're pretty sure you won't need soon, and I would define soon as "any time in the next year, from even one person".

They need to modify parts of their code. They need to deploy it to new systems. For both reasons, their code is not something they can just store on tape. Doing that is useful if their hot storage gets damaged and they need to recover, but trying to do it without the hot storage at all will only lead to frustration.

Study finds 268% higher failure rates for Agile software projects

Re: > it feeds into the suspicion that the Agile Manifesto might not be all it's cracked up to be.

"There is no hook. The manifesto is not required to give precise instructions, period. It's a couple of good ideas that some people wrote down. That's it."

The manifesto is required to explain itself if it wants to be understood. It does not. It is required to give enough detail in its ideas so we know they're good. It did not. Your argument is as easy to defend as saying that it's a collection of bad ideas from people who don't know anything about how software is designed? Do you disagree? You easily can, but not based on the content, because it does not provide enough detail to prove whether they work or not.

Me: Recommendations opposed to plans, documentation, and formal processes in general.

You: No, they are not. The manifesto prohibits neither plans, nor documentation. Nor does it prevent it's implementation as a formal framework

There is a difference between "oppose" and "prohibit". I said "oppose". It does. People have misapplied this by doing even less than the authors probably intended. I say probably because, once again, the authors provided insufficient detail to know. For all I know, this could be exactly what they were going for. All I know for certain is that people claiming to follow Agile are doing an insufficient amount. Whether that was intended or not is not something I or you can prove. If I want to tell people they're doing something wrong, it is incumbent on me to explain what, in detail, they were doing wrong and how to do it differently. A slightly wordier version of "work better" is not sufficient in that regard, nor is saying that anyone who didn't improve was, by definition, not working better and thus that I'm not responsible for what my statement caused them to do.

Re: From what I've seen....

Exactly, and that should be what they do with software as well. Either you need software that has already been written, and if you can't find one then you can ask someone to help you find it. If you can't, you should go to someone who can take your requirements and help design what you need. For instance, I know a guy who needed to have a custom-designed house because he uses a wheelchair. Sure, you can retrofit an existing house and make that work, or you could move to a place where houses are already well-designed for it, but if you don't want to deal with the difficulties each of those brings and you can afford it, then designing one from scratch can work. It would not have worked if he failed to mention that until the first designs were drawn up and someone was building it.

Unfortunately, that happens all too often when people are describing software. They assume that you know that there is a requirement that they didn't state, or they think they stated it and probably did but not in sufficient detail that you understood what it meant. It doesn't even have to be something as big as my analogy. This is why you either have to figure that out at the start or stick with the customer through the development, constantly getting their approval or feedback on things. A lot of people who claim to do Agile aren't doing that latter version, which Agile recommends, and therefore they don't get what the customer wanted. There are a number of reasons why they don't, and one of the main ones is that the customer doesn't want to. However, they need to recognize that they either need to make the customer do it anyway or they need a process that can work without it, and skipping it but continuing to use the process that requires it leads to substandard results.

Re: From what I've seen....

You can have them as long as you take the management with them. The users have a limited understanding of what they want, which is not necessarily the same as what would be of most benefit to them, but making the time to properly understand what they want and why they want it before I start writing tends not to get prioritized. Fortunately, I'm no longer in the position where I was simply given tasks without anyone explaining who wanted it or why, missing all the important details and I couldn't figure out who to ask for them.

Re: Next Week

When I work somewhere with technical writers to do that, I'll keep that in mind. Where I've worked, there aren't any, and if I ask why not, the same line might get trotted out again. If they can't be bothered to have me write a little of it, even though I don't have to explain it to anyone, why would they hire someone to do it? That would take an extra person and probably at least as much time from me.

Re: Interesting...

"I often wonder whether our use of IT blinds us to the actual effectiveness of the processes it replaced."

Probably, but at least part of that is due to users who use the familiar workflow rather than the better one. Yes, they may be able to demonstrate that the real problem is the software not doing something it needs to, but in other cases, the software can do things but someone won't learn it. Not every system that didn't get switched is because the software isn't fit for purpose. Inertia is a big factor, and there are various things we can do about it, from training to more information about why this improves things. If we assume every failure is a quality problem, we may be punishing ourselves for the wrong thing when what was needed was a better introductory training on the new option. Even if it is a quality thing, it could be due to bad programming, good programming of a bad design, or good design of a bad process, and you won't fix the situation without figuring out which.

Re: What I Have Never Understood About Agile......

It can be very useful if the conditions match, specifically that the software has a lot of user*-facing features and the user is actively working with you to get it. The point is that, although they've specified a new thing and you say they'll get it in a year, you can actually show them parts of it every month or so and get their feedback. If they want something developed in the first month to be different, you can change it in the second month. That works badly if you deliver the whole thing in ten months and they decide they want it changed. In the latter case, you usually have to refuse to change it so they can have their software on time, whereas if you can change it quickly, they can get something closer to what they want and still on time.

The problem comes when the user isn't checking on these things. Every month, you send the next development version to a manager who doesn't use it, the manager forwards the email to someone who either doesn't use it either or does, but they're too busy using the old version to help check on the new version, and the developers think everyone's fine with it when nobody's looked. Doing this well effectively requires that the user has an internal beta team, not to catch massive bugs (although they might and that is helpful too), but to report where they would like things to be designed differently. If they are unwilling or unable to do this, then this method no longer works and the developers need to use a different method to ensure their design matches the requirements.

* User in this case may be internal or external, and it may be at various levels. Other programmers can also be the user. In fact, that sometimes works better because hopefully they understand the importance of testing incomplete versions.

Re: Impartial study or not?

I agree with you there. For all the problems I've discussed about Agile, I'm not convinced that this overwhelming condemnation of it is accurate. I'm pretty convinced that there are at least a hundred different processes being called Agile, so there's no way they can be accurately averaged and compared to anything else.

Re: Software is hard...

This really depends what the criteria are for splitting a task. I can easily split lots of tasks into really tiny pieces, and each of them can be done quickly. I don't often do that because it just adds more work to manage tasks without providing any more feedback.

Consider as an example a project I have been building recently. I am the only programmer on it. In order to reach my last test version, I had to build lots of little components and link them together. It would be very easy to split the task into a list of components, then check each one off. The problem is that, when I have written two components and have seven to go, the code still can't produce a result that it couldn't before from the perspective of the users. Until all nine are written, the intended behavior doesn't work. I can finish each one in a short time, but I can't produce an observable improvement until they're all done.

But fine, we're not just looking at the user's perspective. What if this was a team project and people could see the results of finishing one component? It would work in this case, at least somewhat, because the components could be worked on in parallel. The problem is that, by developing multiple components, it would free me to change the design a bit to make improvements. If I split all of these and told other team members to do some of them, there might be clashes when they either didn't have the room to improve or where they proposed improvements that required us to delay our work to work on the interface. Not to mention that, for more complex software, there can also be tasks where the code is not of use to other developers until all parts are written and dividing it would be counterproductive. If it's just about reporting progress, those dividing lines can be set. If it's about having a new shippable version every sprint, there are tasks that are not served well by imposing that requirement.

Re: Overhyped fad proves disappointing

Possibly the reason you're getting disagreement is that "devops" is another one of those words that a lot of people use but they all mean something different and everyone else doesn't know what it means in any given scenario. I've heard it used to describe the following things at least:

1. The same people build the application and manage the servers on which it runs.

2. The same people build the application and manage the environment in which it runs, but someone else runs the server. The dividing line between server and environment can be figured out at a later point, good luck.

3. Different teams manage these things, but they have frequent meetings.

4. The people managing servers should do it with IaC tools that are more similar to development. Who cares what the application developers do.

It's not surprising given these four that opinions on how good it is might vary widely. There's a reasonable chance as well that you have a fifth definition.

Re: > it feeds into the suspicion that the Agile Manifesto might not be all it's cracked up to be.

"True, because that's not the manifestos goal. It points out an, at the time, alternative and new approach. Its a guideline and Idea, not a Step-By-Step cookbook on how people should do their job."

You're trying to let them off the hook again. It's not a guideline. It's at its most benign a statement of the obvious. It's as if I made a new code of moral ethics which reads in its entirety "be kind to people whenever possible unless absolutely necessary". You can't argue that my code is wrong, even if you think it probably is, because I have not bothered to define "kind", "necessary", or even "absolutely".

At its less benign it continues to be hopelessly vague but does make some recommendations. Recommendations opposed to plans, documentation, and formal processes in general. Without expressing any limit, reason, or details, they should not be surprised when those recommendations are followed too strongly. I'm not even sure if they understand that's a problem.

When I say rules, I don't mean about the structure of the thing. Agile doesn't have to talk about when and how you hold meetings or what the organizational chart needs to look like. That is not in the scope. But if they say that they want people to welcome changes late in the process, they should absolutely specify how they think that should be balanced against the fact that, if you change everything late in development, you will not be done by the original deadline. Should you limit the changes you accept late? Should you be open to moving deadlines? Should you maybe try to prevent there being so many changes by doing something earlier in the process? If so, what should you do and when should you do it? They should have answered these questions if they wanted to be understood. Since they did not, misunderstandings are partially their responsibility.

Re: From what I've seen....

I don't think that's fair either. Users know what they want, but even if you remove the managers and talk directly user to programmer, which I have done, you don't get the information without lots of effort from both parties. They understand in broad terms what they want, but there are two important gaps:

1. They only understand the surface layer of what they want, not all the components needed to build it. By components, I don't mean the technical details, but parts of the plan. They understand that the following pieces of data need to be collected, and stop there. They don't think about what the computer should do with the data once it has been collected. The form to collect it is what they can see, whereas the backend automation is not, so it often slips their mind. You have to remind them and step through the process manually to figure out all the things that should happen to the data once you have it.

2. They understand at least that part of the need, but they are not good at expressing it. Even for the parts they have already planned out, they tend to omit crucial details and assume that, because they know it, the programmer knows it. You have to break this down and ask lots of little questions, or you have to make assumptions to fill in the gaps. In my experience, the best relationships come when the programmers are capable of making those assumptions and it works well, but the worst teams are when the programmers aren't capable of doing it and do it anyway, so you have to be really careful at that line.

There are two approaches that tend to work with this. You can plan out every detail of the program through weeks to months of painstaking, boring meetings between the devs or someone dev-adjacent and various layers of the customer. The customer doesn't really want to do this because they don't understand why so much detail is necessary. It's not the fastest or most efficient, and there will inevitably be some gaps even at the end of this. It does limit the number of gaps at the end.

The other is a more agile method, and one I prefer if you can get it. You have some sessions with the customer to make part of a plan, build that part, and continue to iterate. If you have a customer who works well with this, then you can build things quickly and pivot fast if their requirements are different than you imagined. However, it does require that people who know what they're doing continually test it. The developers or QA if you have one is testing to make sure it doesn't break, but the customer has to test that it does what they expected it to do and that you know if it doesn't. It is easy to just assume that the customer is testing it and take no news as good news, but not the best method.

Re: The comments prove Agile is misunderstood

"TL;DR: Maybe instead of blaming your failure on all the principles you violated, you should blame your incompetence! If your "agile" project fails, you were not Agile."

Are you trying to make people hate Agile? If not, the sentences I quoted were a very bad idea.

A lot of failures in project management are not the fault of the Agile philosophy per se, even when it is used to justify the bad decisions. That doesn't make the principles blameless for the problems they can and do cause. You have attempted to elevate them to a position of faultlessness which nothing can live up to. You have further demonstrated that you are unwilling to consider that there may be any problems whatsoever with them. The rest of the world knows that, even if it's something they think is pretty good, that everything has flaws somewhere and will only improve if those flaws are identified and corrected.

If you want to reply to people pointing out what they see as flaws and explain why, in your opinion, they are not flaws, they aren't related to Agile, or they aren't as bad as we think they are, we might get somewhere. If you reply to every flaw and say that, although we've drawn a direct link from it to something core to Agile, it's totally unrelated but you can't be bothered to explain why, then nobody will be convinced. Here are some examples where you have misconstrued points and ended up in error.

since the primary measure of progress in Agile is working software, how do you manage to never have anything working along the way and expect on-time and successful delivery?

Not what happens. People have working stuff along the way. The customer wants something different, but there's not enough time to change from what they said they wanted to what they actually want. They will either get what they wanted late or they'll get not exactly what they want on time.

For example, one is having self-organizing teams, meaning the teams decide the best process to get the work done. If your "agile" project is failing, then you didn't organize well, did you?

So that's the only reason in your mind that a project might fail? I would think that it's pretty obvious that lots of other things could cause project failure. As an extreme example, if an asteroid hits an office building and wipes out some teams, then your organization is not at fault for the productivity decline, is it? As a more realistic example, if you've organized to build something which gets changed late in the process, it is not the fault of those who built what they have now that the final product concept is different and isn't ready.

Re: Next Week

they final assertion in the Manifesto is that there is more value on the things on the LEFT but it doesn't mean there is no value on the things on the RIGHT.

Yes, I know. That has not stopped people from putting too little value on the things on the right, and we shouldn't be surprised because those principles were not elucidated. Never in their list of principles do they explain in detail how to do any of the things they suggest, and when people try to stick too closely to the principles, they end up overshooting the mark.

If good documentation is necessary for success in your project, why would you let a misunderstood "methodology" kill a requirement? (And Agile is principles, not a project management methodology.)

Because people didn't ask me. They decide what they're going to do, and they cite Agile as a reason if I question it. I am just one programmer on the team. I can't change it, not that what we need to change to is a similar thing with an easy name and list of rules. It's not that Agile is itself good or bad, because nobody does Agile the same way, but it makes some things very easy to do wrong.

Re: > it feeds into the suspicion that the Agile Manifesto might not be all it's cracked up to be.

"The Manifesto is fine. The problem is how the methodology is sometimes applied."

I'm not sure I can agree. The application is most definitely responsible for some of it, but the manifesto provides their excuses and doesn't even try to direct them away from those misapplications.

In larger forms, the manifesto says a lot of obvious things. "Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done." That's great, but it doesn't actually tell you how to do it, so it doesn't tell companies that they're doing it wrong. Where the manifesto does make a recommendation that can be applied, it's things like "Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage." Of course, a project shouldn't ossify and refuse to make minor changes at the end because it's the end, but this statement is more extreme and is frequently interpreted as "start over whenever the customer asks you to even if it means wasting months of work". Then they act surprised that it's months later than the customer wanted it. This is more likely to happen because they read "we have come to value: [...] Customer collaboration over contract negotiation[,] Responding to change over following a plan" and so they don't bother getting the design right in the first place. The customer's happy, because they don't like doing that design process. They see that there are new builds every few weeks and that seems great because "yay, there's progress", but they don't test them. Developers are happy because the customers are getting what they asked for and surely they're good with it, after all that design's been in the test versions for a couple months now and they've not complained once. Then the project extends six months over asking, everyone gets unhappy, and the contract determines who has to pay for this and someone gets very unhappy.

The manifesto, without being explicit about these things, is at least partially responsible for this. If the people who wrote it knew about these problems, then they failed to describe or even mention them in their writing. If they didn't, then they probably weren't great at designing a new paradigm. The companies who applied it are responsible for each of their failures, but I don't think it is fair to say that they could have applied the manifesto properly and gotten around their problems.

Re: Next Week

I think at least some things can be blamed on the devs. I have met few devs who like to write documentation. While I don't mind doing it too much, I'm always careful not to announce that because I don't want to write everyone else's documentation (so I do mind it at least somewhat), and I've been in a situation where I was asked to do so because I was the only one who documented my stuff without being asked ten times. I think the "working software over comprehensive documentation" line has been among the most damaging, and that sounds exactly like a thing a developer might have inserted.

Re: Correlation or causation?

A lot of the people don't get to choose their paradigm in any case. As a developer, my management decides what things will be, and they don't ask for my opinion. Also, it's not as simple as selecting one from a menu. If choosing something else with an easy name was an option, then maybe we developers could get together and demand that "We refuse to use Agile. We want NewCoding." That doesn't work because there's lots of pieces of Agile and no team actually uses a standard version of them. They use whatever they already want to do and call it Agile.

Re: From what I've seen....

That's when the client has been clear about what they want before construction started. If they haven't, then you have a different situation that more closely matches the typical software development process. Agile and the developers and managers who recommend it can take some of the blame for that, but the customer gets some of it too.

Customers often say "I want X for Y amount in time period Z", but X is often very brief. X might just be "a database to track [something]". The devs have to figure out how to turn a generic request into something that actually does what the customer wants. The analogy to construction is more if I just said "I want a house. Four bedrooms. Get started.", but after they had built something, reacting with annoyance that they hadn't built in the style I had imagined.

The customer can specify all these details up front, but some don't try and some try and fail to do so properly. That's why I prefer to have them in the loop, testing intermediate versions, so that I can build what they want instead of what they said they wanted.

I didn't touch a thing – just some cables and a monitor – and my computer broke

Re: Blonde moments

It could be the kind where you should remove the plastic cover with no release button or slot and the receiver is in there. I prefer that storage method, but if you don't know that they did it, it can be confusing because yanking off a panel is usually not the right policy when you can't find something.

Re: Crows

There are some good organizations that attempt to reuse usable hardware and recycle obsolete electronics. Since they're already reusing plenty of computers, they don't have problems dealing with more ones, even if they end up having to recycle a lot of them. The only tricky part is finding them, as they usually end up being small groups of motivated people and differ from city to city. I've lived somewhere with a good one and am sad that the city I moved to doesn't seem to have such a thing, but I'd try to find if such a group exists where you live.

Re: refused to take responsibility

That might be true, but the person responsible for getting presentations working at a conference is not the same person, or if it is not at the same time, as the person who fixes a computer that's had coffee poured into it. Quite likely, that was going to need to be replaced. If not, it was going to need a painstaking disassembly. Either way, work on that computer was not going to happen quickly.

Big Telco takes aim at renewed net neutrality rules

Re: Information vs telecommunications service

This is unrelated to companies like Facebook. It only covers ISPs, and those don't have liability for the content they transfer due to common carrier legislation. Facebook and companies like them are protected by section 230, so they're not affected either. This change will not alter the situation you describe.

Contrary to its fine print, Google says it won't confiscate repair returns that have unapproved parts

Re: "end up buying new ones"

In many cases, there isn't a lot of choice. So you want to buy an Android phone and you don't want it to age badly, which is why you were trying to repair your current one. The two companies with halfway reasonable software support policies and models available for purchase are Google and Samsung, both of which have this policy. You can hope that Fairphone sell in your region and that you're willing to pay quite a lot for their device, but otherwise, you are left with options that are worse on at least some levels. Refusing to buy from a supplier again works if there are a lot of them available or if you don't really need to buy that type of thing much, but if you do need another one and the choices aren't great, a lot of people will end up buying from companies they dislike because every other option is worse.

Re: Pretty Sure....

I think this would be illegal pretty much everywhere as theft, but in order to prove it, you'd have to file a court claim. I imagine that any company that has and acts on this policy would respond to any filed claim or possibly even the threat that you would file one by returning the device immediately. They're expecting that there will be many people who won't file a claim who will end up buying new ones and that, for those who do threaten it, they won't be at a loss because all they have to do is actually return the broken unit.

Nokia demos upper 6 GHz band for mobile, but UK wants it shared with Wi-Fi

Re: 6GHz Mobile?

The hardware can already use those frequencies, but it just has to turn off some of the bands. WiFi equipment has been doing this to deal with country requirements since the beginning. The original 2.4 GHz band had 14 channels, but only 11 were allowed in North America, and only 13 in most of the world. Almost all hardware requires, at some level, a country code which is used to select the allowed bands before it switches on. I don't know what will realistically happen if you use that to transmit on frequencies you're not supposed to.

London hospitals left in critical condition after ransomware attack

Re: This question should be put to Starmer and Sunak tonight

You might get them to say that, but they're not going to do it.

Prime Minister: Who attacked our power grid with ransomware?

Security consultant: We're pretty sure it's a ransomware group called TheoreticalName.

PM: And who runs that?

SC: We don't know yet.

PM: How can we find out?

SC: They attacked a Brazilian water company, an American school, and a factory in France recently. Does that suggest anything?

SC: Well, you can usually assume that there are at least some people in Russia for any of these big things. We do know that Russia is blocked in the software as a victim country.

PM: So bomb Russia then?

You can suggest anything you want, and if you ask enough times they'll realize that you want a military response and they'll promise you one, but they will have reasons not to do it when it happens. Those reasons are logical. There's a reason why we don't solve every diplomatic incident with bombs.

Re: Plan B. Have one.

"Paper and people to shuffle it are cheap and plentiful."

We live in different worlds. In mine, paper is cheap, and everything else is expensive. People to move forms manually when a computer can move thousands per second are a lot more expensive than that computer. Finding the people who want to do that work is not easy either. Dealing with errors caused by, for instance, someone misreading handwriting is not fast. Space to store all that paper is not free.

Command senior chief busted for secretly setting up Wi-Fi on US Navy combat ship

Re: Should be given a medal

If you are reading it that way, it also means that I should be able to set up as many broadcast stations as I want, even if it means no other radio or TV signals can get through to you, because that is a medium by which one can express opinions. The same logic would apply to standing in your bedroom with a megaphone while you try to sleep. I think it's clear that that is not what they intended when they wrote that.

Checkmate? AI's pawn-pushing prowess proves partly pitiful, partly promising

Re: Confusing about what Prelovac believes, expects or hopes for

"But what does comparing their chess-playing ability do for us?"

It demonstrates that they are not general intelligences. And I don't agree that he believes they have one. I think he was attempting to demonstrate the extent to which they can solve problems that weren't the purpose of their training data, because that's what a lot of LLM-based products claim to do. By pointing out how often they fail at something that is relatively easy to make a computer do, it demonstrates the failure in a simple, practical, easily-understood way. That might be more convincing to someone who believes that LLMs can reliably solve problems than a theoretical discussion.

Re: A real test

"But seriously, is anyone actually surprised at the complete failure of ML to play chess?"

Was that a typo? ML, as in machine learning, does play chess well. A specific model trained on the rules of chess to play actual chess moves is quite good and routinely beats the most skilled of humans. LLMs, on the other hand, are crap at that because they weren't intended to play chess, but there are lots of people who think that they're something that they're not. I don't think many of us are surprised that an LLM can't play chess, but there are some people who might, but probably won't, understand why this means their conception of an intelligent program is flawed. They see a program write a paragraph with correct grammar that looks to be answering a question, and since they can't answer that question, they assume it must be intelligent. Also because they can't answer the question, they may do that even if the provided answer is wrong. It looks convincing and that's good enough for them. I'm hoping we can show them what the tool can actually do before they unleash some LLM-powered thing on us which annoys everyone with constant wrong answers.

Windows 11 tries to escape Windows 10's shadow with AI muscle

Re: For what stats are worth...

I think it's even simpler. I think people just don't care. They see nothing that Windows 11 has that Windows 10 can't do. I've been running Windows 11 for years now, and it's fine, but there's not much that is different from Windows 10 that affects what I do with it. People will replace broken things and get updates that way, and they won't care at least until security updates stop. I predict that there will be a spike after those updates end from people updating the Windows version on machines that could have supported it any time since 2021, but even then there will be lots of people running 10 because they see an optional update and always cancel it.

Millions forced to use brain as OpenAI's ChatGPT takes morning off

Re: Good to see the cloud is as robust as ever

Your argument might work if their problem was a server capacity error, although not very well because, as everyone including you must know by now, putting your resources on a cloud service doesn't automatically provide resiliency, just provides you more tools so you can have it cheaper. However, with the internal server error messages, you have to wonder if maybe their problem is that they screwed something up. Cloud does not save you from configuring something the wrong way.

Crooks threaten to leak 3B personal records 'stolen from background check firm'

Re: That 'opt out link'

There are two options:

1. You are right, they get it from a UK organization that is breaking GDPR and is liable for it. The Florida people have no requirement to identify who that UK entity is, so unless you can find out in some other way, how are you going to file a complaint?

2. They do it to UK citizens who have provided some information and collect it, with permission, from a UK company that has legitimate reasons under GDPR to process it. Then, unlike that company, they keep it and thus your objection only applies to them. Theoretically, you can still hold them liable under GDPR, but if they don't have operations in Europe, they will likely not pay a penalty.

US standards agency reports back on just how good age verification software is

Re: 3.1 years

"Does NIST not understand that 'region of birth" has only tangential bearing on physical attributes,"

It doesn't matter. If you put region of birth into your analysis and it points out that accuracy is different on that basis, that indicates a problem. Whether that problem is due to a racial difference or if there is some other regional factor is important if you're the writer of the thing wanting to improve it, but as a user wanting to know if it's good enough, you don't need to care, because either way the answer is that it is not good enough.

The Canon Cat – remembering the computer that tried to banish mice

Re: System‑wide LEAP keys could be pretty nice, even with our current mouse UIs

I'm not sure you'll be able to make it system-wide because it generally relies on the application to search for you. If you made it common enough, people might adopt it voluntarily, but it wouldn't change the situation where an application decides to reinterpret what it does even if you'd be happier with using the previously standard behavior. For instance, I can see a browser using those keys as back and forward buttons, then because they've implemented behaviors for the keys, they don't bother implementing the hold and type method.

I also have an ergonomic objection to your suggestion, which is that holding one key and typing out a string means either using one hand to type while holding it or performing finger acrobatics to use the remaining four, and the latter only works if you put it close to the character keys which probably requires moving more keys. You could implement it differently. For one example, not necessarily the best, press both leap keys to enter a term, then press one of them to move by that term. The term can be saved so subsequent presses of a single key jumps between them.

Re: A Pebble is Not a Raindrop

If this was just an argument about whether the Cat should have had a mouse, that is relevant. However, with Liam suggesting similar restrictions today, it no longer is. The separate CAD machines in the 1980s had a point: the software and hardware on general purpose computers at the time was insufficient. That no longer applies today, and what was a minor problem in the 1980s would now be a major problem.

That also assumes that CAD is the only reason why a mouse would be recommended. CAD is just one use case where mice are considered useful. I speak as someone who tends to avoid using one when possible, but Xerox and Apple didn't put mice on their GUI computers for CAD which neither of them could even run at launch. They were needed for lots of classes of applications, and those computers succeeded because they could run lots of classes of applications.

Single-purpose devices will always remain niche, and where they take similar amounts of hardware and software to build, niche is very expensive when you have to pay people to build them. When you add in the extra proviso that the niche thing can't even do something that a different computer can't do, then you reach the fatal zone. For instance, people buy book reader devices with e-paper screens. Those can't do a lot, and therefore you spend a lot more for a relatively low-resolution screen, a cheap low-end SoC, and one application than you would for anything else. People still buy them because they like the screen. Now try to make and sell a book reader device with an LCD on it and I guarantee you a failure. People won't have to look far to realize that you're selling a tablet that's locked down to one app, and they could have any other tablet and run this app on it rather than buying your device. The standalone word processor is similarly doomed.

Endless OS 6: How desktop Linux may look, one day

Re: Wayland?

Of course almost anything can be learned like that. The problem is that people wouldn't try to learn to fly a helicopter like that because there's always a chance that what you've just learned how to do as often as you want is to crash the helicopter containing your squishy self into something that is far less squishy. I think most people learning to fly helicopters take a safer approach to learning, and those who don't are pilots I'd rather not fly with if they managed to survive it.

People see computers and assume that, because no body parts will end up in a different place as the rest of the body, they don't have to. And they're sometimes right because we (programmers) put up lots of guardrails and convenience modes to make it as easy as possible. That's what we should do. Still, it might help some people to put at least a little effort into deliberately learning what is happening rather than trial and error their way through any computer-mediated activity, because although it won't cause you as much harm as a helicopter crash, it's still a system with lots of parts which has the capability to do things you really don't want.

Screwdrivers: is there anything they can't do badly? Maybe not

Re: Pre-history

"Took more than 3 days to get it out in order to save 4 hours of testing.."

Correct me if I'm wrong, but couldn't a tool still have been dropped there with the whole console out, since removing the console wasn't enough to retrieve it? The attempt to save time was definitely unsuccessful, but it doesn't seem like it introduced a new way of causing a delay, and therefore not necessarily a reason not to do the same fast removal next time.

Russia takes gold for disinformation as Olympics approach

Re: What's any of this got to do with information technology?

They use fake sites to store the information and various tactics, often bots on social media, so that anyone actually looks at them. Does it really need to have more of a connection? Also, are you really telling me that you couldn't understand that an article with the headline "Russia takes gold for disinformation as Olympics approach" was going to be about Russian propaganda and need a special category to help you manage that?

Google finally addresses those bizarre AI search results

"I don't know why this National Service thing seemed a good idea. Those my age grew up with that as a looming threat over our teenage years, were lucky enough to have been just young enough to avoid it and can see no good reason to let it interrupt our grandchildren's careers."

You've put your finger on the important difference: you care about your grandchildren, present or future.

Re: You DO eat rocks as food.

That's kind of what I said: a rock is a mixture of minerals, but not a superset of minerals. Especially as mineral itself is a pretty vague term. What we're really dealing with are compounds, or even substances, but that's so broad as to be no longer a distinction. Sodium chloride is definitely a compound, when found in the ground is classified a mineral, but I can make it out of metallic sodium and chlorine gas if I have those and then it's probably not, and although it can be found in rocks, it is so far from that that classifying it as a rock only works if I can classify almost every other solid substance as one too. This plum is a rock, just one with a lot of water in the middle bit.

Re: You DO eat rocks as food.

Are they? I'm not sure that's true. The set of minerals could contain specific substances only, whereas rocks can be made up of a mixture of those. A set containing a sheet of paper and a puddle of ink is not a subset of a book, even if books can be made from those things, and importantly, if you ask for stationary, it would not be acceptable if I gave you an already-printed book instead.

TikTok said to be working on US-specific version of its content algorithm for months

Re: Not any better

No, it won't, but nobody doing anything here cares about that. The people suggesting to ban it aren't worried about users' mental health, but about Chinese spying/propaganda/whatever other thing they think the Chinese government could do with it. They would like it sold to someone outside of China, but don't care if those people keep the algorithm with any risks to its users that it might have. TikTok, of course, doesn't see a reason to change the purpose of their algorithm either. Either way, that part is not changing.

US senator claims UnitedHealth's CEO, board appointed 'unqualified' CISO

Re: I think this is overblown

The question is not whether they are responsible in theory, as that's what having that position means. The question is whether the level of blame attached to this person is correct. If they had named someone with more security experience, do we have reason to believe that would have improved things? If the answer is no, then focusing on this is distracting from a different and larger problem. Of course, this depends on lots of little points that we don't have information on, which is why most retrospective examinations take a long time and produce long reports.

For example, if the lack of MFA issue is determined to be an important issue, did the CISO know about it? If he did, was he trying to do something about it or not? If he was, did he have enough time between finding out about the situation and the attack that he should have completed his actions or not? If he didn't know, why didn't he? If he should have been told but wasn't, why not? If he shouldn't have been told because it was being managed by a lower level, repeat all these questions with the manager of that group.

It's boring work, but if you need a problem to stop, it is not enough to fire the person nominally in charge and put someone else in. That someone else will probably change something, but without asking all these questions, it could end up being the wrong thing and that person just becomes the responsible party in the next breech. In this case, there actually appears to be several technical failures involved, but exactly the same blame is ascribed to anywhere that had a negative event, no matter how much responsibility the tech areas had for causing the event. Did someone in sales get bribed to get the customer list, to which they had access because sales needs to annoy the customers to keep having more sales, and send a copy? Fire the CISO, that's what they're there for. It can easily be the right response, but it shouldn't be an automatic one.

Thanks for coming to help. No, we can't say why we called – it's classified

Re: Why wouldn't they have some support people who are cleared?

Probably because they needed an engineer who could fix something, not general support. They might well have had someone who could replace broken parts, but not someone who could fix something that was wrong for all units. Then the problem got reported to someone stupid who brought in someone who could fix the problem but didn't understand that, to fix the problem, they had to know what the problem was.

Re: what we're they thinking?

There wouldn't have been an error code or message from the sound of it. The problem was incorrect results. If they had had someone there who was thinking, that person would have figured out a calculation with random numbers that gave an inaccurate result, and they could just send that. Apparently, that's not what they did.

There's a time problem, a data storage problem, and a general security problem with using paper instead of hard drives.

Time: To use paper, budget time for printing every document modified during the day, filing each paper copy, putting the drive in the wiper, wiping it if you're supposed to stay watching it, retrieving the papers from the file, scanning them in, and editing OCR errors, which ideally should be rare because you're scanning a fresh print but they still happen and it's very important that you don't order the 15l part when you need the 151. Compared to removing the drive and locking it up, that's probably at least an hour of extra work, which means a lot less gets done each day.

Data storage: You're doing this so the sensitive data isn't on the drive, and in order to do it, you're putting the same data through many other systems that could theoretically be used to try to access it. Sure, probably nobody is going to break in to try to get copies off the printer's cache, the scanner's cache, or to modify the wiper to read before wiping, but anything is possible. Also, I've assumed that you have a data drive that you're wiping and a system drive that you're not, mostly because if you only had one drive then reimaging a fresh version every morning would extend that time problem to ridiculous levels, but if you do, there's a chance that some parts of the data files will be on the system drive in temp files, so you'd still have a hard drive to secure. More points where the data is stored won't make the process worthwhile.

Security: Locking up a hard drive is no more complicated than locking up papers, and in fact you can use a smaller box to store it with less risk that someone will get it. Among other things, you don't have each day's stack of paper to deal with. It will probably be shredded, but never having been printed makes it even harder to reconstitute. Paper is also easier to steal. If I, your colleague who's also a spy, manage to get into your office while you're in the morning scan process and steal some of your sheets from the already-scanned pile, then you might not notice, allowing me to sneak your documents away, and if they get caught any time after I drop them, you get the blame.

Re: "he joked"

That's true. A lot of these people have senses of humor but have somehow developed the ability to turn them completely off. This leaves two large classes of people. One looks like two completely different people whether they're working or not. If they're at home, they look like normal people. If they're at work, they look like those old science fiction shows where the robot has killed the person and worn their skin as a disguise. The other is a bit scarier: they look like normal people with senses of humor, even at work. Then you say something and they instantly switch to robot mode and don't come out.