awaythrow98765's comments

awaythrow98765 | 2 years ago | on: Scaling up the Prime Video audio/video monitoring service and reducing costs

> I'm a cloud proponent because it means not having to sit through hours of meetings to deploy a $5/mo virtual machine.

And endless orgies of "call for pricing" with hardware vendors and hosting. Shitty websites where you can buy preconfigured servers somewhat cheaply, or vendor websites where you can configure everything but overpay. Useless sales-droids trying to "value-add" stuff on top.

Cloud buys are a lot friendlier, because you only have the one cloud vendor to worry about. Entry level you just pay list price by clicking a button. If you buy a lot, you are big enough to have your own business people to hammer out a rebate on list price, still very easy, still very simple. But overall still more expensive unfortunately.

awaythrow98765 | 2 years ago | on: Scaling up the Prime Video audio/video monitoring service and reducing costs

> If your business invests in physical servers anticipating strong growth next year then later finds out actually we're going into a recession and those servers are no longer needed, then that's a sunk cost.

Cloud vendors also mostly sell minimum use packages for discounts in the range of 20 to 80% (called e.g. "committed use discount" or "compute savings plan"). Lots of businesses use those, because two-digit discounts are real money, but they might find themselves in the same spot as with physical hardware they don't need...

awaythrow98765 | 2 years ago | on: Passkeys: The beginning of the end of the password

> No. Passkeys can't be phished, passwords can. Passkeys can't be cracked after a data breach. Passwords can. Passkeys can't be set to something easily guessable. Passwords can. Passkeys can't be written on a post-it note and taped to your monitor. Passwords can. Passkeys can't be reused across multiple sites. Passwords can.

Passkeys don't need to be cracked after a data breach of your backup provider, they are just usable, right there.

> There are so many ways passkeys are superior to user-memorized passwords from a security perspective, it's laughable to call them "as insecure as a password".

Passkeys are accessible permanently on some devices unencrypted or decryptable in the filesystem, if part of e.g. a backup. Whereas passwords are usually only accessible temporarily. That makes the attack surface top copy over some passkey far larger than for sniffing a password.

awaythrow98765 | 2 years ago | on: Amnesty International criticised for using AI-generated images

Amnesty International is primarily an advertisement and donation collection business. Most of your donations go straight into advertisements and collecting more donations. Collectors aren't volunteers but hired professional collection agencies/con-artists trained to guilt people out of their money.

AI using AI for misrepresentations fits my very low opinion of them.

awaythrow98765 | 2 years ago | on: Passkeys: The beginning of the end of the password

Those passkeys are either insecure or unreliable. Let me explain:

Those passkeys are asymmetric cryptographic keypairs where the private key is securely stored on a device, unlockable (for use, not reading) only by convincing your devices security processor to do so by pin/fingerprint/pattern. Which in itself can be secure, given you do trust that magic security processor (which you shouldn't, see yesterday's news for example). However, if that key cannot be read, you cannot make a backup of it, so it will be unrealiable and easy to loose. The recovery process will either be insecure and prone to social engineering, or unreliable because proving your identity will be nigh impossible without that passkey. Now one could allow backups of a passkey, but then that passkey would be as insecure as a password. One could allow multiple instances of authorized passkeys, but those would be even more insecure than passwords, because malicious software on your device could create evil new key instances.

In all a bad and dangerous idea.

awaythrow98765 | 2 years ago | on: Passkeys: The beginning of the end of the password

Actually I'd see a future where some of those password killers might replace passwords, even for some of the under-funded, under-manned applications out there.

What is necessary is a robust, simple-to-integrate standard for authentication, authorization and sessions built into HTTP. Such that all the "hard work" is integrated into common HTTP server software or load balancers, transparently. From an application perspective it should just look like your request getting HTTP_USER=someone HTTP_PERMISSIONS="stuff,foo,bar" HTTP_SESSION="0xdeadbeef", similar to what you get from HTTP basic or negotiate auth, but with a few more necessary features such as session, login/out and a permission model. Browsers would have to provide some proper UI for that, not utter crap like they currently do for HTTP basic or negotiate auth.

Then your centralized auth application can just talk to any old application in a very simple way, no need to deal with huge integration headaches like OAuth or stuff. And the centralized auth application can do all the fancy password killer, 2FA, magic or whatever special auth you need.

awaythrow98765 | 2 years ago | on: Ask HN: Paychecks from a failed startup?

Actually, there is no "folding in good faith" in such like cases.

A company is bankrupt if a point in time can be foreseen, where the company can no longer pay its debtors (employees here are debtors, sometimes even a higher-priority class of such). And while one can argue about the "foreseen" part, e.g. by saying "I did reasonably expect that incoming payment to arrive, which didn't". As soon as you were unable to pay a debt once, or like here even twice, you are actually too late in declaring your bankruptcy. Which, in most jurisdictions, is a crime. And it certainly is in bad faith. If the company isn't actually bankrupt, could pay but won't, then it is also an act of bad faith.

awaythrow98765 | 2 years ago | on: The Windscale Fire: Britain's 'Chernobyl' (2019)

This is assuming the LNT (linear no threshold) model of radiation damage is true. Which it probably isn't. Lower than predicted deaths from accidents such as Windscale/Sellafield are sometimes taken as arguments against LNT.

However, in all such discussions, one needs to be aware of the strong interest of the British government to keep all things around it's nuclear weapons program secret. So maybe the public figures are fake.

awaythrow98765 | 2 years ago | on: Ask HN: Paychecks from a failed startup?

No written contract (over here) is sometimes a very nice thing in those kinds of situations, because then some very employee-friendly default terms do apply (unlimited contract time, long notice period for dismissal, no reassignment to a field of work you might not like, etc).

Get a lawyer and good luck!

awaythrow98765 | 2 years ago | on: Pure Sh Bible

Yes, but actually no: I was tempted to include it but didn't. The one big argument for bash and sh is ubiquity and compatibility. Perl also has those. Python is somewhat lacking in those. Ruby is very lacking on both.

awaythrow98765 | 2 years ago | on: Pure Sh Bible

Easier, lightweight syntax for shell-like pipes, command execution and catching stdin/stdout/stderr.

Something like Perl's IPC::Run.

Also, more shell-relevant stuff in the default distribution, so that one doesn't need to care about any modules (which is the primary reason for using bash or even sh, those are installed practically everywhere along with at least coreutils and stuff). Edit: examples that a standard python doesn't really do would be quick and easy recursive directory traversal and doing stuff to files found there (like the unix 'find' tool), archive (de)compression, file attribute operations (not only simple permissions but also ACLs, xattrs, mknod, etc).

But the sister comment clarified it in another way, so this maybe irrelevant.

awaythrow98765 | 2 years ago | on: Pure Sh Bible

If you are at this level of required complexity as in those examples, you should use a proper programming language, not shell. Half those snippets fail with spaces in the wrong place, newlines, control characters, etc.

I think all such shell "magic" should come with a huge disclaimer pointing the user at better alternatives such as perl or python. And all snippets should have the necessary caveats on horribly broken and dangerous stuff such as "if this variable contains anything other than letters, your 'eval' will summon demons" in eval "hello_$var=value" and stuff...

awaythrow98765 | 2 years ago | on: Germany Quits Nuclear Power, Ending a Decades-Long Struggle

Anti-nuclear-people have mostly been a vocal minority. However, due to mostly anti-science reporting and irresponsible media-spread panic after Czernobyl and Fukushima, there have been temporary majorities for a shutdown, which populist politicians used to get (re)elected.

awaythrow98765 | 2 years ago | on: Germany Quits Nuclear Power, Ending a Decades-Long Struggle

2 of the 3 currently governing parties made up the coalition that first decided to end nuclear back in 2001. The later conservative Merkel government just first extended reactor life-times just to go back on its word and shorten them again when Fukushima happened.

But all the big parties and their politicians had a hand in the current desaster, people are quit right to blame all the last 25 years' governments.

awaythrow98765 | 2 years ago | on: Germany Quits Nuclear Power, Ending a Decades-Long Struggle

Exiting nuclear was once according to then-current public sentiment. Problem is, all governments in the last 30 years have been populist power-hungry careerists without any regard for longer-term science-based policy. They just did what seemed the easiest way to get over the next election.
page 1