Related but in specific ways. Stock is often priced in anticipation of growth. If NVDA could meet its credit obligations while its real profit stayed flat, the two would diverge, at least for awhile. A large amount of NVDA’s current cash flow is likely purchase contracts with a fixed multi-year term, which further smooths out the impact of, say, a stock crash following a couple of quarters of terrible earnings.
Now, whether many things NVDA has invested in with expectation of repayment or earnings would be able to repay or appreciate in a market environment where Nvidia’s stock was crashing? That’s another question entirely.
Anecdotal, but I've been happily using it under Linux desktops for years, and it works quite well. Workloads include: development, VM hosting, steam gaming, web browsing, multimedia playback. OSes include Debian, Proxmox, vanilla Arch, CachyOS, and others. Daily-driver hardware (ignoring servers and less general-purpose desktop stuff) included 2019 chromeboxes, 2015 (!) laptops, current-gen gaming laptops, and desktop towers with handfuls of spinning rust and solid state drives.
It seems to work well in a variety of situations: 4GB/single-slow-SSD ancient systems work just as well as spinning rust bulk storage pools with NVME ARC/ZIL caches for my gaming/server/database datasets, and all-SATA-SSD pools can get to near-NVME performance with bonus redundancy for boot volumes and latency-critical stuff. For personal desktop use, I haven't found dedup worth the squeeze in RAM costs and tuning (it works, but it's generally easier to solve most dedup-compatible problems at a layer closer to the cause).
ZFSBootMenu and the ability to roll back to snapshots and restore/maintenance disks from outside of the primary operating system, without having to think about fallback boot drives or physical backup volumes, is a godsend in the "try random sketchy commands that might trash my installation in order to get a low-level driver problem resolved" and "I could take the time to understand what this curl | bash invocation does, but I have better things to do; I want to be able to reverse it if it breaks stuff" departments.
In general, I strongly recommend ZFS for daily-driver use. Its core primitives are quite flexible, it makes redundancy/backups/drive addition/replacement easy, and it works fine on old and under-resourced systems; the mythos of "it requires ECC and enterprise-grade hardware and tons of RAM/CPU to work at all" was always bunk. The enterprise/SAN features are there if you want them, but are off by default, and the core FS capabilities are widely useful. Even casual desktop Linux users would do well to set it up, since there are a lot of rare-but-real ordinary user needs that, if they come up and you're not running something like ZFS, can't be done at all unless you connect purpose-specific hard drives or reinstall your OS.
Especially now that NVMEs are so expensive, ZFS should be considered for its ability to make RAIDing up a set of slower drives (or mostly slow drives with an NVME cache) very easy. That way, you can make your existing disks into something that performs well enough that you don't need to spend money on new hardware.
Just don't install it via DKMS; get a distro that ships it compiled into the kernel or as an installable kernel-paired module. Many such distros exist. The DKMS edition won't eat your data, but you'll get real tired of failed system updates because the kernel changed some source and the compile failed. That happens often; turns out that the volume of the kernel API surface used by something as massive as the ZFS codebase is quite large.
Edit: upon reading back through this, I'm a bit sheepish that I sound like such a breathless shill. I promise I'm not in the ~pocket~ zpool of big filesystem. I just like it.
Agency isn't some magical axiomatic property where if you exercise it you're the sole contributing factor to your actions. Exercising agency, like making any other choice, is a decision whose inputs include your circumstances, history, etc.
Consider someone who quit smoking cigarettes in the 1950s. That was a time when cigarette smoking was common and not widely considered unhealthy. That person exercised agency. Now consider someone who quit in the 2020s, when cigarette smoking is widely warned against. That person exercised agency, too. More people quit smoking in the 2020s than the 1950s, by any measure. Does that mean people had less agency in the 1950s? No, it means the inputs to their decision-making on how to exercise their agency were different.
> a case where a normal person had genuine photos leaked and then just baldly denied everything
"Genuine" is doing a lot of work in that sentence. A big part of the threat model for image provenance/signing/similarity diffing is identifying when images aren't genuine--if they're from elsewhere than they're claimed to be from, or have been modified.
You're right that there are privacy/security costs to attributability, and that it's not always the right thing to do. I hope that keeping provenance information either entirely cryptographic in nature (okay, the image has a signature--you can't determine anything about that signature other than "signed with this key y/n" when you present a key) or reducing identifying or fingerprintable information presence in provenance metadata is sufficient to mitigate some of those concerns.
Dr. Neal Krawetz has written and researched a lot about this topic:
> For loads with over 20k rows/s and people pushing changes, you may need a full-time person to handle the cluster and take a look at the crazy queries people are going to write.
I think this was a benefit of DBA culture in previous eras. Not that the DBAs were specifically necessary to write good queries (often they'd need to work with application teams to guide them towards schemas/behavior that worked well) or to maintain the database (managed DB offerings obsolete a lot of this work), but because they functioned as gatekeepers and rate-limiters of what queries and schemas could exist.
In that mode, DBAs functioned a bit like a human/process version of a thin microservice wrapping database access functionality. A big benefit was that the rate of change of queries/schema changes/access patterns was controlled and had a higher probability of being reviewed and thought about by humans before it went live. This also resulted in an increased end-database-user culture of trying to make existing schemas/query patterns work before jumping straight to bespoke access patterns. That culture's not what you want as e.g. a startup or pro-rapid-big-refactors shop, but it is what you want when your DB reliability needs or query rate/dataset size are high.
I don't think it's a given that a gatekeeper team is worth the overhead and cost; that's situational. I do think that the code version of that team (aforementioned microservice that wraps DB accesses/schema changes and nothing else) is usually not worth the cost. In my experience, that pretty much always reduces reliability and free performance gains that come from using direct DB clients from user code.
Instead we're... listen to this... we're going to take a software developer right. Just a normal developer right. We're going to make them be the database expert right. And the cloud expert. And we're going to put them on call. We're going to have them debug linux logs, and optimize our AWS costs. They'll be there for client escalation work. And big sales calls. From time to time we'll even have them do front end work.
I think a DBA/ops/infrastructure person as an imposed bottleneck is a useful capability in some environments.
But I won't follow you as far as "expecting developers to have expertise in how and where their software runs is unreasonable".
Like, yeah, it sucks that added DevOps responsibilities etc. don't come with adjusted compensation/time allocation expectations. I'm with you there.
But it's simultaneously true that a ton of "just regular developer" people are significant liabilities because they don't understand anything about the environment where their software runs. That liability manifests operationally (if someone's just running integration tests on Windows for their Java business logic changes and don't have any familiarity with e.g. the Linux, container, or cloud environments where their code runs, they're going to be useless when their code breaks in production and operations staff needs context), and it also makes them less effective when writing code--this culture of "developers should just live in business logic and not have to context-switch or fill their brains with other levels of the stack" is what leads to full table scans, lack of awareness of memory use, N+1 query hell, looping microservice dependencies, misunderstanding of what HTTP fields are set on requests that are mutated by load balancers, mistaken assumptions about how many instances of code can run and what concurrency/thread/coroutine behaviors are present, and so on. Those are very common problems, and it's incumbent on developers in every specialty to gain familiarity with how and where their code runs in order to write and maintain that code effectively.
If your code runs on Linux in Kubernetes, all of your developers should know how to read Linux system logs, check database sessions/queries issued by parts of the application, ls/grep/cat/strace/ps their way around, interpret k8s/application dashboards, check application logs both in log storage and as they're emitted from a process, exec into a container, restart pods, check deployment liveness, etc. Even if they don't have permission to do those things in production.
That was true in 2005 when they deployed their code to IIS on Windows Server/MSSQL, too--just with different operational specifics.
That's a low bar that's often unmet, and all sorts of teams suffer from that failure. Those skills can be trained, kept up to date, and hired for; I don't think there's a great excuse for not expecting them.
Apologies my comment was very tongue and cheek. I understand what you're getting at with regards to dedicated DB style teams being a potential bottleneck and not effective for every organization, as for example most orgs get by fine with a simple RDS instance with minimal management and optimization.
What I'm calling out practically is a de-specialization in roles and the trade-offs it imposes.
For example, the "jack of all trades master of one" that was already propagating under the guise of "Full stack engineer" or "DevOps" is further exasperated when those consolidated roles are also delegating critical knowledge acquisition to LLMs.
Further, as we consolidate roles and delegate knowledge acquisition to llms, we're also paying people less, giving less job security, lowering the general quality of life not just for developers, but for operations staff and users, and generally promoting total consolidation within big tech.
No apology needed; I understand what you're getting at, and I broadly agree. It's a spectrum between "extremely easy-to-hire people that operate in such a narrow niche that they're an operational liability with limited capabilities" and "expect everyone to be an expert at every level of the stack". The right point on that spectrum is different depending on context, but I do think that a majority of software shops would be better served by moving their required skillset more towards the generalist end of that spectrum, because the default is often far too niche (driven by poor tradeoffs and short-termism in service of growth/hiring, usually).
I wanna re-emphasize that this is not a new problem. It's not because of DevOps culture or cloud complexity or scale or whatever. Very limited-specialty people were always operational liabilities and had limited positive impact on feature delivery once you accounted for the help they needed to do anything that spanned multiple levels of the stack. There are just more engineers working on more systems with tighter timeline expectations now, so it seems like the complexity incumbent on the engineering role went up in general. It didn't (it went up in some situations and down in some situations), we just started noticing operational pain more often.
I definitely do agree that there's widespread ignorance of the velocity and difficulty-of-work tradeoffs that arise from requiring a wider range of specialties from engineers, and a similarly widespread failure to adjust compensation and timeline expectations accordingly.
What's worked really well for us is not having the DBAs as gate keepers, but rather having them as guardians and experts for devs to rely on.
Our DBAs are the first line of defense when a DB starts to struggle. They crack the database open, see what's going on, and troubleshoot and sometimes fix the problems. If it's just a simple stored proc change or table change, our DBAs are empowered to go in and fix them. If there's a code change needed, they work with the devs to fix the code.
But by and large the devs still write most of the queries and tables. We as devs get DB training, but we also have a very open door policy with the DBAs so the devs can lean on their expertise and ask advice before sending stuff out. Our devs get a much better sense of "This seems like it could be expensive, let's talk to the DBAs and see what they'd suggest".
It's worked great.
I think any company would benefit from this sort of subject matter expert employment.
I usually see full-stack and DevOps roles as being a creation of the startup and early growth phases of a company. In those phases, the market and product definition is changing rapidly. Whatever you lose in reduced technical depth of these engineers, you gain in reduced communication costs, faster ability to make changes, and additional context and ability to spot efficiencies because they understand the full stack. And these companies are usually default-dead anyway, so if they screw things up and cause an outage, it's no worse than if they build the wrong product and have no users.
I've never seen a DevOps role in Big Tech (I've ping-ponged back and forth between the startup and FANG worlds a few times), and usually a full-stack engineer is someone very senior who designed a lot of the product when it was young and stuck with it for a decade. Instead there's usually a clear SRE/SWE split, and hyper-specialization, enough that someone might actually become the expert on one particular screen of a mobile app.
If you're frustrated with the de-specialization of roles, it's entirely possible you're working at companies at the wrong stage of their lifecycle. Move to a big company and the struggle is to avoid becoming pigeon-holed into one very specific task (and then laid off when the structure of the product changes so that task is no longer necessary). Such a career change can be challenging at first because your career can get specialized to "working for startups and early growth companies", and then big companies won't even look at your resume. But if you try enough places and say in the interview that you're looking for a place where you can really specialize and develop expertise, you can often find a manager desperate enough to take a chance.
LLMs are another issue. I'm worried that they're going to make the economy very unstable because the whole reason a firm exists is to capture institutional knowledge and the LLM captures that institutional knowledge in the model, where a.) it's not specific to a differentiated business and b.) it's subject to model-collapse issues. Could easily see the whole technological world collapse through lack of expertise, but if that happens it's a bigger problem that you can only fix by developing the expertise yourself.
> Such a career change can be challenging at first because your career can get specialized to "working for startups and early growth companies", and then big companies won't even look at your resume.
How would you suggest to approach such a career change successfully?
> But I won't follow you as far as "expecting developers to have expertise in how and where their software runs is unreasonable".
In my professional experience, management tends to treat this as a dichotomy rather than a range. And its lead to situations where we're choosing to route every decision through a small number of 'experts' and expecting that to scale, or have people make very bad decisions about things like indices, data layout, etc.
I align with you on this. If you are using some sort of system, there is a sort-of minimum bar of expertise one should acquire. When using analytical platforms, having a basic understanding of how data is stored and the levers it gives you to optimize data processing should be standard.
Some examples:
MySQL - I would expect developers to be able to come up with a list of columns to index and why, understand why UUIDv4 is a bad choice for primary keys, know how to write performant SQL by hand and understand when their ORM is going to do the wrong thing, etc.
Redshift - Understand dist and sort keys and have some mental models on how data shuffles and is pruned based on each choice.
Iceberg + Spark/Trino - Understand that data tends to be stored/loaded as batch files. Understand how deletes work. Understand partitions and sort as options. Understand generally how bloom filters work and when you should decide to place a bloom filter. Understand why UUIDv7 is better than UUIDv4 when its part of a partition key.
Eerily accurate how it works these days, I wish you weren't correct. I met a DBA wizard (he looked like the creator of c++) at a banking IT dept and this guy intuitively sensed what you needed and how its done.
And don't forget contract management with the supplier, L1-L2-L3 support, all in one, and integrating as the supplier is useless and your contract is shit.
Oh and you will do also business analysis with the business as claude is too complex for them (read any version of the nocode initiative).
Why are you complaining? You should be grateful of the learning opportunity not everyone gets to have. Sure, we pay you peanuts for it. But, it's ultimately for your own good. Don't mind my yacht and Ferrari, though.
That kinda how moving from programmers + sysadmins to devops looks like.
Managers went happy coz now they don't need to have hire sysadmins, while in reality they hire sysadmins, call them devops, and have them know some programming on the side.
And the "savings" from not having onprem infrastructure are burned on expensive cloud and debugging cloud blackboxes
Most startups can just scale your traditional separation of compute & storage here though. You’d be shocked how well duckdb against s3 scales for 99.9% of use cases
It's one thing to be able to scale database compute/storage; it's another thing to be able to partition it. It's extremely common for bad queries/access patterns to cause noisy-neighbor effects on other simultaneous accesses to the database, to the extreme of knocking the whole database over with timeouts/OOMs/etc.
Scaling out DB compute can only help with that to a (expensive) point; eventually, you end up wanting to either prevent the bad queries from being added to the system (DBA culture) or ensure that the bad query runs on database infrastructure that doesn't affect other queries. That's why partitioning DB compute (and storage: noisy-neighbor effects from a bad query at the storage layer don't require storage to be running e.g. a BookKeeper or whatever on a server; they can manifest as hot S3 keys or cloud object/block store rate limiting) is a necessary capability if your plan for dealing with a culture of "anyone can add any access pattern they want" is to scale the DB.
Iceberg & Delta Lake do partition the data. You can add as many DuckDB servers processing them as you want, each app can have as many as you need. You pay Amazon for all the I/O and let them worry about it scaling it.
I'm not saying there is no point of contention - depending upon your write patterns you have practical limits, but for reading data that is already stored you pretty much just pay more to do more and the rate of that cost is close to linear.
I'm sure there is a scale at which that pattern breaks, and I'm sure 99.9% of people reading this will never operate a system at that scale.
Iceberg addresses the hot s3 key prefixes. It places entropy in the prefix path per object so reads/writes are randomized over the bucket key prefix space.
It’s much less of an issue. Also, 99%+ of Aws customers likely don’t have enough QPS to hit the per prefix limits anyway
Most software developers now are absolutely ignorant of performance concerns. Just throw more compute at it until it works, and someone else will pay the AWS bill.
I think the answer to this is roughly ... the content of an applied statistics degree, or a research methodology practicum. There are so, so many ways that quantitative measurement of human phenomena can mislead, from measurement error to conflation between trends/sample sizes/effect sizes, to p-hacking, to good old bias (in interpretation or in deciding what tools to use to smooth or normalize data), and thousands more.
Pedantically, colored functions in Go might be ones that produce their output on a channel rather than returning a value. Then, you need select/for-range/<- to get their result, similar to “await”.
Practically, the runtime’s ability to suspend and move goroutines around means that the impact of that (niche/rarely appropriate as a default approach) kind of coloring is much less in Go than in other languages.
You don’t have to have all of that material published and polished before you turn your website live. It literally is stuff that belongs on your marketing Wordpress static site or whatever.
If the founder had done a big b2b ad blitz without that stuff, sure, some griping might be warranted. But this isn’t that: some fledgling product website went viral-ish in HN and you’re complaining about the digital equivalent of the paint not being dry.
It’s rife with “and that’s the important thing. $thing”-type constructions. Human writing uses those much more sparingly and doesn’t separate them into two sentences as often. It has a lot of “subject change: teaser” constructions, too. And overuse of bold and restatement.
Could it be human? Sure. But it doesn’t seem likely to me.
Now, whether many things NVDA has invested in with expectation of repayment or earnings would be able to repay or appreciate in a market environment where Nvidia’s stock was crashing? That’s another question entirely.
reply