jwatte

But if they had a cheaper support model, the large corporations would also pay less, and they'd make even less money overall. Not to mention: support engineers are expensive, and researching tickets take a lot of time.

I don't quite understand the "ads it deems necessary for me to see" comment. You will always get ads on sites that serve ads. The thing the tracking might do, is change which particular ads you get. The right solution to that, is to use an ad blocker, and to pay for sites that have an ad-free alternative.

Also, fingerprinting isn't always "bad" -- any business who takes credit cards online, wants to try to exclude people who will commit fraud (because they might have done it before.) Preventing fingerprinting, means you prevent certain anti-fraud, which means that you see higher prices and more friction doing commerce online, which also affects your experience. The connection is just much less direct.

The logical conclusion at the end is ... www.observeinc.com ? Nice :-)

That kinda depends on what custom_condvar_wait() does, right?

If the goal is to remove bad execs, then a document trail can help, although I'd suggest starting with some statistics like "over the last 3 months, we moved the goalpost 8 times, which led to an effective throughput of 4 weeks of work being done rather than the expected 12 weeks. How do you think we could improve these conditions?" Collaboration first.

Keeping email threads for reference is probably plenty data enough, btw; "signatures" sounds like the wrong approach. Maybe even just summarize the direction given in a wiki document with a change log with time stamps and requesting person, which you can review once in a while, and the sheer length of it might be enough to bring the point across.

> with no source control

This is bad.

> It's all require_once. > it doesn't use any framework

This is not necessarily bad.

> no code has ever been deleted

This is bad

> Multiple versions of jQuery

This is bad

> a full rewrite is necessary, but how to balance it?

You never need to fully rewrite something. You can always take an incremental approach. If the code and 3 people generate 20 million dollars of revenue (on their own? or with massive sales support? what is the cost of goods?) then it's got to be doing something right.

I'd start with the source control. Just check everything in, so it's easy to go back. Do that on the server they develop on, even. (But have a script that pushes the checked-in code to offsite.)

Second, make it possible to spin up a second instance of the same application, in some automated fashion, out of bare source control. This may mean dumping schemas and checking them in, and probably figuring out what data in the database are "necessary configuration" versus "user payload data."

Then, you can initiate integration testing on top of the second cluster. You can also turn this into some kind of local sandbox development setup.

Once that is done, you may be able to change the code quicker, because you can do and test it locally, and perhaps have some acceptance tests on top of the mudball. At that point, you can switch over to doing development locally and deploying (and, ideally, having the ability to un-deploy.)

After that, starting to clean up should at least be possible with less risk, because you can test it in isolation. You can then start pulling on threads in the code, such as standardizing library versions, detecting and deleting unused code, putting like modules together, and so on.

You don't need fancy tools for managing this, shell scripts and command-line git are probably plenty enough. Resist the temptation to spend six months engineering the build system of the future!

Of course a lot will depend on details, but from your brief description, this sounds like the path forward -- focus on making it possible and safe and cheap to iterate, and then you can get on with actual iteration. Don't waste time on big rewrites; instead do things incrementally. Don't believe that any one tool will save the day, because it won't.

I like how this aligns vendor needs with customer needs. If I use more of it, it means I'm getting more value out of it.

Meanwhile, an Oracle sales person would love for you to sign a yearly contract, then ignore the license until it's time for the next renewal.

(This is also how Amazon and Azure beats out HP and Dell.)

This is probably a better comparison than one might at first think.

A game engine has a second, hidden, part of the iceberg: The production pipeline for all the 3D world/art assets.

That's actually where most of the work goes -- hundreds of artists go into a AAA game, and all the art they produce must be technically excellent along a bunch of dimensions that have nothing to do with what it looks like (and in fact, generally make it harder to achieve the look you want.)

Game engines that can wire physics simulation to 3D rendering to window abstractions are easy-ish to make, similar to how web UI frameworks are easy-ish to make.

All the production pipeline stuff is where the real meat is, similar to how in WebUI and, package management and transpiling and bundling and deploying is a hard problem. I think the game side has it even harder than the web side, though, although they usually have the benefit of only needing to work on a defined set of platforms, rather than in "the" browser.

Trunk driven development has worked well everywhere I've used it.

That being said, pull requests / code reviews / merge commits are totally compatible with that. Gerrit, for example, does every commit as a mini-pull-request on top of a branchless HEAD, and when the review finishes, you merge to main/trunk and off to CD it goes.

Jevons Paradox: Applied economics in pricing. Nice!

I would expect the code to crash when passed a null pointer, absolutely! And the if statement is there to let me recover after using "continue" in the debugger. And if I run on an ISA without protected memory, that load will not actually crash, and I'm OK with that. That's a level of UB differing-behavior (more like ID, really) that's reasonable.

I know of no experienced C programmer who would expect the compiler to re-order the statements. That sounds very much like a strawman argument to me!

I'd also be OK with a compiler that emitted a warning: "This comparison looks dumb because the rules say it should do nothing." Emitting that warning is helpful to me, the programmer, to understand where I may have made a mistake. Silently hiding the mistake and cutting out parts of code I wrote, is not generally helpful, even if there exist some benchmark where some inner loop will gain 0.01% of performance if you do so.

After all: The end goal is to produce and operate programs that run reliably and robustly with good performance, with minimum programmer cost. Saying that the possible performance improvements of code that nobody will run because it's buggy absolutely trump every other concern in software development, would be a statement I don't think reflects the needs of the software development profession.

The concept of "friendly C" is not new, and this is one of the straw men that it knocked down, because it is actually possible to define "what I mean."

It's totally OK to say that an out-of-bounds write may or may not be detectable by reading any particular other local or global variable or heap value. That doesn't in turn translate to compilers being allowed to turn a bug in a SPECint kernel into an empty infinite loop (a case that happened!)

> That has become increasingly plausible to me as I’ve grown older and have more money than time.

Indeed.

Everybody's focusing on the type stuff, which is nice -- but luau also just performance better than Lua in a bunch of cases. Arseny (from Roblox) has tweeted a bit about it. It's interesting to follow!

Super happy to see this released, and also for all the kids getting started programming on Roblox learning that there is a better way than random tag-checked mush :-) Good on you all!

I've found one source of vocabulary to come from research into the temporal relational algebra and temporal databases.

For example: https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.47... (This being a not fully settled / exploited area of computational science, there are plenty of alternative interpretations, too.)

The main challenge here is that extending relational algebra ("key tuple maps to row") into time ("key tuple maps to function from time to row") essentially cross-products two different dimensions, creating a much bigger domain to process and reason about.

Once you have the theory down, you can express some pretty handy relationships.

For you functional folks, you can consider the TRA as the regular RA lifted into the time monad. Except the composition can also go cross-wise; TRA can also be considerd as the narrow timeline lifted into the relational monad. Fun times!

Interesting project by an interesting game technology developer!

The battery is probably the least sensitive part to noise. In fact, the battery may be able to filter/absorb a lot of noise, as long as it's charging, because it's a strong current sink and it has low impedance. (You may still have ground loop problems and other resistive voltage dividers that let the interference get to other places.)

The circuits in the phone may be damaged by excessive spikes. Especially if the spikes happen to be of a frequency that the internal filters / regulators in the phone aren't good at rejecting -- some regulators may only reject 20 dB of noise in certain bands, and > 80 dB in others.

10C isn't an absurdly fast charge rate if your battery has very low internal resistance. Drone / RC people have been doing that (and more) for years, as their batteries are often made for 50C+ discharge rates.

Google "balanced power for tube amplifiers" and see how far that rabbit hole goes ...

(And it's not all superstition, and it's not all for tube amps -- it's all in the SNRR of your power stages for every piece of equipment in your sound chain.)

Even if you maintain Kafka for business logic, you don't want to run your observability in the same Kafka cluster, because then when the business Kafka goes down, how will you debug it?

Depends on where they're coming from. If all they know is Java, then surely not! If they've done Python and C and Erlang before, the switch doesn't seem as hard.

A good functional language lets you clearly define, manage, and trace where your code meets reality, though. That kind-of needs strict static type systems, rather than loosey-goosey dynamic tag checking, though. That's IMO the main reason statically type checked languages like C++/Java/etc work much better at large scale than runtime tag checked languages like Python/Clojure/etc.

HTTP is super great for loosely coupled, request-based services.

RPC is more lightweight for persistent connections to stateful services. RPC makes broadcast easier than HTTP. Individual RPC requests have (much) less overhead than HTTP requests, which is very helpful when tight coupling is acceptable.

Trying to run, say, MMO gaming servers over HTTP is an exercise in always paying double for everything you want to do. (Also, trying to run a FPS gaming server over TCP instead of UDP is equally not the right choice!)

Nerds believe that truth is more important than interpersonal alignment.

Most HN commenters are wrong. A mirror DOES flip one coordinate; the coordinate that is orthogonal to the plane of the mirror. That's what makes it a mirror, and not a window.

The mirror DOES flip one coordinate, the "hither" versus "yon" coordinate. If you hold a paper of text up against the mirror, and it looks mirrored, then you can notice that the original text ALSO looks inverted to you, if the paper is translucent. Right is right. Up is up. However, "hither" becomes "yon." Exactly like we would expect by looking at the math for reflection in a plane.

Helm is an example of what I mean by "pusing against the boundaries." We tried using helm, but we kept running into limitations, and the complexity of trying to customize charts that didn't work right ended up being worse than the original problem. Currently, we're using kustomize, plus a thought out manifest hierarchy, which is working out better.

"Simple" solutions to "complex" problems, by necessity, only work for certain subsets of the problems. Modern distributed systems have tons of largely essential complexity. The only way to reduce it, is to reduce the expressive power of the solution, which might be great for the cases where you fit into the mold, but then fails spectacularly (either with excess resource consumption, or by not working at all) when you push against the boundaries.

Business was at a standstill in 2008. It takes 8-10 years to go from embryo to IPO these days. Thus, a lot of companies got started in 2010-2012, and are now reaching IPO maturity. I think this is a "ketchup bottle" effect rather than a sign of the end times.

(That being said, the end times may ALSO be upon us, but not because of this particular sign.)