MySQL’s concurrency control is a limit on the total number of threads that can be active at once, across all queries.
Traffic Control limits concurrency and resource use according to configurable metadata like the username, remote address, or the contents of any sqlcommenter tags included in the query. So you can say things like “the batch processing role can’t run more than four queries at a time.” The finer granularity is key.
Now you have to maintain the automation. There is nothing wrong with that. There is nothing wrong with building your own server. There is nothing wrong with colocation. There is nothing wrong with driving to the colo to investigate an outage. There is nothing wrong with licensing arm and having TSMC fab your chip. There is nothing wrong with choosing which level of abstraction you prefer!
This is all trivial, and can and should be automated. Furthermore, all of your arguments can easily be applied to NodeJS version deprecations, React realizing they shipped a massive CVE, etc.
I will die on this hill: parent is correct - the ability to manage a Linux server should be a requirement to work in the industry, even if it has fuck-all to do with your job. It proves some basic level of competence and knowledge about the thing that is running your code.
I'm curious about this trivial automation. Let's say the new OS LTS version no longer includes nginx, because it was replaced by a new product with different config. How does the automation figure out what the new server package is and migrate your old Nginx config to the new format?
I agree with Node.js version deprecations being a huge problem and personally advocate for an evergreen WebAssembly platform for running apps. Apps should run forever even if the underlying platform completely changes, and only require updating if the app itself contains something that needs updating.
The answer is to write your server in portable C++, and just rebuild it for whatever new OS you're dealing with.
The speed. Imagine the performance. There are plenty of mature C++ web server frameworks, it's really not difficult. If you're afraid of C++, you could choose something else. Rust if you're insane, or golang if you're insane but in a different way.
Anyway. Nginx is not going away, so the argument is a bit silly. "What if js went away". Same thing.
If an LTS of an OS replaced nginx with something else, a. it would be announced with great fanfare months in advance b. if you don’t want to do that, add apt / yum / zypper install nginx to your Ansible task, or whatever you’re using.
The things that you just described are not automation, but human activities needed to tackle the new situation by following news and creating new automation. Which kind of proves my point that you cannot prepare for every unexpected situation before it actually happens. Except maybe with AI in the future.
When AWS announces that they’re EOL’ing the Python or NodeJS version in your Lambda, or the version of your RDS cluster, etc. you also are required to take human action. And in fact, at any appreciable scale, you likely want that behavior, so you can control the date and time of the switch, because “zero downtime” is rarely zero downtime.
Yes, and like I mentioned in another comment, I consider this a major painpoint and problem with Node.js based applications. I have high hopes that eventually there will be an "evergreen" WebAssembly based Lambda function runtime.
I keep reading posts like this, but the people who say this never actually seem to enlighten the rest of us troglodytes by, say, writing a comprehensive, all inclusive, guide to doing this.
If it's so easy, surely it's no big undertaking to explain how one self hosts a fully secured server. No shortcuts, no "just use the usual setup" (we don't know what it is!), no skipped or missed bits. Debian to Caddy to Postgres, performant and fully secure, self upgrading and automated, from zero to hero, documenting every command used and the rationale for it (so that we may learn).
The parent I responded to was discussing issuing certs, configuring SSH keys, and updating an OS. Those are all in fact trivial and easily automated.
What you have stated requires more knowledge (especially Postgres). You’re not going to get it from a blog post, and will need to read actual source docs and man pages.
The original claim was "People shouldn't even be in the industry unless they can administer a Linux server, even if that has nothing to do with their role." It is a very significant moving of the goalposts to now suggest this is all about "updating an OS". That's not a good faith claim.
This whole thing is merely cheap online snark masquerading as wisdom. No, not all SWEs know how to maintain Linux servers, and many (most?) SWE roles have all of zero overlap with that kind of work. If businesses could fire all their expensive server admins and replace them with some college kid and a $5 VPS, they would long since have done so.
If this is anything more than poseur snark, put your money where your mouth is and either write a comprehensive resource yourself, or at least compile a list of resources that would suffice for someone to be able to securely run and maintain a live server in production. No, not Hello Worlds, actual prod. Then, when next this comes up, link us to your guide rather than just spraying spittle on the plebs who lack your expertise.
Do something more constructive than low effort snark.
They don't write the guide because by the time they've written the guide to an appropriate level of specification, the result they've produced is an off-the-shelf service provider not unlike the ones they're railing against.
> The sqlite_sequence table is the most underappreciated debugging tool in SQLite. It tracks the highest auto-increment value ever assigned for each table — even if that row was subsequently lost.
> WorkQueueTask.count returns ~300 (current rows). The sequence shows 3,700+ (every task ever created). If those numbers diverge unexpectedly, something deleted rows it shouldn't have.
Or it means that SQLite is exhibiting some of its "maybe I will, maybe I won't" behavior [0]:
> Note that "monotonically increasing" does not imply that the ROWID always increases by exactly one. One is the usual increment. However, if an insert fails due to (for example) a uniqueness constraint, the ROWID of the failed insertion attempt might not be reused on subsequent inserts, resulting in gaps in the ROWID sequence. AUTOINCREMENT guarantees that automatically chosen ROWIDs will be increasing but not that they will be sequential.
> No ILIKE. PostgreSQL developers reach for WHERE name ILIKE '%term%' instinctively. SQLite throws a syntax error. Use WHERE LOWER(name) LIKE '%term%' instead.
You should not be reaching for ILIKE, functions on predicates, or leading wildcards unless you're aware of the impacts those have on indexing.
> json_extract returns native types. json_extract(data, '$.id') returns an integer if the value was stored as a number. Comparing it to a string silently fails. Always CAST(json_extract(...) AS TEXT) when you need string comparison.
If you're using strings embedded in JSON as predicates, you're going to have a very bad time when you get more than a trivial number of rows in the table.
> Writing assembly is probably completely irrelevant.
ffmpeg disagrees.
More broadly, though, it’s a logical step if you want to go from “here’s how PN junctions work” to “let’s run code on a microprocessor.” There was a game up here yesterday about building a GPU, in the same vein of nand2tetris, Turing Complete, etc. I find those quite fun, and if you wanted to do something like Ben Eater’s 8-bit computer, it would probably make sense to continue with assembly before going into C, and then a higher-level language.
Some things are just enjoyable. I get no real utility from photography - it’s not my career, it’s not a side gig, and I’m not giving prints out as gifts. Most of the shots never get printed at all. I do it because I enjoy the act itself, of knowing how to make an image frozen in time look a particular way by tweaking parameters on the camera, and then seeing the result. I furthermore enjoy the fact that I could achieve the same result on a dumb film camera, because I spent time learning the fundamentals.
I would love to see someone attempt to do multiplication who never learned addition, or exponentiation without having learned multiplication.
There is a vast difference between “never learned the skill,” and “forgot the skill from lack of use.” I learned how to do long division in school, decades ago. I sat down and tried it last year, and found myself struggling, because I hadn’t needed to do it in such a long time.
Most people learn multiplication by counting, it has been in basic mathbooks since forever. "1 box has 4 cookies. Jenny ha 4 boxes of cookies. How many cookies do Jenny have?" and so on, the kids solve that by counting 4 cookies in every of the 4 boxes and reaching 16. Only later do you learn those tables.
That’s definitely not how I learned it, nor how my kids have learned it. I vividly remember writing out “2 x 3 = 2 + 2 + 2 = 3 + 3.” I later memorized the multiplication table up to 12, yes, but that was not a replacement of understanding what multiplication was
Tangential, I bought a nearly identically-spec'd (didn't spring for the 8 TB SSD - in retrospect, had I kept it, I would've been OK with the 4 TB) model, and returned it yesterday due to thermal throttling. I have an M4 Pro w/ 48 GB RAM, and since the M5 Max was touted as being quite a bit faster for various local LLM usages, I decided I'd try it.
Turns out the heatsink in the 14" isn't nearly enough to handle the Max with all cores pegged. I'd get about 30 seconds of full power before frequency would drop like a rock.
I haven't really had a problem with thermal throttling, but my highest compute activity is inferencing. The main performance fall-off I've observed is that the cache/context size to token output rate curve is way more aggressive than I expected given the memory bandwidth compared to GPU-based inferencing I've done on PC. But other than spinning up the fans during prompt processing, I'm able to stay peak CPU usage without clock speed reducing. Generally though this only maintains peak compute utilization for around 2-3 minutes.
I'm wondering if there was something wrong with your particular unit?
CPU performance was acceptable; GPU was the one was that falling off a cliff.
Re: particular unit, I’m not sure - it was perfectly fine during anything “normal,” and admittedly, asking a laptop to run at 100% for any extended period of time is already a big ask. But it’s possible, I suppose.
I’m waiting for the Studios to get the Max and / or Ultra, and will reconsider if I want one, or if I don’t really need to play with local LLM at this time.
If you’re writing the script to be used by multiple people, or on multiple systems, or for CI runners, or in containers, etc. then there’s no guarantee of having Python (mostly for the container situation, but still), much less of its version. It’s far too easy to accidentally use a feature or syntax that you took for granted, because who would still be using 3.7 today, anyway? I say this from painful recent experience.
Plus, for any script that’s going to be fetching or posting anything over a network, the LLM will almost certainly want to include requests, so now you either have to deal with dependencies, or make it use urllib.
In contrast, there’s an extremely high likelihood of the environment having a POSIX-compatible interpreter, so as long as you don’t use bash-isms (or zsh-isms, etc.), the script will probably work. For network access, the odds of it having curl are also quite high, moreso (especially in containers) than Python.
If you're distributing the script to other people then the benifit of using python and getting stuff like high quality argument parsing for free is even greater.
> often there's no real substitute for pulling a couple of terabytes locally and going to town on them.
Fully agree. I already know the locations of the logs on-disk, and ripgrep - or at worst, grep with LC_ALL=C - is much, much faster than any aggregation tool.
If I need to compare different machines, or do complex projections, then sure, external tooling is probably easier. But for the case of “I know roughly when a problem occurred / a text pattern to match,” reading the local file is faster.
0: https://dev.mysql.com/doc/refman/8.4/en/innodb-performance-t...
reply