PakG1

This headline is factually incorrect and doesn't match the original article as well. They're protesting against F1, not for it.

I think the point is that the protests may not be reflective of local opinions. Not whether HN should have an opinion on it.

For what it's worth, MDPI has a lot of criticisms from academia as a publisher. Criticisms regarding editorial reliability, methodology acceptance, rigour, etc, etc. Here's just a smattering: https://en.wikipedia.org/wiki/MDPI#Evaluation_and_controvers...

It's been enough where I end up automatically ignoring MDPI papers unless someone I respect recommends one to me. For better or worse. But MDPI made it's own bed in many ways.

I'm not an expert on this stuff at all, so assume I'm stupid and ignorant when I write the following. As I understand it, HIV has actually been useful to develop a delivery mechanism for some therapies that have excellent potential. Would this kind of vaccine cause such therapies to become ineffective?

When we were purchasing a clothes washer and dryer, Samsung had a special promotion. The sales rep at the store told us that the Samsung machines got the most complaints and she would recommend the LG machines. But we wanted that promotion, it was oh so nice. We bought a 5-year warranty just in case.

Sure enough, it's year 3 and the washer has stopped working. Repair guy came and decided he needs to order new parts to fix it. It's been a week or so without doing any laundry. Glad we purchased the extra warranty, but maybe we should have gone with the LG like the sales lady recommended.

What is fascinating to me about technical people is the particular subculture that sincerely believes that technology will solve the people problem. I recently got into a long thread argument with someone on HN about this. The person was adamant that people problems can NOW finally be solved by designing technology to be able to handle adversarial and incompetent actors. But the problems that such software tries to solve are tightly defined in scope and cannot deal with actually messed up people or organizational problems. Unless engineers are willing to acknowledge people problems, they will keep banging their heads against the door when the organization isn't doing what it's supposed to do.

But it's far easier to acknowledge the people problem first and see if there is a solution for that, rather than trying to ram technological solutions through a people-shaped hole. And if the people problem can't be solved (i.e., it will often involve a change in culture and leadership style, or else a change in leadership, both of which are difficult), it may be best to give up anyway and wash one's hands of the whole mess. In which case, one just sits there going through the motions to pass the day and collect the pay. If they're motivated, they'll find another job, rather than try to fix the mess, and they'll likely be happier doing that too. This is also why it takes a certain non-technical skillset combined with technical skills to succeed in leadership roles. It's a completely different game to play.

Sounds like a lot of online platforms.

Only one of those sectors would justify the act. This is a case of not caring about collateral damage. Most of us will not be in a position to say whether or not the collateral damage was acceptable in order to attain the goal. But we can't pretend that the collateral damage was nonexistent.

Having watched full screen replacements, button replacements, and battery replacements on my iPhone, I suppose I don't understand why one wouldn't just wait the extra 5 minutes to get the issue resolved. Repairs can get done really fast in my experience.

What hardware repair would require handing over your passcode? If it's to test that the phone is working fine after the repair, can't you test it yourself in front of them before you pay? If they were doing software repairs, what would be the nature of the repair? Hard for me to imagine anything to repair software-wise, given how iOS is.

As a non-physicist and non-chemist who keeps running into quantum mechanics only through headlines, extra thanks for pointing this out. It's quite obvious in retrospect to acknowledge that quantum mechanics is the physics of chemistry, and I don't know why I didn't see that before. It certainly helps to view a lot of things in a new light.

“The question of whether a computer can think is no more interesting than the question of whether a submarine can swim.” Edsger W. Dijkstra

I imagine the insane traffic volume in NYC also incentivizes more aggressive driving. There's a higher trip time penalty for not making the turn, compared to a city with less jammed roads. This matters for people who need to make appointments or any other driving where time matters (does anyone still offer pizza delivery in 30 minutes or it's free?).

So out of curiosity, are Americans not taught to stop at a red light and check their right-side mirror and blind spot for cyclists or pedestrians before turning right on a red light? Because I certainly was taught that when I signed up for driving lessons? Just Americans don't do this?

Sure, except Americans may also have a weird obsession with driving that makes them oblivious to pedestrians, whereas many other nations may be more aware of pedestrians and thus have fewer fatalities per capita. I have no data to back up such a statement. Just anecdotal experiences.

I don't think that's something the roads prioritize. That's something that the drivers choose to do. A better word might be that roads afford or allow drivers to prioritize speed. I've been in cities where drivers don't prioritize speed. It's nice driving in such cities. People are civil on the road. It's really nice.

Look, you're not able to say how you would get subpar organizations to solve internal system problems. I see what's happening here. You're restricting all your technology examples and use cases to those where organizations need to be able to use technology to interact with other organizations in a trustworthy manner. There needs to be a counterparty that is important and who will give feedback that something is failing. Cryptography enables that. E-mail security mechanisms enable that. The problems the UK Postal Office experienced and that many other subpar organizations experience are not those problems. Why you are talking about oranges when the discussion was about apples is beyond me.

None of your solution philosophy would have prevented what the UK Postal Office experienced. Their issues had nothing to do with interacting with the public. Their use case was an internal black box where things went to hell and they refused to see that it went to hell because it looked like it was working.

You have no idea that we're talking about different things. You can just refuse to implement smtp authentication, DKIM, and SPF and not email the rest of the world. It is possible when you don't care about communicating with the rest of the world and you only use it for something it wasn't meant to do. And then weird phenomena emerge from that. Or you are emailing the rest of the world but you have no clue that you're having one-sided conversations because you don't care about replies. There are so many ways your assumptions can fall apart but it doesn't matter because they're not even trying to use the darn thing for e-mail.

You can design perfect technology in your perfect world but you can't force people to use it the way you're planning. In all your examples, you have the assumption that people will use technology for what you're designing it to do. Those assumptions mean nothing when they use your technology for something you didn't expect and it seems to work for them anyway. And there's no counterpart that they actually care about that tells them otherwise. You can try to explain to them that it's not working. You can even show evidence that their outputs aren't matching what they claim they want. But they won't listen because to them, it looks like it is working.

You need to stop bringing up examples and use cases that have nothing to do with the problems that the UK Postal Office was actually experiencing, and that all subpar organizations experience. Their problems are not the problems you are trying to solve in your logic. And even good organizations experience the same problems too, just to a lesser degree.

> The entire field of research you purport to not exist and not matter is what drives this cabal forward. They remove various footguns every day and take the reins out of incompetent operators hands further with every release.

I never said it didn't exist. I am saying it's not related. Again, the entire field of research that you champion solves a problem that is completely different from the problem that the UK Postal Office experienced. If you understand what happened with the UK Postal Office completely and then offer viable explanations of how your ideas would have prevented their problems and achieved their organizational goals, I will say I'm wrong. Hey, I'm not so arrogant to say it's impossible. But I will say that everything you've said so far is so unrelated to what their problems actually were at a root cause level. To say otherwise is a lie.

To be fair, I used to think like you. It was because I believed that we could create technological solutions to human problems that I didn't understand why organizations didn't just do technology properly. After diving into the research literature, I have realized that's naive. I no longer think like you. It is more complicated than what code alone can resolve. If you can't provide a solid analysis of how your ideas would have prevented the UK Post Office's problems, we really need to agree to disagree.

If it was the Post Office editing Fujitsu's statements, who better than Fujitsu staff to confirm as a trial witness what was in the original pre-edited statements?

I suppose the cynic would argue that if they didn't have this billing practice, they may have survived. Which the other cynic would say is the problem, are businesses being too subsidized by unethical billing?

I don't know what to say here. You don't understand the issues and you refuse to believe that such issues exist. We should agree to disagree. But I'll give it one last stab.

You can't just drop an Instagram-like app into the British Postal Office and then everything's great. Instagram works as a standalone app that doesn't need to comply with any exogenous processes or standards. It can set the standard process for itself, and then all of its users need to adapt to it. There is no way to design an app outside of the British Postal Office that will fulfill their needs and then drop it inside of the British Postal Office and expect to work. Even if you forced the organization to reorganize itself in order to adapt to the app (which happens a lot), the problems will be inevitable.

Even Office 365 or Google Apps, stars in the SaaS space, require internal administration and customization when being used inside organizations and they can be misused. Something as simple as this person should be part of this security group but not part of that security group. Such misconfigurations are inevitable because organizations are messy.

People smarter than you and I have been trying to solve the problem of good IT governance for decades and have so far failed. And the problem has nothing to do with the quality of the software engineers who make the product, nor their technical decisions. It is orthogonal to the real issues. The fact that dumb users can use encryption today without realizing it has zero implications on solving the issues that organizations actually face. It has zero implications on how they use their technology. The only thing it's done is made the technology more trustworthy for transactions of information, but it did nothing to change work habits, decisions, or perceptions about technology. We know because there are studies on how people interact with technology.

These are not technological problems. They are human problems. Things as simple as "I am petty and don't like that employee" or "I'm gonna make sure that my friend gets to have sole responsibility for that app's strategic focus, even though he knows nothing about how to do that department's work, but he's my friend" or "I need this political win and that's more important than hiring the right technology experts or implementing the right feature the right way." They're simple problems to express but intractable to solve. They're intractable because they're emotional and irrational, spawned by people who need therapy. And most often, the people with these problems aren't stupid or dumb. They're actually often smart, which is why they're also often in the position to make the wrong decisions for the wrong reasons. And then it trickles down throughout the organizational culture.

Technology cannot solve this simply because technology can always be discarded or misconfigured, despite the technology's design. Nobody can force an organization to use a technology, especially when it doesn't have the necessary experts to implement it properly. The biggest problem was that nobody at the British Post Office cared for quality control of the system. Bugs continue to be found in cryptography. They're rare, but they are found. Then they are patched. A lot of organizations don't care and then they have security holes simply because nobody cares about patching. Such lack of care extends beyond just cryptography. Automated updated certificates like LetsEncrypt does not solve this problem because the problem runs deeper than keeping a certificate up to date or running automated security patching. Certainly, nobody can force an organization to use LetsEncrypt. Nobody can force an organization to keep the right people in the right security groups. Nobody can force an organization to disable network accounts for employees fired for embezzlement. Nobody can force an organization to care about documenting, reporting, and fixing bugs.

Being right on a technology level has no bearing on whether one can ensure that an organization makes the right decisions overall. Most of the most important decisions aren't even directly related to technology. Even if the easy solution is as simple as use a SaaS that is as simple as Instagram. The dysfunctional ones will say, "Screw that, I want my bonus or I want my job security or whatever, I'll make sure we never use that Instagram-like app, or anything like it." Or worse, they'll try to use it with the best of intentions and then still screw it up massively when they deploy it for employees.

If you can't accept that possibility, we have to agree to disagree.

I remember in grade... 3? a kid at school was showing me books from the library about how to make a game in Basic. Then one day he finally had it going. It was amazing to see. I can't remember what it was, but it would have been the simplest thing. But it was still amazing.

You fail to address the issue that none of these resolve the issue that people still don't follow best practices. This is especially true the further one is from best practices. The reason why cryptography is significantly better is not because the best research has been done. It's because it's impossible for cryptography work to be done without the best people because it's that hard. Drop cryptography engineers into this Post Office mess in the middle of the implementation and they'd say screw it, you can't pay me enough to deal with this crap. They'll leave to go work for an organization that respects them enough to listen to them and still make it worth their while.

You can talk about best practices all you want. You're not going to get most organizations to afford or convince the best people capable of following best practices to come work for them. And even if they did, those best people will leave before they can even change the technical culture. No effective person would put up with the insanity that exists in subpar organizations, many of which continue to exist in spite of their incompetence for many other reasons.

You have no concept of working in the real world where people who suck exist. You talk like you've only ever worked with all-star Linus Torvalds types. Of course it's easy to do what you are recommending when you're working on the Linux kernel, for FAANG, startups with competent founders, etc. All those organizations are able to do what you recommend for reasons that many other organizations can't.

You're a Xoogler working with startups. I get it. You're in that world. You have no idea how to fix an organization like the British Postal Office so that they will do IT competently.

Well, the joke was about whether humans keep evolving into crabs, but I think I crashed the joke's landing. :)

And yet we still have people out there trying to create their own cryptography when the golden rule is to not roll your own crypto. For whatever reason, best practices don't get followed 100% of the time, even if they exist. For cryptography, the situation is better than most other domains. I think we're having different conversations here. You seem to be having a technical conversation. I'm having a sociotechnical conversations within the context of organizations and their workers and managers. I'm seeing you discuss technical solutions to sociotechnical issues, which is not what I am discussing. Even when the technical ideas are perfect, organizations still need to implement the ideas. That implementation tends to not follow allegedly perfect specifications for many reasons.

But you are entitled to your opinion and that's fine. We can agree to disagree, nothing wrong with that.

But... what about humans???

But I've had experience too. My career started in a national telecom where I was part of a skunkworks team to develop internal applications because the organization was fed up with the IT department delivering solutions that didn't fit their needs. We approached issues differently from the ground up. Software developers gathered requirements on their own by job shadowing employees, and then delivered MVPs within days, which were then constantly iterated to finally solve the real problems. The software developers had complete control over what was made and why with zero change management or approval processes. We also had complete control over what technologies we used to make our apps. We mostly used .NET, but we also did some Java Swing and Ruby on Rails, and of course everything also used Javascript.

Our relatively small skunkworks team developed apps that changed the end-to-end solution delivery processes for major business units, both consumer and business sectors, saved the company 8 digits in opex and capex each year, and won an international award for "Best Support Team" (the Stevies, sort of known as the Oscars of the business world). Our greatest feat that year that enabled us to win the award was keeping the company afloat during a four-month union labour dispute by improvising solutions that automated everything in sight. At the end of the labour dispute, the CEO send a company-wide email about how important we were, awarded us this made-up award "Holding the Fort". When the union came back to work, we trained them how to use the new tools, but we unfortunately were also enablers of heavy downsizing, which I always disliked. Some of these people were hardworking people who did nothing wrong and followed the rules. Many of them were elderly and had little chance to go back to school to get new skills (we're talking 50-year-old clerical workers, etc). It drastically changed how I thought about corporate software work. That being said, we were all young cowboys, and it was possibly the best team I've ever experienced in my life.

I experienced the absolute opposite in many ways when I worked overseas for IBM, managing projects that spanned the Asia Pacific. I was the go-to PM many of their mission-critical infrastructure projects, including helping with datacenter migration from Japan to Australia, necessitated by the 2011 Fukushima earthquake and tsunami. I also experienced a middle ground as a venue technology manager for the Vancouver 2010 Olympics. Lots of pressure and set processes, but a lot of extremely competent people too.

Look, I'm not doubting your experience, but I've had mine too, which shaped my views, just as I'm sure that your experiences have shaped yours. We can agree to disagree, nothing wrong with that.

Kind of makes me wish there was a nonprofit organization focused on making AI safe instead of pushing the envelope. Wait, I think there was one out there....

For a car? A car will definitely not outlast most viable companies. What if it's cars for a car rental company? I believe the car would be a core company asset then. But if you don't label it as revenue, what DO you label it as? I'm not an accountant, only have rudimentary accounting knowledge, but don't see any options other than revenue there.

You got a better way to explain the transactions? If you're saying the transactions should be illegal, there are plenty of scenarios where these transactions wouldn't be weird or horrible. How to differentiate which are OK and which aren't?

If they had product market fit, they wouldn't have major feature change requests that turn the product upside down and inside out. But either way, startups don't blame their customers for being unable to meet their customers' needs. I think it's poor practice to blame organizations for being unable to meet organizational needs, especially when we already know that organizations and users don't know how to conceptualize software requirements well, let alone create software.