To play devil's advocate here, imagine a world where the exact opposite has occurred: physical media (CDs specifically) is the norm, and there's no DRM, so the raw data can be copied right off of it. In this world, scalpers scoop up all available inventory of physical media from local retailers, consumers pay a premium to them for the original product, the scalpers sell cheaper copies where the game binary has been modified to insert advertisements or mine cryptocurrency, out of the woodwork appears a cottage industry of companies offering services to modify game binaries and connect them to the ad networks and crypto exchanges. The scalper gets a cut, the gamer gets a cheaper game, everyone is happy.
I'm with you but I see a bigger problem. I'm not sure if you noticed but there are threads of low desire within our society. Young people, in particular young men, increasingly seem to be checking out of dating and higher education, both examples being paths towards enriching oneself. As these people age, lose mental plasticity, and become entrenched in their ways, how likely are we to be able to convince them to begin valuing those things again?
I'm less concerned about the impact of AI specifically and more about concerned about people simply losing the will for one another or anything at all. None of this stuff in the real world will matter too much if people are getting their basic needs and desires met in a virtual one.
The rhetoric of this comment seems to imply that this is a bad thing, but is it really? If it becomes more difficult to make money through creative endeavors, then that leaves us with fewer reasons to be creative other than for the sake of self-expression... which is what we want, right?
I'm surprised that there's been no mention of Operation Paperclip, neither in the article nor in the comments here. Seems like a huge part of the story to leave out.
It's about writing code that your peers can read. "DO NOT SUBMIT" is clear as day. "ASDFASD" probably does not mean "this is a debugging string" to most people.
I live in an apartment complex that uses RealPage. My roommates and I re-signed the lease earlier this year, with a projected 15% rent price increase. We then walked to our leasing office to ask about it, they simply cancelled the increase. We're now paying the same rate we were last year.
I am fairly certain that 15% increase was the automatic recommendation by RealPage.
There are plenty of projects smaller than the Linux kernel that have developed and employed DSLs (to varying degrees of success, I'll grant). I wonder, are there any languages out there designed specifically for kernel programming?
Given the number of preprocessor hacks used in the kernel, and the amount of GCC-specific behavior that the codebase depends on, it seems like they are already halfway there.
I gained a a few years of experience in SQL-based OLAP systems at my current job. In this time I developed a strong appreciation for SQL, especially for its composability. Recently, I started a project in Google Colab, gluing together queries from several systems with Pandas DataFrames. I can honestly say that I've never been more frustrated learning an API than I have with Pandas.
Need some window function like LAG() or LEAD()? Too bad, I hope you like writing Python "for i in range(...):" loops. My notebook is littered with ".reset_index()" calls, ".replace(np.nan, None)", "axis='columns'", "foo.assign(bar=lambda df: df.apply(lambda row: ...))". groupby is especially confusing to me, as a Pandas GroupBy is difficult to compose with a normal DataFrame until you call .reset_index(). Compare this to SQL, where a subquery is a subquery, whether or not it has a GROUP BY clause.
The Pandas documentation also leaves a lot to be desired. Take the documentation of pandas.NaT[1] for example. "pandas.NaT: alias of NaT". Ok? That still doesn't tell me what NaT is, nor does it link to the thing that it aliases. The groupby documentation[2] also caused me some headaches, as it covers only the simplest aggregation use-cases.
Pandas is clearly better for some use-cases, but mostly for simple operations that are well-supported by the API (perhaps numeric operations that are implemented with native numpy routines). But if I'm doing some interactive OLAP stuff, I'll reach for SQL. Perhaps the problem is I'm trying to use Pandas like it's SQL, when it's not. But for manipulating data, I'd rather use a language than a library.
Oh, I'm not arguing that using checksums, SHA for example, for integrity verification is a bad idea. That's what they're designed for, after all.
However, I do think it's a bad idea to enforce the content of compressed archives to be deterministic. tar has never specified an ordering of its contents. Compression algorithms are parameterized for time and space, so their output should not be deterministic either. Both of these principles apply to zip as well. But we now have a situation where we are depending on both the archive format and the compression algorithm to produce a deterministic output. If we expect archives to behave this way in general, we set a bad precedent for all sorts of systems, not just git and GitHub.
I wonder if this incident will encourage our industry to build more robust forms of artifact integrity verification, or if we will instead codify the status quo of "we guarantee repos to be archived deterministically." To me, the latter seems like a more troubling precedent.
There's more nuance to it than that, so let me try to clarify again. Like you said, the accelerometer shows the difference between the casing's reference frame and the internal's reference frame. The internals ideally maintain an inertial reference frame. It's only "designed" to show 0g in free-fall because the difference between the reference frames of the casing and internals _is_ 0 when you are falling. Because, again, when you are falling, you are in an inertial reference frame - you are not accelerating against the flow of spacetime.
The only time the accelerometer reads something other than 0 is when something pushes it away from an inertial reference frame. This is true when you're on the ground: spacetime is curved, and "flows" towards the center of the Earth. The ground pushes you against the flow of spacetime, and the difference between these two frames of reference is 1g. Note that this 1g is not "caused" by gravity, it's caused by the electromagnetic force. Forces push matter away from an inertial reference frame. Gravity is different. It decides where an inertial reference frame goes by curving spacetime - it is not a force.
Hypothetically, if you were are the center of the Earth, the accelerometer would read 0g. There would be nothing pushing you in any particular direction - you would be in an inertial reference frame (ignoring the minor detail of being crushed by all of the Earth's mass).
Again, I'm trying to show the subtle difference between accelerating compared to a fixed coordinate system, and accelerating compared to an inertial reference frame. The fixed coordinate system does not take into account the curvature of spacetime. If it did, the coordinates would be "accelerating" towards the center of the Earth at 1g - congratulations, you've defined an inertial reference frame.
I hope that makes sense. It blew my mind when this idea clicked: that space and time are not two distinct things, they are two parts of the same thing.
There's a difference between accelerating compared to a coordinate system, and accelerating compared to an inertial rest frame. If you set a fixed coordinate system relative to the ground, then yes, the cat is accelerating towards the ground.
Consider this: if you hold an accelerometer while stationary on the ground, it will read 1g (accelerating). If you read an accelerometer while in free-fall, it will read 0g (ignoring wind resistance). In the first scenario, you are accelerating compared to your rest frame, even if you are standing still.
This is not an arbitrary distinction either. The 1g of acceleration while stationary on the ground produces measurable relativistic effects.