That point absolutely still stands.
It’s just strange that since the 4a, the 2 smallest phones Google released were both not in the a series.

The only A series Pixel phone smaller than the Pixel 8 was the Pixel 4a.

They also usually assume a lot about the users’ knowledge of the domain of the program itself.

In my experience, many programs’ man/help is very brief, often a sentence or less per command/flag, with 2 or more terms that don’t mean anything to the uninitiated. Also, even when I think I know all the words, the descriptions are not nearly precise enough to confidently infer what exactly the program is going to do.
Disclaimers for potentially dangerous/irreversible actions are also often lacking.

Which is why I almost always look for an article that explains a command using examples, instead of trying to divine what the manual authors had in mind.

According to a different source shared by @giriinthejungle, the attorney who has taken the case is suing the entire operating unit and expects whoever instructed the girl to drill the hole to be liable for assault. That is also the estimation of the chief regional patient attorney, provided the incident happened as reported by the media.

The neurosurgeon as well as one other doctor have already been let go by the hospital.
Police have not yet charged anyone, their investigation is still ongoing as of the time of the article (2024-08-26).

That’s quite interesting.

Although it would need access to an already configured and fully functional environment to actually run this.
I don’t think we’re quite at the point yet where it’s able to find the correct script, pass it to the appropriate environment and report the correct answer back to the user.
And I would expect that when integration with external systems like compilers/interpreters is added, extra care would be taken to limit the allocated resources.

Also, when it does become capable of running code itself, how do you know, for a particular prompt, what it ran or if it ran anything at all, and whether it reported the correct answer?

Thanks for responding, that makes a lot of sense.
I think generally what one gets used to has a big impact on preferences.

I’ll say, an easily accessible, reliable gesture for side menu sounds nice. It feels like this was either abandoned on Android or left up to developers who mostly abandoned it. I remember struggling to get the side menu to trigger instead of back navigation and it not working near reliably enough. So I’ve been trained to always use the hamburger buttons that, ironically, are hard to reach in the top left corner in most apps. To be fair, I feel like I hardly use one menu interaction for every 100 back actions, so the latter being ergonomic is a lot more important to me.
On that point, swipe from left to go back seems quite annoying. I go back all the time, and having to move my thumb across the entire screen is a pain. I almost never need to go forward, so having that be the more accessible gesture seems weird. I’ll concede that having a gesture for it at all is useful and Android should add the option.

I never felt like the swipe to go back is too sensitive, and if you accidentally trigger it, you can simply move your finger back towards the edge before letting go to cancel the action. You can also configure the sensitivity in the settings. The feedback that you’re about to trigger the action is probably not as obvious as on iOS though, and likely less elegant.

I think both Android and iOS would do well to let users customize these interactions more to their own needs.

Could you elaborate on the gestures part?
I remember the opposite, having hated navigating my iPhone for work. I specifically remember swipe to go back not working reliably at all (many apps seemed to just ignore it, others I think configured other actions on that gesture - WTF), so I got into the habit of using that stupid little hard to reach, hard to hit, tiny back arrow that at least worked consistently when you managed to hit it.
I’ve been enjoying Android navigation gestures pretty much ever since I found out they existed.

It might have been a user issue in my case with iOS since I didn’t use it as much, and therefore maybe was simply using it wrong/was unaware of better ways. But I don’t see anything wrong/missing with gestures on Android.

Bonus: good tests can also serve as technical documentation.

Though I have to disagree with the notion that documentation is as important or more so than code.
Documentation is certainly near the top of the list and often undervalued. I’ve worked on a project where documentation was lacking and it was painful to say the least.
Without documentation, changing or adding features can be a nightmare. Investigating bugs and offering support is also very difficult. But without code, you have nothing. No product, no users, no value.

There are (inferior) substitutes for documentation: specialized team knowledge, general technical expertise. These alternative pools of knowledge can be leveraged to create and improve documentation incrementally.
There’s no replacement for the actual functionality of your applications.

Ditto on the no text part. That is an accessibility failure that’s way too widespread.
Sometimes I’m afraid to even push a button: does this delete my thing, or does it do some other irreversible change? Will I be able to tell what it did? Maybe it does something completely different, or maybe I’m lucky and it does in fact perform the action I’m looking for and which in my mind is a no-brainer to include?

And it’s infected interpersonal communication too - people peppering their messages with emojis, even professional communications. It not only looks goofy, but is either redundant (when people just add the emoji together with the word it’s meant to represent - such a bizarre practice) or, worse, ambiguous when the pictogram replaces the word and the recipient(s) can’t make out what it depicts.
The most fun is when it’s a mix - the message contains some emojis with accompanying translation, some without.

Me every time I see one of these pretty much.
Feels like these are from another timeline. Guess the name is fitting.

If I had to guess, I think this might be poking fun at overprotective parents who unwittingly do more harm than good by controlling their kids’ environment to an unhealthy degree.
Trying to read more into it, perhaps it’s also pointing at the propagation of bad childrearing practices across generations - parent cows grew up on a farm, constrained by an electric fence. Though presumably more independent now, this is what they knew growing up, so they apply (a bizarre perversion of) these same practices to their own children.

I’m probably way off though, because that interpretation barely elicits a half smile from me.
Curious for an explanation from someone who actually gets it too.

I don’t share the hate for flat design.
It’s cleaner than the others, simpler and less distracting. Easier on the eyes, too. It takes itself seriously and does so successfully imo (nice try, aero). It feels professional in a way all the previous eras don’t - they seem almost child-like by comparison.

Modern design cultivates recognizable interactions by following conventions and common design language instead of goofy icons and high contrast colors. To me, modern software interfaces look like tools; the further you go back in time, the more they look like toys.

Old designs can be charming if executed well and in the right context. But I’m glad most things don’t look like they did 30 years ago.

I’m guessing many people associate older designs with the era they belonged to and the internet culture at the time. Perhaps rosy memories of younger days. Contrasting that with the overbearing corporate atmosphere of today and a general sense of a lack of authenticity in digital spaces everywhere, it’s not unreasonable to see flat design as sterile and soulless. But to me it just looks sleek and efficient.
I used to spend hours trying to customize UIs to my liking, nowadays pretty much everything just looks good out of the box.

The one major gripe I have is with the tendency of modern designs to hide interactions behind deeply nested menu hopping. That one feels like an over-correction from the excessively cluttered menus of the past.
That and the fact that there’s way too many “settings” sections and you can never figure out which one has the thing you’re looking for.

P S. The picture did flat design dirty by putting it on white background - we’re living in the era of dark mode!

Love this comment.
Absurd, mysterious, unapologetic.

The point is not the difference between a fake memory and a real one (let’s grant for now that they are undistinguishable) but the fact that positive experiences are worth a lot more than just the memories they leave you with.

I may not know the difference between a memory of an event that I experienced and a memory of an event I didn’t experience. Looking back on the past, they’re the same.
But each moment of pleasure that I only remember, without having experienced it, was essentially stolen from me. Pleasure is a state of consciousness and only exists in the present.

Even better, Obsidian notes are stored directly in folders on your device as plain text (markdown) files.
It’s all there, nothing missing, and no annoying proprietary format.

Not only can you keep using them without the Obsidian application, you can even do so using a “dumb” text editor - though something that can handle markdown will give you a better experience.

Honestly, their comment reads like copy pasta. That first paragraph is chef’s kiss.
I initially thought they weren’t being sincere, something something Poe’s law…

(’ v ')/

The main difference is that 1Password requires two pieces of information for decrypting your passwords while Bitwarden requires only one.

Requiring an additional secret in the form of a decryption key has both upsides and downsides:

• if someone somehow gets access to your master password, they won’t be able to decrypt your passwords unless they also got access to your secret key (or one of your trusted devices)
• a weak master password doesn’t automatically make you vulnerable

• if you lose access to your secret key, your passwords are not recoverable
• additional effort to properly secure your key

So whether you want both or only password protection is a trade-off between the additional protection the key offers and the increased complexity of adequately securing it.

Your proposed scenarios of the master password being brute forced or the servers being hacked and your master password acquired when using Bitwarden are misleading.

Brute forcing the master password is not feasible, unless it is weak (too short, common, or part of a breach). By default, Bitwarden protects against brute force attacks on the password itself using PBKDF2 with 600k iterations. Brute forcing AES-256 (to get into the vault without finding the master password) is not possible according to current knowledge.

Your master password cannot be “acquired” if the Bitwarden servers are hacked.
They store the (encrypted) symmetric key used to decrypt your vault as well as your vault (where all your passwords are stored), AES256-encrypted using said symmetric key.
This symmetric key is itself AES256-encrypted using your master password (this is a simplification) before being sent to their servers.
Neither your master password nor the symmetric key used to decrypt your password vault is recoverable from Bitwarden servers by anyone who doesn’t know your master password and by extension neither are the passwords stored in your encrypted vault.

See https://bitwarden.com/help/bitwarden-security-white-paper/#overview-of-the-master-password-hashing-key-derivation-and-encryption-process for details.

This works as a general guideline, but sometimes you aren’t able to write the code in a way that truly self-documents.
If you come back to a function after a month and need half an hour to understand it, you should probably add some comments explaining what was done and why it was done that way (in addition to considering if you should perhaps rewrite it entirely).
If your code is going to be used by third parties, you almost always need more documentation than the raw code.

Yes documentation can become obsolete. So constrain its use to cases where it actually adds clarity and commit to keeping it up to date with the evolving code.

It’s a big deal IMO, particularly because at login it doesn’t do the same. From the user perspective, your password has effectively been modified without your knowledge and no reasonable way of finding out. Good luck getting access to your account.
When a bank does this it should be considered gross negligence.

If their password was actually good (18+ random characters) it’s not feasible with current day technology to brute force, no matter how few PBKDF2 iterations were used.

Obviously it’s still a big issue because in many cases people don’t use strong enough passwords (and apparently LastPass stored some of the information in plaintext) but a strong password is still good protection provided the encryption algorithm doesn’t have any known exploitable weaknesses.

Extra steps that guarantee you don’t accidentally treat an integer as if it were a string or an array and get a runtime exception.
With generics, the compiler can prove that the thing you’re passing to that function is actually something the function can use.

Really what you’re doing if you’re honest, is doing the compiler’s work: hmm inside this function I access this field on this parameter. Can I pass an argument of such and such type here? Lemme check if it has that field. Forgot to check? Or were mistaken? Runtime error! If you’re lucky, you caught it before production.

Not to mention that types communicate intent. It’s no fun trying to figure out how to use a library that has bad/missing documentation. But it’s a hell of a lot easier if you don’t need to guess what type of arguments its functions can handle.