duped

It feels like the problem are the SAT prep courses' existence then

I don't deny their efficacy, I'm saying that there's a massive crop of grifters and liars building them and using them.

Pullman, IL was the model of a company town and started off as a reasonable (if paternalistic) approach to providing good housing and services to your employees.

Unsurprisingly, it did not last.

AI companies/users are filled with liars and grifters, so any numbers/outlook they report should be highly suspect.

Finders fees aren't nefarious

> So in the median case, a state adding an additional 20% in income tax would have a total marginal tax rate of 37% + 4.75% + 20%, or 61.75%

Good! It should still be higher!

There's nothing more tone deaf than an uber wealthy man arguing he shouldn't pay more in taxes to the system that allows him to be uber wealthy and to be deliberately misleading at the same time.

> both of which famously have powerful unions.

It depends. The NFLPA is famously powerless. Domonique Foxworth (former NFLPA President) has long argued it should decertify and reorganize as a trade association because it doesn't work like a traditional labor union.

> the union boogeyman you may have seen on TV

Around me the union boogeymen are the police and teachers unions. Ultimately the issue is a professional political class decoupled from reality that extort local government.

However there are also the unions for artists (think actors, television writers, theater, etc) which do a very good job stabilizing pay and standards for safety without interfering with the flexibility of businesses to hire who they want or labor to work where they want to. Within reason.

That's what I mean, I've seen enough autoconf "checking for <feature that totally works in every compiler you care about>" noise to know it's mostly pointless in this day in age.

podman seems to handle rootless namespaces just fine, minor caveat for some perf overhead but it's not the end of the world.

I think this is true of github as a forge but it faces the threat of unbundling. Off the top of my head

- Code repository

- Project wiki

- Project roadmap/planning

- Static site hosting

- Issue tracking

- Internal and external contributions (PRs)

- Code review

- Cross platform CI pipelines/runners

- Release hosting

Of these key things, what is Github good at and how much can you improve by providing an alternative that's faster/cheaper/more robust?

Of these I think the only thing Github stays competitive at is "code repository." Everything else kinda sucks and/or is expensive and flaky.

Just as an example, there's that hilarious "just give me an EXE" Reddit post from a few years back. It's fun to laugh it given the state/purpose of Github but you can also look at that as a lost market for Github. Why can't you provide a nice landing page with downloads/installers in a very clean landing page for your project on GitHub? It could even be a premium feature if it means paying for storage/bandwidth.

And don't get me started on actions. Absolute trash tier product that they should be ashamed at the state of.

In my opinion Hendrix is to electric guitar what Beethoven was to (Western) harmony. All contemporary lines go through him.

One thing to note though is that Hendrix had a very short career in which he lived/performed in Nashville, the Chitlin' Circuit, Greenwich Village, and London. On top of being an incredibly proficient/creative guitar player he also had an incredible ear and picked up sounds/techniques/songs from everywhere he lived and with everyone he played with.

Part of why you can trace the evolution of guitar playing through Hendrix is that on top of his records being popular and everyone learning those tunes as a first/second year student, his own musicological background was a fusion of the major songwriting movements of the 1960s that spawned modern blues, pop, funk, fusion, rock, and metal. It's easy to see Hendrix as an influence on modern music because he was a magnet for players of all those genres.

What's interesting about Hendrix is that he is "an artist you listen to" instead of "an artist who an artist you listen to, listens to" from the same era like Albert King or Joe Pass.

> People just don't use this because they want to write "portable" "standard" C

Something that bothers me is the Venn diagram of people that think abstraction is slow and error prone and people that only write portable C.

How many C implementations do you actually need to compile against? I don't think I've seen more than 3 outside Unix software from the 90s. Using non portable extensions is in fact totally doable for your application and you should probably do it, and just duplicate/triplicate code where you have to. It's not that hard to write and not hard to read.

I searched the name "fastcode" and the only results were AI

A manual is not a tutorial, and having AI anywhere near this task is actively harmful. Please do not build this.

> it's a PITA to differentiate the utility of hundreds of different vpaddcfoolol instructions

This is one complaint I toss back at Intel and AMD.

If an instruction/intrinsic is universally worse than the P90/P95/P99 use case where it's going to be used to another set of instrinsics, then it shouldn't exist. Stop wasting the die space and instruction decode on it, if not only the developer time wasted finding out that your dot product instruction is useless.

There are a lot of smart people that have worked on compilers, optimized subroutines for LAPACK/BLAS, and designed the decoders and hardware. A lot of that effort is wasted because no one knows how to program these weird little machines. A little manual on "here's how to program SIMD, starting from linear algebra basics" would be worth more to Intel than all the money they've wasted trying to improve autovectorization passes in ICC and now, LLVM.

The definition of a byte today is different than the definition of byte when those machines were manufactured. Just like how 'foot' is now standardized(*)

(* technically, a 'foot' is not a standard unit of measure but that's due to the long history of 'foot' not being standardized until relatively recently)

You could argue the answer to this question depends on if you believe P=NP

> A big ugly warning in the UI?

There's already a warning in the docs. There's no UI to put the warning in that isn't going to be visible until it's too late. And even that warning isn't scary enough - this documentation is buried behind a "warning" in the docs and then two more links to get to the meat.

> Workflows triggered via pull_request_target have write permission to the target repository. They also have access to target repository secrets. The same is true for workflows triggered on pull_request from a branch in the same repository, but not from external forks. The reasoning behind the latter is that it is safe to share the repository secrets if the user creating the PR has write permission to the target repository already.

> pull_request_target runs in the context of the target repository of the PR, rather than in the merge commit. This means the standard checkout action uses the target repository to prevent accidental usage of the user supplied code.

So what this means is if you use `pull_request_target`, the jobs have read and write access to privileged data in the repo (including secrets) and the code the job runs is controlled by the target.

> Or, push back on the architecture?

Personally, I would advocate to remove this feature for public repositories. It has ~zero legitimate use cases. If it needs to come back, it should be an error to run jobs on this trigger if the user that initiated it doesn't have write permissions for the repo.

If this breaks CI pipelines that is a good thing. Those pipelines are just waiting to be pwned.

There's a PR open to mitigate this on actions/cache but I don't believe it's actually solving the root cause, which is in the design of actions itself.

The fundamental problem is that on Github Actions it's possible to give read-only permissions to pipelines that are then violated because runners can be granted read+write permissions to the cache. And they don't consider this a P0 bug.

So you don't even need to see questionable bash scripts to know there's a problem. The script would have already completed and pwned you by the time you see it.

With podman or nix you would have to poison the container registry/nix store which is more difficult, but you're also probably using your own runners.

My point though is that it's not bash or yaml here, but Github's default access controls. If you own your own runners and your own caching layer then you're not going to be nearly as boneheaded as Github here. But Github pushes people towards their integrated solutions, which have horrible defaults.

> What if your CI pipeline was old-school bash script instead?

It doesn't matter if the cache is accessed through `actions/cache` in YAML or `curl -X POST $GITHUB_CACHE_URL < wololo.exe` or whatever. The fundamental problem is that "cache scope is per-repo."

I cannot fathom why they chose to support this at all, let alone make it the default for any action trigger. Any writeable data should be scoped to users/groups and require credentials. It should be impossible to write to a shared cache without explicitly granting permissions to the user triggering the action.

And sure a PAT might leak through an env var not configured through secrets, but that's an understandable issue created by the user. I think most people are surprised their caches are world writeable with an innocuous actions trigger.

Rust's compilation unit is a crate. Counting crates is like counting source files in C++.

> Are benefits in binary size really worth that complexity?

What complexity?

sys crates are also mostly generated and lack a lot of eyeballs. Sneaking something into the build.rs of a sys crate would not be difficult and would land in the builds of everything downstream of it.

Why not? Processes are cheaper than you might think. GCC invokes several as an example.

RIFF = an awesome chunk based binary format

RIF = a really shitty way to run business

> a file that can have any extension

So read the magic number, you shouldn't trust file extensions anyway

> that file can be copied around to other servers

So can spreadsheets

I'm not discounting that having centralized data access is desirable but it doesn't sound like that particular reasoning is well thought out

Ostensibly this is what STIR/SHAKEN was supposed to cover but aiui they basically fucked it up so bad that it will only work for domestic calls in the US.

Which is almost guaranteed if you're launching multiple containers with the same base image or shared layers.

I live in a major metro area, basically every theater has assigned seats now.

Because it adds 4-6x overhead to all integer arithmetic