I have seen SQL written by professional Oracle DBAs. What I learned is that I do not want to look at SQL written by professional Oracle DBAs.
I have seen SQL written by professional Oracle DBAs. What I learned is that I do not want to look at SQL written by professional Oracle DBAs.
Except people take that method seriously all the time. All the objections I raised were one’s people have actually thrown back at me.
I’m tons of fun at parties. Everybody loves seeing my collection of bottles from defunct soda companies.
You know, maybe we shouldn’t be taking estimation advice from a 1980s science fiction movie that amounts to a systematic method of lying.
Yes, I’ve used it before. Yes, you can hopefully have everything average out in the end. Yes, project managers demand estimates. None of these are good reasons to back up how fundamentally flawed it is.
Also, in practice, they’re usually only good at one or two of the things on the list (at best) and hack their way through the rest. As much as people make fun of overspecialization, it happens in every field for a reason.
I haven’t read through the whole spec to know what else is there, but the thing is, HTTP/1.1 always allowed GET to have a body. It was originally supposed to be ignored, but they gave up on that later on because it’s dumb.
IIRC, the original reason was to avoid people making custom parsing directives using comments. Then people did shit like "foo": "[!-- number=5 --]"
instead.
Some hackers DoS the code. This guy DoS’s the corporate process.
There’s downsides to the companies, though. Interviewing new candidates takes money, and takes time away from people already on the team. If everyone is switching jobs to get a higher salary, then companies aren’t saving anything in the long run. They also have a major knowledge base walking out the door, and that’s hard to quantify.
It’s a false savings.
If I were to steel man this, it’d be cross-pollination. Old employees get set in their ways and tend to put up with the problems. They’ve simply integrated ways to work around problems in their workflow. New people bring in new ideas, and also point out how broken certain things are and then agitate for change.
This, I think, doesn’t totally sink the idea of the “company man” who sticks around for decades. It means there should be a healthy mix.
I keep waiting for someone to come up with some kind of explanation for this that even sorta makes sense. No, as far as I can tell, companies just work this way.
Nobody going to admit to being the pigeon? Because that’s me.
It’s a historical quirk of the industry. This stuff came around before Open Source Software and the OSI definition was ever a thing.
10BASE5 ethernet was an open standard from the IEEE. If you were implementing it, you were almost certainly an engineer at a hardware manufacturing company that made NICs or hubs or something. If it was $1,000 to purchase the standard, that’s OK, your company buys that as the cost of entering the market. This stuff was well out of reach of amateurs at the time, anyway.
It wasn’t like, say, DECnet, which began as a DEC project for use only in their own systems (but later did open up).
And then you have things like “The Open Group”, which controls X11 and the Unix trademark. They are not particularly open by today’s standards, but they were at the time.
The tooling around it needs to be brought up to snuff. It seems like it hasn’t evolved much in the last 20+ years.
I had a small team make an attempt to use it at work. Our conclusion was that it was too clunky. Email plugins would fool you into thinking it was encrypted when it wasn’t. When it did encrypt, the result wasn’t consistently readable by plugins on the receiving end. The most consistent method was to write a plaintext doc, encrypt it, and attach the encrypted version to the email. Also, key servers are setup by amateurs who maintain them in their spare time, and aren’t very reliable.
One of the more useful things we could do is have developers sign their git commits. GitHub can verify the signature using a similar setup to SSH keys.
It’s also possible to use TLS in a web of trust way, but the tooling around it doesn’t make it easy.
I hate grammers in anything that don’t support trailing commas. It’s even worse when it’s supported in some contexts and not others. Like lists are OK, but not function parameters.
I setup my opnsense firewall for IPv6 recently with Spectrum as an ISP. I followed this howto from The Other Site:
Even as someone who has a background in networking, I’d have no idea how to figure some of that stuff out on my own (besides reading a whole lot and trying shit that will probably break my network for a weekend). And whatever else you might say about Spectrum, they have one of the saner ways to implement it; no 6to4 or PPPoEv6 or any of that nonsense.
I did set the config for a /54, but Spectrum still gave me a /64. Which you can’t subnet in IPv6. Boo.
Oh, and I’m not 100% sure if the prefix is static or not. There’s no good reason that it should change, except to make self-hosting more difficult, but I have a feeling I’ll see it change at some point.
So basically, if this is confusing and limiting for power users, how are average home users supposed to do it?
There are some standardization things that could make things easier, but ISPs seem to be doing everything they can to make this as painful as possible. Which is to their own detriment. Sticking to IPv4 makes their networks more expensive, less reliable, and slower.
S-expressions are basically directly writing the AST a compiler would normally generate. They can be extremely flexible. M-expressions were supposed to be programming part of Lisp, and S-expressions the data part. Lisp programmers noticed that code is just another kind of data to be manipulated and then only used S-expressions.
Logo is arguably a Lisp with M-expressions. But whatever niche Logo had is taken by Python now.
I’d like something akin to XML DOM for config files, but not XML.
The one benefit of binary config (like the Windows Registry) is that you can make a change programmatically without too many hoops. With text files, you have a couple of choices for programmatic changes:
That last one probably exists for very specific formats for very specific languages, but it’s not common. It’s a little more cumbersome to use as a programmer–anyone who has worked with XML DOM will attest to that–but it’s a lot nicer for end users.
Sometimes. Those can get canceled when they layoff the team after release.
Who are the real pirates?
If the end user is reusing passwords. Which, granted, a lot of people do.
On the flip side, we’re also forcing the use of JavaScript on the client just to handle passwords. Meanwhile, the attack we’re protecting against only works for reused passwords, and the attacker is inside the server and can see the password after transport layer encryption is removed. This is a pretty marginal reason to force the complexity of JavaScript.
Per your edit, you’re misunderstanding what Bitwarden does and why it’s different than normal web site password storage.
Bitwarden is meant to not have any insight into your stored passwords what so ever. Bitwarden never needs to verify that the passwords you’ve stored match your input later on. The password you type into Bitwarden to unlock it is strictly for decrypting the database, and that only happens client side. Bitwarden itself never needs to even get the master password on the server side (except for initial setup, perhaps). It’d be a breach of trust and security if they did. Their system only needs to store encrypted passwords that are never decrypted or matched on their server.
Typical website auth isn’t like that. They have to actually match your transmitted password against what’s in their database. If you transmitted the hashed password from the client and a bad actor on the server intercepted it, they could just send the hashed password and the server would match it as usual.
Mostly, yes.
I’d like to find a better way to phrase "why aren’t you . . . " questions. It carries an accusatory tone in text, even if you don’t intend that. The answer is almost invariably going to be either “I didn’t know it existed” or “because reason X”. Neither case justifies the accusatory tone. Maybe if the “I didn’t know it existed” answer was something so basic that they really should have known it existed, but probably not even then.