MyNameIsFred

TL;DR Is US continues to change policy without any clear guidance nor facilitation. Impractical to comply. https://apnews.com/article/us-tariffs-goods-services-suspens...

I'm a personal and professional advocate from r passkeys, yet I must acknowledge that your criticisms and skepticism are valid. I don't see this as a flaw in the passkeys concept so much as a growing pain. It's a very different mental model, and I've seen businesses make some very poor implementation decisions based on some poor understanding of what this system aims to be. That in turn adds to a bad consumer impression, a growing body of bad examples for others to look to and replucate, and it all just compounds.

This rebuttalakes no sense to me. What you cite is about about transport encryption. App -> Server. The end of the process is that the receiver (Telegram servers) receives a decrypted (plaintext) message, just as kelsey98765431 is saying.

The simplified terminology is not for you or I as technologists. It is for the general consumer market. Yes, public/private key cryptography has been a thing for decades, but it has been out of reach for the consumer market. The whole passkey idea is to reduce the technical and cognitive friction to make it a viable replacement for passwords.

You are completely correct and I really wish you weren't.

MS ToDo was hewn from the corpse of Wunderlist. It's the same "ding".

Yes! I dove into this (and later, Moondlander) because I have mobility issues and had to reduce travel, but the resulting 90WPM and (unprovably) faster coding have been awesome side-effects.

Yeah it's a neat idea but I struggle to think of good use-cases [...] If I'm working on a service [...]

I suspect that's simply not the use-case they're targeting. You're thinking of a database as simply the persistence component for your service, a means to an end. For you, the service/app/software is the thing you're trying to deliver. Where this looks useful is the cases where the data itself is the thing you're trying to deliver.

That's an alarming equation. The harder you lie, the less likely you'll be called out on it.

What else in life works that way?

Yes, thank you. A mindset which thinks that documentation is wasted due to a need to constantly update, is cousin to the mindset which thinks that software, once written, is a purchased asset which needs no further attention nor maintenance.

They most certainly do not "handle it just fine". They are highly scammable, they know it, and it's "solved" my moving as much of the burden and repercussions onto the consumer as possible.

I've had my identity stolen, and both my wife and I have been mistaken for somebody else. There ARE way to move past this condition (inline with Google Pay, apparently), but it's just done via trust. Or apathy. Or acceptable risk. Or some combination thereof. It never truly goes away.

What wouldn't be the 5th time I've heard such stories, but I don't think it's in any way specific to IBM. Employers like that want any OT you do to be dedicated to THEIR endeavor, not somebody else's...even your own.

If you're able and willing to code in your off-time, you should be doing it for the good of the Company. /s

My team of consultants will write Android apps, and the customer takes ownership of the code base when we're done.

My wife would leave me if she knew how much I love Kotlin, but I could never use it for work projects because we just could not justify expecting random inheriting developers to know Kotlin and accept its legitimacy. That constraint lifted in an instant. It's a political thing, but it really matters.

I haven't done Windows development for a long time, but I think that this may be an overstatement, at least on that platform.

You need to have cursor focus to receive key events, right?

The clipboard, by contrast, can be continually monitored, while playing completely "by the rules", right?

I do not see this as an actual rebuttal to the idea of it being a backdoor. The article makes two points: 1. Ultimately, verification falls to the user, so even in a secure system, user error, misunderstanding, and/or laziness can result in becoming compromised 2. Clients can lie to us anyway

The point about this "backdoor" business is that the WhatsApp client does not even give the user the chance to even make a mistake of skipping or mis-executing validation. Instead, it will just make that mistake FOR you, every time, for your convenience!

That utter failure of design, and breach of trust, enables a remote actor (the WhatsApp servers) to access secure data. So yes, it is a "backdoor".

Sometimes PDFs store actual character data (like vector graphics), and sometimes they store static images. Last I checked (admittedly a few years ago), Word conversion only works on the former. It didn't do OCR or anything so dramatic.

If only some PDFs will work for them, they wouldn't accept them at all.

Following that statement, the author spends the rest of the article explaining how the people asserting supremacy often do not see it as such.

It is an implicit and unwitting reality of the position they are taking. I used to be one of these folks; I couldn't see the harm and hate of my own positions, thanks to the fog of ethnocentrism.

The striking difference here, at least to me, is the a matter of scale and delay. Aphids and fungus are smaller than the ants, and have shorter lifecycles than the ants themselves. Planting and cultivation of a coffee plant suggests understanding of much larger scale (both literally and conceptually).

By what reasoning? On the surface I would assume that to be false. Please elaborate?

Sorta. The basis for your concern underlines one of the problems. When such gaffs happen in engineering, the firm is blamed. Within the firm, individual actors are blamed. In software, on the other hand, your major system might have responsibility for a critical system spread across a total of 1 persons, so he gets all the blame. Is that really okay for one hip-shooter to take this on in the first place?

Well, yeah, that's one of her few points in this tiny article.

Your .bat files still work, and you can use the legacy terminal if you I insist. All they did was change the default terminal from the archaic one to newer one they first introduced as a the non-default option only a mere decade ago.

There is no reason to be dramatic.

Steam.

Sounds like a joke, yet it's spot-on.

Do you do much C programming?

If I put my "Java goggles" on, the first, "untasty" snippet looks so very obviously to be the right way to do it. But...

If I put my "C goggles" on, the "clever" version from Linus looks much more direct, obvious, and better in general...much like the final example from the article author.

This is true.

I must admit that my more recent, positive experiences are only possible due to my accumulated understanding of my dependency chain and toolkit. I work on multiple things, but my largest, indefinitely-running one has only a single dependency...but it's a truly beastly, poorly documented enterprise system. It took me almost 2 years before I properly understood the system's intended usage, interfaces, intents, bugs, and pitfalls.

The JavaDocs are awesome in their uselessness:

  /**
   * Sets the Wimbulator.
   *
   * @param wimbulator
   *     the Wimbulator to set
   * @param identifier
   *     the identifier to use
   * @param flags
   *     flags
   * @param legacy
   *     used to apply legacy
  */
  public void setWimbulator(Wimbulator wimbulator, String identifier, long flags, boolean legacy);

Yes!

Sometimes I will have a have a big problem that I will decide not to fix immediately, even if it's more "important" than other things I'm working on. Then, when I come back and rapidly write a simple solution, the question of course is "Why didn't you do this a week ago if the solution was so simple?".

The answer is that the answer wasn't simple at first. Understandings of a problem and solution often live and die many times over in a mental background thread, before they ever reach a keyboard.

Sometimes, when under pressure, I am forced to ignore this fact and start writing the moment I reached the "Yeah, I think that would probably work, let's git 'er done!" phase. In almost every such case, it takes longer overall as I iterate through incomplete solutions and rewrites.

In a sense, programming is all about what your program should do in the first place. The “how” question is just the “what”, moved down the chain of abstractions until it ends up where a computer can understand it, and at that point, the three words “multichannel audio support” have become those 9,000 lines that describe in perfect detail what's going on.

This closing paragraph is excellent.

While I do wonder if the author's progress along these wouldn't have been accelerated if more of this evolution took place before the first line of code, the overall message here is very true and very well put.

When I made this realization for myself, it was a major turning point in the quality, speed, maintainability, and usability of the code I produce, especially when I can successfully define the final code structure to directly reflect this progressive refinement from intent to implementation.

Or too lazy to work it out in your head. Jeez.

That's a good point, but do you think that things have a chance of playing out similarly this time around? I get the feeling that web tech was more of an open question at that point, so people would look to a group like IBM to set the standard. I'm not so sure that that's the case anymore (and I make my living building within the IBM ecosystem, so I wish it were so).