I wrote a little game like this in the 80s because I wanted a game that used two mice. There were two openings for sand at the top and two exits at the bottom and the goal was to get as much sand in your bin by redirecting everything. You drew little platforms (left button) like in the one you linked to and could erase each other's platforms (right button).
Yeah seems like that's quite explicitly the goal. The question is, what means or method are they trying to hide and is it hyper illegal or just something they don't want to be pubic knowledge?
Thinking on it, I suspect it's a case of a larger number of smaller techniques. Cops aren't very good at keeping secrets so it can't be something that is widely pervasive, but every department has their stupid little trick
It’s all about delivery. Cops don’t deal with it directly. Their department does through a vendor on a branded portal where they upload information and it does its thing.
It’s no different than any investigative portal they use in their eyes.
It turns out it's actually fine if your data is on offer to the government from a third party.
The Constitution was meant to be permanently fixed and extremely literal about only the technology available from centuries ago, it was not meant to describe general concepts nor intended to be updated to ensure those same rights are retained along with changes in society.
>The Constitution was meant to be permanently fixed and extremely literal about only the technology available from centuries ago, it was not meant to describe general concepts nor intended to be updated to ensure those same rights are retained along with changes in society.
/s?
I can't tell because people unironically use the same reasoning to make the "2nd amendment only apply to muskets" argument.
That isn't the muskets version of that argument I have heard.
The version I've heard is that the firearm technology when the second amendment was ratified was very different than today and that makes it worth evaluating if we want to amend it again.
Similarly the military landscape looks very different as well such that there's a very different risk of foreign armies taking ground and citizens everywhere needing to be ready to hold ground until the more official military forces can arrive.
If we want to get really pedantic about 2A where are the well regulated militias?
Even if someone really is saying the thing you're claiming, 2A doesn't mention muskets at all or any other specific technology so that would be a really dumb thing for those people to say.
The founding fathers denied the right to bare arms to Catholics (and I’d wager lots of other religions), Native Americans, slaves (unless their owners explicitly allowed them), and we inherited English Common Law which limited carrying guns in populated areas.
Until Heller in ~2008, the right to bare arms (as a national right) was widely agreed to mean a collective right (eg. The militias), not an individual right.
We are in a weird place at this moment where the tide turned and lots of jurisprudence is being switched. Also, with ICE / DHS acting as unprofessional as they are, I wouldn’t be surprised to see lots of Dems advocate for more individual gun rights.
"Tanks" as a vehicle aren't regulated whatsoever - their main cannon is a destructive device which carries its own set of regulations, but you can absolutely own a tank (sans main gun) with zero paperwork.
Privateers sunk over 600 British vessels during the Revolution - do you think they needed permits for their cannonry? Or that the Founders somehow didn't know this was happening?
> Until Heller in ~2008, the right to bare arms (as a national right) was widely agreed to mean a collective right (eg. The militias), not an individual right.
Tell me what United States v Miller was about then?
Why do the Federalist papers disagree with everything you are saying, repeatedly?
> we inherited English Common Law which limited carrying guns in populated areas.
Federalist #46:
"Besides the advantage of being armed, which the Americans possess over the people of almost every other nation, the existence of subordinate governments, to which the people are attached, and by which the militia officers are appointed, forms a barrier against the enterprises of ambition, more insurmountable than any which a simple government of any form can admit of. Notwithstanding the military establishments in the several kingdoms of Europe, which are carried as far as the public resources will bear, the governments are afraid to trust the people with arms. And it is not certain, that with this aid alone they would not be able to shake off their yokes. But were the people to possess the additional advantages of local governments chosen by themselves, who could collect the national will and direct the national force, and of officers appointed out of the militia, by these governments, and attached both to them and to the militia, it may be affirmed with the greatest assurance, that the throne of every tyranny in Europe would be speedily overturned in spite of the legions which surround it."
This "collective right" idea is completely bogus and flies in the face of countless historical writings, accounts, etc. The jurisprudence on this issue is long-settled, and who are you to disagree with a majority of Justices of the Supreme Court of the United States?
> The jurisprudence on this issue is long-settled, and who are you to disagree with a majority of Justices of the Supreme Court of the United States?
It was settled for the first time with Heller in 2008, which was not long ago. That SCOTUS decision was supposedly the first to affirm that there was an individual right to carry (not as part of a militia).
Your quote from Federalist 46 doesn’t disprove what I said.
And the Heller decision was 5-4 with one of the dissenting justices claiming it was such a terrible ruling that there should be a constitutional amendment to fix it[1].
You might want to spend some more time with an open mind. You seem extremely confident, but your facts don’t back up such confidence.
When the second amendment was passed, a "well-regulated militia" was already a thing people did, required and defined by the Articles of Confederation.
On one hand, it was controlled by the state, which also had to supply materiel, and not just random citizens making a group. Upper ranks could only be appointed by the state legislatures.
On the other hand, the weaponry the militia was expected to use included horse-drawn cannons, much more than just "home defense" handheld stuff.
P.S.: In other words, the second amendment was designed purely to block the new federal government from disarming the states. I assert that any "Originalist" saying otherwise is actually betraying their claimed philosophy.
If it never created a private right before, then it was wrongly "incorporated" by Supreme Court doctrine, and States ought to be free to set their own gun policies.
Meanwhile privateers sunk or captured 2200+ British ships during the Revolution - I'm sure this was all "organized" militia and every one of those cannons had a permit and taxes paid.
LOL, nobody even considered naval ships to overlap with "the militia" in the first place. You're trying to sneak in some bizarre personal redefinition, like trying to claim your shoes are "vehicles" because they help you get places.
The Articles of Confederation ("Constitution 1.0")--the thing I explicitly showcased, the first thing that "united the states" for over a decade before they wrote a sequel--clearly distinguishes between ships and militia as separate categories.
I'd argue the modern equivalent would be anything you can mount/move with a pick up or a trailer. So a machine-gun, but not a howitzer.
Either way, those "field pieces" were the property of the state, that it was expected to supply by the AoC treaty, rather than something individuals were expected to bring along.
Was... was that nonsense supposed to be some kind of "gotcha"?
Giving the federal government the option to deputize individuals as international agents does not even remotely suggest that States were agreeing to completely abolish all their local gun-laws for all time.
That's like claiming the permission to establish a national postal service somehow bars States from having DUI laws, because any drunkard could maybe suddenly be hired as a postman.
The point is that they implicitly expect private entities/individuals to be able to own and deploy "go toe to toe with the the state equivilent" quality units (though I don't think they expected the same quantity at that quality).
Sure, but crucially "expect some" is not "expect all". The presence of some X is not the same as absolutely zero limitations on X.
Suppose the Federal government chooses to award a letter of Marque and Reprisal to... Bob. However, Bob is in State prison for life, because he was convicted of multiple murders, boat-theft, ramming boats into other boats, selling guns for drugs, whatever.
This sets up a State/Federal conflict, with four major types of resolution:
1. [Specific, State] The Federal government chose a useless agent, but that's their problem for making a stupid choice instead of picking someone not in prison who can wave a gun around and do the job they want done.
2. [Specific, Federal] A lawsuit occurs and it is decided the State has to specifically release Bob from prison and wave a gun around as long as he has that special Federal status.
3. [General, State] The Federal government loses all ability to deputize people because that could potentially cause a conflict.
[General, Federal] The State government loses all ability to imprison anyone or control anybody's gun-waving, because that could potentially cause a conflict.
Surely you'd agree that #4 (and #3) would be insane? Nobody drafted or ratified that M&R clause thinking that they agreed to nullify their State's ability to imprison, nor that the M&R clause itself would be dead on arrival. (Aside, #2 is problematic since it would give Congress a secret pardoning power even more-powerful than the President's.)
> though I don't think they expected the same quantity at that quality
Privateers sunk or captured literally thousands of ships during the Revolution, and were documented to be far more effective than the Continental Navy. The Founders knew this: they were there.
I believe the argument is that in order to have the Letters of Marque be useful, it must have been the case that captains had these types of weapons.
So, to fit it into your analogy, I think it is more like the permission to establish a national postal service implies that the government in the past had not outlawed literacy. There is no need for the government to provide services where the only possible users are already breaking the law.
That said I’m not actually sure I believe this because ships have always been a bit weird legally, going about in international waters far away from any law enforcement… it wouldn’t surprise me if there was some specific cut out for weapons that were only to be used at sea or something…
> it must have been the case that captains had these types of weapons.
Some did, but that doesn't mean states couldn't (or didn't) have laws touching on it.
Similarly, I own and use a car today... but that doesn't mean "the state can't have safety requirements for vehicles", nor does it mean "the state can't bar a legally-blind 20-time DUI convict from driving."
> your analogy
I have a much better/closer one to offer. Consider that tomorrow the Federal legislature could grant a letter of Marque and Reprisal to someone who... Is a convicted murderer held on (state) death-row.
Does that possible wrinkle mean the original Constitution actually banned States from running their own prison systems all along? Does it mean only the federal government is allowed to sentence anybody to carceral punishment?
Obviously not, that'd be an insane conclusion... Yet the only difference here which realm of state law was "getting in the way." If a state can't have gun control because of an M&R letter, then it can't have prisons either.
>The version I've heard is that the firearm technology when the second amendment was ratified was very different than today and that makes it worth evaluating if we want to amend it again.
That's an even worse argument because it's seemingly trying to both to do an motte-and-bailey and strawman at the same time. The motte and bailey comes from seemingly trying to present as sympathetic of an argument as possible. I mean, who's against reevaluating old laws? Strawman comes from the fact that from all the 2nd amendment supporters I've heard, nobody thinks it should be kept because we shouldn't be second-guessing the founding fathers or whatever. All their arguments are based on how guns aren't that dangerous, or how it serves some sort of practical purpose, like preventing state oppression or whatever. Whatever these arguments actually hold is another matter, of course, but at least "the 2nd amendment only applies to muskets" argument doesn't rely on a misrepresentation of the 2nd amendment proponents' views.
;) they are NOT the National Guard. They are the militia of Texas. (Texas State Guard aka TXSG). Subordinate to the state gov, only.
However TX considers it more complicated than that:
The Organized Militia: Consisting of the Texas Army National Guard, the Texas Air National Guard, and the Texas State Guard.
The Unorganized Militia: This consists of all "able-bodied" residents of the state who are at least 18 but under 45 years of age and are not members of the organized militia.
They keep getting arrested because some fed informants show up and convince them to kidnap a governor of whatever before they can become "Well regulated".
This is really strong passive voice. I have to wonder if they were actually on track towards the "well regulated" part if some feds were able to convince them to kidnap a governor.
It was mostly a joke, since these sorts of groups have always, like going back 40+yr, been magnets for law enforcement who always seem to push them to do illegal things.
Second, the incident I'm referencing is well documented. You should look it up. It's basically the "feds radicalize then arrest muslim man, pat themselves on back for catching terrorist" playbook but for white people.
Yes, /s, they're advocating for it to be more of a work-in-progress document, and not considered something final in its current state.
The last pull request got accepted into main in 1992 after being stuck in the per review stage for no less than 202 years. The latest one out of 4 that still remain open ("no child labour") celebrated its 100th year anniversary 18 months ago because for some reason 15 states rejected to approve it and 2 of the states haven't even bothered to address it. 12 of the 28 that gave their approval also rejected it initially but then changed their opinion down the line.
There's definitely an argument to be made here, though.
I think everyone can agree that if the founding fathers knew about modern warfare they would probably feel different about a variety of things. Or, at least, consider them more carefully.
1. Don't use bash, use a scripting language that is more CI friendly. I strongly prefer pwsh.
2. Don't have logic in your workflows. Workflows should be dumb and simple (KISS) and they should call your scripts.
3. Having standalone scripts will allow you to develop/modify and test locally without having to get caught in a loop of hell.
4. Design your entire CI pipeline for easier debugging, put that print state in, echo out the version of whatever. You don't need it _now_, but your future self will thank you when you do it need it.
5. Consider using third party runners that have better debugging capabilities
I would disagree with 1. if you need anything more than shell that starts to become a smell to me. The build/testing process etc should be simple enough to not need anything more.
I agree with #2, I meant more if you are calling out to something that is not a task runner(Make, Taskfile, Just etc) or a shell script thats a bit of a smell to me. E.g. I have seen people call out to Python scripts etc and it concerns me.
My software runs on Windows, Linux and MacOS. The same Python testing code runs on all three platforms. I mostly dislike Python but I can't think of anything better for this use case.
You might consider Deno with Typescript... it's a single exe runtime, with a self-update mechanism (deno upgrade) and can run typescript/javascript files that directly reference the repository/http/modules that it needs and doesn't require a separate install step for dependency management.
I've been using it for most of my local and environment scripting since relatively early on.
> The same Python testing code runs on all three platforms.
I have no objections to Python being used for testing, I use it myself for the end to end tests in my projects. I just don't think Python as a build script/task runner is a good idea, see below where I got Claude to convert one of my open source projects for an example.
"pwsh" is often used as the short-hand for modern cross-platform PowerShell to better differentiate it from the old Windows-only PowerShell.
I think pwsh is worth exploring. It is cross-platform. It is post-Python and the Python mantra that "~~code~~ scripts are read more often than they are written". It provides a lot of nice tools out of the box. It's built in an "object-oriented" way, resembling Python and owing much to C#. When done well the "object-oriented" way provides a number of benefits over "dumb text pipes" that shells like bash were built on. It is easy to extend with C# and a few other languages, should you need to extend it.
I would consider not dismissing it off hand without trying it just because Microsoft built it and/or that it was for a while Windows-only.
It's also both a larger download and slower to start than Java, which is not known for being light and nimble. In fact, PowerShell is so slow that you can both compile and run the equivalent C# program before PowerShell finishes launching. Not ideal for a shell or a scripting language.
Also, the newer versions aren't included with Windows, which would have been useful – instead Windows includes an incompatible older version that admonishes you to download the new version. But why would you download several hundred megabytes of pwsh when you can equally well download any other language runtime?
Also, it sends "telemetry" to Microsoft by default.
Also, the error handling is just awful, silencing errors by default, requiring several different incantations to fix.
Also, the documentation is vague and useless. And the syntax is ugly.
It gets faster to boot on subsequent launches and some distros are now packaging pre-baked versions.
The new versions aren't included in Windows and the old versions are still in Windows for the exact same reasons of Windows backwards compatibility requirements. But at this point the bootstrap on Windows is as easy as `winget install --id Microsoft.PowerShell`.
The error handling isn't far from the bash defaults, but the magic incantations actually tell you what they do versus the number of bash scripts littered with `set -euxo pipefail` is the exact same as the number of scripts that need an `$ErrorActionPreference = "Stop"` and/or a `$PSNativeCommandUseErrorActionPreference = true`.
I find the documentation less vague and more useful than the average `man` page and the syntax is fine (and better than bash) to me, but I understand how much of that is personal preference and familiarity.
Huh? Who cares if the script is .sh, .bash, Makefile, Justfile, .py, .js or even .php? If it works it works, as long as you can run it locally, it'll be good enough, and sometimes it's an even better idea to keep it in the same language the rest of the project is. It all depends and what language a script is made in shouldn't be considered a "smell".
Once you get beyond shell, make, docker (and similar), dependencies become relevant. At my current employer, we're mostly in TypeScript, which means you've got NPM dependencies, the NodeJS version, and operating system differences that you're fighting with. Now anyone running your build and tests (including your CI environment) needs to be able to set all those things up and keep them in working shape. For us, that includes different projects requiring different NodeJS versions.
Meanwhile, if you can stick to the very basics, you can do anything more involved inside a container, where you can be confident that you, your CI environment, and even your less tech-savvy coworkers can all be using the exact same dependencies and execution environment. It eliminates entire classes of build and testing errors.
I use to have my Makefile call out and do `docker build ...` and `docker run ...` etc with a volume mount of the source code to manage and maintain tooling versions etc.
It works okay, better than a lot of other workflows I have seen. But it is a bit slow, a bit cumbersome(for langs like Go or Node.js that want to write to HOME) and I had some issues on my ARM Macbook about no ARM images etc.
I would recommend taking a look at Nix, it is what I switched to.
* It is faster.
* Has access to more tools.
* Works on ARM, X86 etc.
I've switched to using Deno for most of my orchestration scripts, especially shell scripts. It's a single portable, self-upgradeable executable and your shell scripts can directly reference the repositories/http(s) modules/versions it needs to run without a separate install step.
I know I've mentioned it a few times in this thread, just a very happy user and have found it a really good option for a lot of usage. I'll mostly just use the Deno.* methods or jsr:std for most things at this point, but there's also npm:zx which can help depending on what you're doing.
It also is a decent option for e2e testing regardless of the project language used.
Shell and bash are easy to write insecurely and open your CI runners or dev machines up for exploitation by shell injection. Non-enthusiasts writing complex CI pipelines pulling and piping remote assets in bash without ShellCheck is a risky business.
You shouldn't be pulling untrusted assets in CI regardless. Hacking your bash runner is the hardest approach anyways, just patch some subroutine in a dependency that you'll call during your build or tests.
> Huh? Who cares if the script is .sh, .bash, Makefile, Justfile, .py, .js or even .php?
Me, typically I have found it to be a sign of over-engineering and found no benefits over just using shell script/task runner, as all it should be is plumbing that should be simple enough that a task runner can handle it.
> If it works it works, as long as you can run it locally, it'll be good enough,
Maybe when it is your own personal project "If it works it works" is fine. But when you come to corporate environment there starts to be issues of readability, maintainability, proprietary tooling, additional dependencies etc I have found when people start to over-engineer and use programming languages(like Python).
E.g.
> never_inline 30 minutes ago | parent | prev | next [–]
> Build a CLI in python or whatever which does the same thing as CI, every CI stage should just call its subcommands.
However,
> and sometimes it's an even better idea to keep it in the same language the rest of the project is
I'll agree. Depending on the project's language etc other options might make sense. But personally so far everytime I have come across something not using a task runner it has just been the wrong decision.
> But personally so far everytime I have come across something not using a task runner it has just been the wrong decision.
Yeah, tends to happen a lot when you hold strong opinions with strong conviction :) Not that it's wrong or anything, but it's highly subjective in the end.
Typically I see larger issues being created from "under-engineering" and just rushing with the first idea people can think of when they implement things, rather than "over-engineering" causing similarly sized future issues. But then I also know everyone's history is vastly different, my views are surely shaped by the specific issues I've witnessed (and sometimes contributed to :| ), than anything else.
> Yeah, tends to happen a lot when you hold strong opinions with strong conviction :) Not that it's wrong or anything, but it's highly subjective in the end.
Strong opinions, loosely held :)
> Typically I see larger issues being created from "under-engineering" and just rushing with the first idea people can think of when they implement things, rather than "over-engineering"
Funnily enough running with the first idea I think is creating a lot of the "over-engineering" I am seeing. Not stopping to consider other simpler solutions or even if the problem needs/is worth solving in the first place.
> Yeah, tends to happen a lot when you hold strong opinions with strong conviction :) Not that it's wrong or anything, but it's highly subjective in the end.
I quickly asked Claude to convert one of my open source repos using Make/Nix/Shell -> Python/Nix to see how it would look. It is actually one of the better Python as a task runners I have seen.
While the Python version is not as bad as I have seen previously, I am still struggling to see why you'd want it over Make/Shell.
It introduces more dependencies(Python which I solved via Nix) but others haven't solved this problem and the Python script has dependencies(such as Click for the CLI).
It is less maintainable as it is more code, roughly x3 the amount of the Makefile.
To me the Python code is more verbose and not as simple compared to the Makefile's target so it is less readable as well.
> It introduces more dependencies(Python which I solved via Nix) but others haven't solved this problem and the Python script has dependencies(such as Click for the CLI).
UV scripts are great for this type of workflow
There are even scripts which will install uv in the same file effectively making it just equivalent to ./run-file.py and it would handle all the dependency management the python version management and everything included and would work everywhere
Personally I end up just downloading uv and so not using the uv download script from this but if I am using something like github action which are more (ephemeral?) I'd just do this.
Something like this can start out simple and can scale much more than the limitations of bash which can be abundant at times
That being said, I still make some shell scripts because executing other applications is first class support in bash but not so much in python but after discovering this I might create some new scripts with python with automated uv because I end up installing uv on many devices anyway (because uv's really good for python)
I am interested in bun-shell as well but that feels way too much bloated and even not used by many so less (AI assistance at times?) and I haven't understood bun shell at the same time too and so bash is superior to it usually
So previously when I have seen Python used as a task runner I think they used UV to call it. Although I don't think they had as a complete solution as your here auto-installing UV etc.
Although the example you've linked is installing UV if missing, the version is not pinned, I also don't think it is handling missing Python which is not pinned even if installed locally. So you could get different versions on CI vs locally.
While yes you are removing some of the dependencies problems created via using Python over Make/Shell I don't think this completely solves it.
> Something like this can start out simple and can scale much more than the limitations of bash which can be abundant at times
I personally haven't witnessed anytime I would consider the scales to have tipped in favour of Python and I would be concerned if they ever do, as really the task runner etc should be plumbing, so it should be simple.
> That being said, I still make some shell scripts because executing other applications is first class support in bash but not so much in python but after discovering this I might create some new scripts with python with automated uv because I end up installing uv on many devices anyway (because uv's really good for python)
Using Python/UV to do anything more complex than my example PR above?
I think UV scripts can/will actually install python and manage it itself as well and you can actually pin a specific version of python itself via Uv scripts
# Use some syntax added in Python 3.12
type Point = tuple[float, float]
print(Point)
> Using Python/UV to do anything more complex than my example PR above?
I can agree that this might be complex but that complexity has a trade off and of course nothing is shoe fits all but there are times when someone has to manage a complex CI environment and I looked at and there are some CI deterministic options too like invoke etc. and when you combine all of these, I feel like the workflow can definitely be interesting to say the least
Once again, I don't know what really ends up in github actions since I have never really used it properly, I am basing its critiques based on what I've read and what solutions (python came quite frequently) and something recently which I discovered (which was the blog)
Does it really matter if its a global install of uv or not especially on Github Actions
Also if this still bothers you, nothing stops you from removing the first x lines of code and having it in another .py file if this feels obnoxious to you
> Oh, and later the author suggests the script modify itself after running. What the fuck. Absolutely unacceptable way to deploy software.
Regarding author suggest its removes itself its because it does still feel clutterish but there is virtually 0 overhead in using/having it still be if you are already using uv or want to use uv
Oh also, (I am not the Author) but I have played extensively with UV and I feel like the script can definitely be changed to install it locally rather than globally.
They themselves mention it as #overkill on their website but even then it is better than whatever github action is
Yes I believe the same too and I think we are on the same goal. I think that I can probably patch this code to install uv, let's say locally instead of globally if that's a major concern. I feel like its not that hard.
It's easy enough to patch. It's the philosophy that bugs me. We already have a huge problem with routine workflows pulling things from the network (often, without even a semblance of hash-locking) and foregoing the traditional separation between environment setup and business logic. There's a lot of value into having discrete steps for downloading/installing stuff and doing development, because then you can pay special attention to the former, look for anything odd, read release notes, and so on. Between explicit, human-solicited upgrades, dev workflows should be using, ideally, vendored dependencies, or, if not that, then at least stuff that's hash-verified end-to-end.
Someday, someone is going to have a really big disaster that comes out of casual getting unauthenticated stuff from somebody else's computer.
I think your reason of worrying is either that A) packages can update and contain malware or B) Uv's installation itself. might have malware if any of A) or B) get hacked
Regarding B) I feel like they provide attestations via GitHub Artifact Attestations and the script could once again be modified to actually verify it via github attestations and they also provide ghcr artifacts (as such immutability) atleast of docker images and I looked further into it and it seems that you can use github artifacts to upload normal binary files as well so I will probably take a look into seeing if I can do something like this for uv's ghcr
Effectively after A) and B) the trust just ends up being reliant on Github's Microsoft infrastructure (usually) and perhaps python infrastructure which is on fastly
But I feel like this is for cases of extremely sensitive workflows But I feel like I might still take a look at it because security still feels very interesting to me and just because of this discussion, I can see at some pointers of following up on curiosity lol
Anyways would love to continue our discussion and probably update you on trying to make a script which could actually be completely pinned (atleast uv binary instead of just running a shell script from the astral servers in such case)
I find that shell scripting has a sharp cliff. I agree with the sentiment that most things are over engineered. However it’s really easy to go from a simple shell script running a few commands to something significantly more complex just to do something seemingly simple, like parse a semantic version, make an api call and check the status code etc, etc.
The other problem with shell scripting on things like GHA is that it’s really easy to introduce security vulnerabilities by e.g forgetting to quote your variables and letting an uncontrolled input through.
There’s no middle ground between bash and python and a lot of functionality lives in that space.
> However it’s really easy to go from a simple shell script running a few commands to something significantly more complex just to do something seemingly simple, like parse a semantic version, make an api call and check the status code etc, etc.
Maybe I keep making the wrong assumption that everyone is using the same tools the same way and thats why my opinions seem very strong. But I wouldn't even think of trying to "parse a semantic version" in shell, I am treating the shell scripts and task runners as plumbing, I would be handing that of a dedicated tool to action.
Let’s say have a folder of tarballs and need to install the latest version. I could reach for an additional “dedicated” tool, get it installed into the CI environment and then incorporate it into the build process, or I could just make a slight modification to my existing shell script and do something like “ls mypkg-*.tar.gz | xargs -n1 | sort -Vr | head -n1” and then move on. But then we start publishing multiple release candidates and now I need to add to that logic to further distinguish between earlier and later rc versions. And so on and so forth…
Now I’m in agreement with you that this is a bad fit for shell scripting, but it is often pragmatic and expedient. And bc there is a cliff between bash and (say) python, some of the time, you’re going to choose the path of least resistance.
Now scale this out to a small team of engineers all facing the same dumb decision of needing to make some tradeoff when they would much rather be writing application logic. The lack of a ubiquitous and robust intermediate language leads to brittle CI fraught with security vulnerabilities.
While the example I provided is a bit contrived, this behavior isn’t hypothetical. I see it everywhere I’ve worked.
Yes I am seeing what your saying, it can start of simple and people will choose the path of least resistance and you'll end up with a ball of mud eventually. Fortunately I have not come across anything that bad yet.
I know it is a made up example, but I am not sure Python would improve the situation. I would be looking at either Docker or SBOMs to try and improve the situation and then hopefully the release process would become a lot simpler.
yea imagine having to maintain a python dependency (which undergoes security constraints) all because some junior cant read/write bash... and then that junior telling you you're the problem lmao
> If your CI can do things that you can't do locally: that is a problem.
IME this is where all the issues lie. Our CI pipeline can push to a remote container registry, but we can't do this locally. CI uses wildly different caching strategies to local builds, which diverges. Breaking up builds into different steps means that you need to "stash" the output of stages somewhere. If all your CI does is `make test && make deploy` then sure, but when you grow beyond that (my current project takes 45 minutes with a _warm_ cache) you need to diverge, and that's where the problems start.
Ironically, at least for a couple recent projects... just installing dependencies fresh is as fast on GH Actions as the GH caching methods, so I removed the caching and simplified the workflows.
> With uv, it turns out that it's often faster to omit pre-built wheels from the cache (and instead re-download them from the registry on each run). On the other hand, caching wheels that are built from source tends to be worthwhile, since the wheel building process can be expensive, especially for extension modules.
> If your CI can do things that you can't do locally: that is a problem.
Probably most of the times when this is an actual problem, is building across many platforms. I'm running Linux x86_64 locally, but some of my deliverables are for macOS and Windows and ARM, and while I could cross-compile for all of them on Linux (macOS was a bitch to get working though), it always felt better to compile on the hardware I'm targeting.
Sometimes there are Windows/macOS-specific failures, and if I couldn't just ssh in and correct/investigate, and instead had to "change > commit > push" in an endless loop, it's possible I'd quite literally would lose my mind.
I literally had to do this push > commit > test loop yesterday because apparently building universal Python wheels on MacOS is a pain in the ass. And I don't have a mac, so if I want to somewhat reliably reproduce how the runner might behave, I have to either test it on GH actions or rent one from something like Scaleway. Mainly because I don't currently knwo how else to do it. It's so, so frustrating and if anyone has ideas on making my life a bit better that would be nice lol.
there is quickemu which can install mac vm on linux (or any other host) rather quickly, what are your thoughts on it (I am an absolute quickemu shill because I love that software)
That's what I intend to use it for, Mac and Windows... I'm starting on an app that I want to work cross platform (tauri/rust w/ react+mui) and want to be able to do manual testing or troubleshooting as needed on mac and windows without needing a separate machine.
My laptop is an M1 MacBook Air, and I do have an N100 I could use for Windows... I'd just assume use my fast desktop which even emulated is likely faster and not have to move seats.
yes, I think just the amount of friction it can reduce might be worth it in the first place.
Oh btw although there are many primitives which help transferring files between VM's and others by having sshfs etc., one of the things which I enjoyed doing in quickemu is using the beloved piping-server
The speeds might be slow but I was using it to build simple shell scripts and you can self host it or deploy on cf workers too most likely which is really simple but I haven't done it
But for quick deployments/transfers of binaries/simple files, its great as well. Tauri is meant to be lightweight/produce small binaries so I suppose one can try it but there are other options as well
Piping Serrvers + quickemu felt like a cheatcode to me atleast for more ephemeral vm's based workflow but of course YMMV
Good luck with your project! I tried building a tauri app once for android just out of mere curiosity on linux and it was hell. I didn't know anything about android development but setting up the developer environment was really hard and I think I forgot everything I learnt from that but wish I had made notes or even video documenting the process
Fortunately/Unfortunately it wouldn't be a good experience for Phone use, maybe table as part of it will be displaying BBS-ANSI art and messages which lends itself to a larger display.
> If your CI can do things that you can't do locally: that is a problem.
Completely agree.
> I'm a huge fan of "train as you fight", whatever build tools you have locally should be what's used in CI.
That is what I am doing, having my GitHub Actions just call the Make targets I am using locally.
> I mean, at some point you are bash calling some other language anyway.
Yes, shell scripts and or task runners(Make, Just, Task etc) are really just plumbing around calling other tools. Which is why it feels like a smell to me when you need something more.
I don't agree with (1), but agree with (2). I recommend just putting a Makefile in the repo and have that have CI targets, which you can then easily call from CI via a simple `make ci-test` or similar. And don't make the Makefiles overcomplicated.
Of course, if you use something else as a task runner, that works as well.
For certain things, makefiles are great options. For others though they are a nightmare. From a security perspective, especially if you are trying to reach SLSA level 2+, you want all the build execution to be isolated and executed in a trusted, attestable and disposable environment, following predefined steps. Having makefiles (or scripts) with logical steps within them, makes it much, much harder to have properly attested outputs.
Using makefiles mixes execution contexts between the CI pipeline and the code within the repository (that ends up containing the logic for the build), instead of using - centrally stored - external workflows that contains all the business logic for the build steps (e.g., compiler options, docker build steps etc.).
For example, how can you attest in the CI that your code is tested if the workflow only contains "make test"? You need to double check at runtime what the makefile did, but the makefile might have been modified by that time, so you need to build a chain of trust etc.
Instead, in a standardized workflow, you just need to establish the ground truth (e.g., tools are installed and are at this path), and the execution cannot be modified by in-repo resources.
That doesn't make any sense. Nothing about SLSA precludes using make instead of some other build tool. Either inputs to a process are hermetic and attested or they're not. Makefiles are all about executing "predefined steps".
It doesn't matter whether you run "make test" or "npm test whatever": you're trusting the code you've checked out to verify its own correctness. It can lie to you either way. You're either verifying changes or you're not.
You haven't engaged with what I wrote, of course it doesn't make sense.
The easiest and most accessible way to attest what has been done is to have all the logic of what needs to be done in a single context, a single place. A reusable workflow that is executed by hash in a trusted environment and will execute exactly those steps, for example.
In this case, step A does x, and step B attests that x has been done, because the logic is immutably in a place that cannot be tampered with by whoever invokes that workflow.
In the case of the makefile, in most cases, the makefile (and therefore the steps to execute) will be in a file in the repository, I.e., under partial control of anybody who can commit and under full control of those who can merge.
If I execute a CI and step A now says "make x", the semantic actually depends on what the makefile in the repo includes, so the contexts are mixed between the GHA workflow and the repository content.
Any step of the workflow now can't attest directly that x happened, because the logic of x is not in its context.
Of course, you can do everything in the makefile, including the attestation steps, bringing them again in the same context, but that makes it so that once again the security relevant steps are in a potentially untrusted environment. My thinking specifically hints at the case of an organization with hundreds of repositories that need to be brought under control.
Even more, what I am saying make sense if you want to use the objectively convenient GH attestation service (probably one of the only good feature they pushed in the last 5 years).
Usually, the people writing the Makefile are the same that could also be writing this stuff out in a YAML (lol) file as the CI instructions, often located in the same repository anyway. The irony in that is striking. And then we have people who can change environment variables for the CI workflows. Usually, also developers, often the same people that can commit changes to the Makefile.
I don't think it changes much, aside from security theater. If changes are not properly reviewed, then all fancy titles will not help. If anything, using Make will allow for a less flaky CI experience, that doesn't break the next time the git hoster changes something about their CI language and doesn't suffer from YAMLitis.
You're correct. It's absolutely security theater. Either you trust the repository contents or you don't. There's no, none, zilch trust improvement arising from the outer orchestration being done in a YAML file checked into the repo and executed by CI instead of a Makefile also executed by CI.
What's the threat model Wilder is using exactly? Look, I'm ordinarily all for nuance and saying reasonable people can disagree when it comes to technical opinions, but here I can't see any merit whatsoever to the claim that orchestrating CI actions with Make is somehow a security risk when the implementations of these actions at some level live in the repo anyway.
> when the implementation of these actions at some level live in the repo anyway
This is the false assumption. You can standardize that not to happen, and you can verify at runtime that's not the case.
You can control admission of container images for example, restricting those that were built by your workflow X (the approved, central, controlled, standard one) and reject anything else. You do this via build provenance attestation.
With makefile I don't know how you can achieve standard and centrally manageable (and verifiable) instructions (which are part of SLSA).
> With makefile I don't know how you can achieve standard and centrally manageable (and verifiable) instructions (which are part of SLSA).
The way I'm thinking about it, we distinguish instructions from policy. Policy, of course, has to be imposed from outside a package somehow, but the instructions taken within policy seem like things that should evolve with it. For example, "no network access" might be an externally enforced policy. Another might be limitations of dependencies, enforced by making exceptions to the previous policy.
But in the end, you have to do something. Are you suggesting a model in which a project's entire test suite lives in a separate repository with an access control policy that differs from that project's so that the project's authors can't cheat on test coverage or pass rate?
Sure, you can do that, but the instructions for running those tests still have to live somewhere, and a makefile in that test repository seems like as good a place as any.
A classic example would be build (container build) images instructions.
Of course, other examples are running a security static analysis, running tests, or whatever other standard practice is desidered for security.
Say that you build 100 images, each with its own repository where there is the code, there is the Dockerfile etc.
Now, if you build images with "make build", it means that ultimately the actual command line flags for the build command are going to be in the Makefile, inside each repository. These flags could include flags like --cache-from, build arguments, --add-host, or many other flags that may not be desirable in an organization.
Imagine what the workflow file would like for such a case: you have your in-repo CI file that clones the repo, and then executes make test, make build, make push, etc.
Do you know if make push sent the PCI registry secret somewhere else on the internet? Do you know what exactly flags were used to build? Not really, you need to trust the code inside the repo to at most collect this information, and how do you know it was not tampered or spoofed?
Compare it with the following scenario:
All 100 repos at some point in that CI invoke an external workflow, which contains instructions to build images, push them to the registry (and run tests before, whatever). This can obviously also be a combination or workflows, I am saying one for simplicity.
This workflow (or workflows) at the end produces an attestation, including provenance data and about what is run.
It can do so reliably, because the instructions of what had to be done are within its own context. There is no input that comes from outside (e.g., the repository) that determined build flags or instructions, outside of what the workflow exposed (e.g., few variables).
In the second case, I can then use a policy that restrict images that have attestation and that were built by my workflow(s) that contain standard and deterministic instructions. This way I know that no image was built using weird build flags, including strange dependencies, maybe tampering with network and DNS (in makefile I can write whatever) or local docker cache, etc.
I know this because a standard workflow was executed in a fresh, "sterile" environment with a standard set of instructions, that can't be changed or tampered by those controlling the repository content.
Note that all of the above is solely concerned with being able to make security statements on the build artifact produced, not on the context of the build (e.g., no network access).
That's a great point. If we keep following the requirement for attestation to its logical conclusion we would end up replicating the entire server running the repository at the source, then the cycle repeats
Not really, that's the point. Reusable workflow, in a tightly controlled repos avoid exactly what you are saying and they are a fairly standard practice (if anything, also to avoid having 200 versions of CI instructions).
You can also verify attestations provenance by enforcing attestation performed via that particular, approved workflow, which is not security theater, it's actual real controls.
Makefile or scripts/do_thing either way this is correct. CI workflows should only do 1 thing each step. That one thing should be a command. What that command does is up to you in the Makefile or scripts. This keeps workflows/actions readable and mostly reusable.
Neither do most people, probably but it's kinda neat how they suggested fix for github actions' ploy to maintain vendor lock-in is to swap it with a language invented by that very same vendor.
I was once hired to manage a build farm. All of the build jobs were huge pipelines of Jenkins plugins that did various things in various orders. It was a freaking nightmare. Never again. Since then, every CI setup I’ve touched is a wrapper around “make build” or similar, with all the smarts living in Git next to the code it was building. I’ll die on this hill.
They could noop on local runs but be reflected in the github/gitlab as separate steps/stages and allow resumes and retries and such. As it stands there's no way to really have CI/CD run the exact same scripts locally and get all the insights and functionality.
I haven't seen anything like that but it would be nice to know.
I typically use make for this and feel like I’m constantly clawing back scripts written in workflows that are hard to debug if they’re even runnable locally.
This isn’t only a problem with GitHub Actions though. I’ve run into it with every CI runner I’ve come across.
How do you handle persistent state in your actions?
For my actions, the part that takes the longest to run is installing all the dependencies from scratch. I'd like to speed that up but I could never figure it out. All the options I could find for caching deps sounded so complicated.
> How do you handle persistent state in your actions?
You shouldn't. Besides caching that is.
> All the options I could find for caching deps sounded so complicated.
In reality, it's fairly simple, as long as you leverage content-hashing. First, take your lock file, compute the sha256sum. Then check if the cache has an artifact with that hash as the ID. If it's found, download and extract, those are your dependencies. If not, you run the installation of the dependencies, then archive the results, with the ID set to the hash.
It really isn't more to it. I'm sure there are helpers/sub-actions/whatever Microsoft calls it, for doing all of this with 1-3 lines or something.
The tricky bit for me was figuring out which cache to use, and how to use and test it locally. Do you use the proprietary github actions stuff? If the installation process inside the actions runner is different from what we use in the developer machines, now we have two sets of scripts and it's harder to test and debug...
> Do you use the proprietary github actions stuff?
If I can avoid it, no. Almost everything I can control is outside of the Microsoft ecosystem. But as a freelancer, I have to deal a bunch with GitHub and Microsoft anyways, so in many of those cases, yes.
Many times, I end up using https://github.com/actions/cache for the clients who already use Actions, and none of that runs in the local machines at all.
Typically I use a single Makefile/Justfile, that sometimes have most of the logic inside of it for running tests and what not, sometimes shell out to "proper" scripts.
But that's disconnected from the required "setup", so Make/Just doesn't actually download dependencies, that's outside of the responsibilities of whatever runs the test.
And also, with a lot of languages, it doesn't matter if you run an extra "npm install" over already existing node_modules/, it'll figure out what's missing/there already, so you could in theory still have "make test" do absolute everything locally, including installing dependencies (if you now wish this), and still do the whole "hash > find cache > extract > continue" thing before running "make test", and it'll skip the dependencies part if it's there already.
Depends on the build toolchain but usually you'd hash the dependency file and that hash is your cache key for a folder in which you keep your dependencies. You can also make a Docker image containing all your dependencies but usually downloading and spinning that up will take as long as installing the dependencies.
For things like installing deps, you can use GitHub Actions or several third party runners have their own caching capabilities that are more mature than what GHA offers.
We use Nuke for this purpose and I really like it. We're a .NET shop, and Nuke is C#, so works pretty well. Almost all our Nuke targets are shared between local and CI except some docker stuff that needs caching in CI.
Minor variance on #1, I've come to use Deno typescripts for anything more complex than what can be easily done in bash or powershell. While I recognize that pwsh can do a LOT in the box, I absolutely hate the ergonomics and a lot of the interactions are awkward for people not used to it, while IMO more developers will be more closely aligned to TypeScript/JavaScript.
Not to mention, Deno can run TS directly and can reference repository/http modules directly without a separate install step, which is useful for shell scripting beyond what pwsh can do. ex: pulling a dbms client and interacting directly for testing, setup or configuration.
For the above reasons, I'll also use Deno for e2e testing over other languages that may be used for the actual project/library/app.
Step 0. Stop using CI services that purposefully waste your time, and use CI services that have "Rebuild with SSH" or similar. From previous discussions (https://news.ycombinator.com/item?id=46592643), seems like Semaphore CI still offers that.
A year ago I would have agreed wholeheartedly and I was a self confessed skeptic.
Then Gemini got good (around 2.5?), like I-turned-my-head good. I started to use it every week-ish, not to write code. But more like a tool (as you would a calculator).
More recently Opus 4.5 was released and now I'm using it every day to assist in code. It is regularly helping me take tasks that would have taken 6-12 hours down to 15-30 minutes with some minor prompting and hand holding.
I've not yet reached the point where I feel letting is loose and do the entire PR for me. But it's getting there.
I think that's the key. Healthy skepticism is always appropriate. It's the outright cynicism that gets me. "AI will never be able to [...]", when I've been sitting here at work doing 2/3rds of those supposedly impossible things. Flawlessly? No, of course not! But I don't do those things flawlessly on the first pass, either.
Skepticism is good. I have no time or patience for cynics who dismiss the whole technology as impossible.
I think the concern expressed as "impossible" is whether it can ever do those things "flawlessly" because that's what we actually need from its output. Otherwise a more experienced human is forced to do double work figuring out where it's wrong and then fixing it.
This is not a lofty goal. It's what we always expect from a competent human regardless of the number of passes it takes them. This is not what we get from LLMs in the same amount time it takes a human to do the work unassisted. If it's impossible then there is no amount of time that would ever get this result from this type of AI. This matters because it means the human is forced to still be in the loop, not saving time, and forced to work harder than just not using it.
I don't mean "flawless" in the sense that there cannot be improvements. I mean that the result should be what was expected for all possible inputs, and when inspected for bugs there are reasonable and subtle technical misunderstandings at the root of them (true bugs that are possibly undocumented or undefined behavior) and not a mess of additional linguistic ones or misuse. This is the stronger definition of what people mean by "hallucination", and it is absolutely not fixed and there has been no progress made on it either. No amount of prompting or prayer can work around it.
This game of AI whack-a-mole really is a waste of time in so many cases. I would not bet on statistical models being anything more than what they are.
I would strongly recommend this podcast episode with Andrej Karpathy. I will poorly summarize it by saying his main point is that AI will spread like any other technology. It’s not going to be a sudden flash and everything is done by AI. It will be a slow rollout where each year it automates more and more manual work, until one day we realize it’s everywhere and has become indispensable.
It sounds like what you are seeing lines up with his predictions. Each model generation is able to take on a little more of the responsibilities of a software engineer, but it’s not as if we suddenly don’t need the engineer anymore.
Though I think it's a very steep sigmoid that we're still far on the bottom half of.
For math it just did its first "almost independent" Erdos problem. In a couple months it'll probably do another, then maybe one each month for a while, then one morning we'll wake up and find whoom it solved 20 overnight and is spitting them out by the hour.
For software it's been "curiosity ... curiosity ... curiosity ... occasionally useful assistant ... slightly more capable assistant" up to now, and it'll probably continue like that for a while. The inflection point will be when OpenAI/Anthropic/Google releases an e2e platform meant to be driven primarily by the product team, with engineering just being co-drivers. It probably starts out buggy and needing a lot of hand-holding (and grumbling) from engineering, but slowly but surely becomes more independently capable. Then at some point, product will become more confident in that platform than their own engineering team, and begin pushing out features based on that alone. Once that process starts (probably first at OpenAI/Anthropic/Google themselves, but spreading like wildfire across the industry), then it's just a matter of time until leadership declares that all feature development goes through that platform, and retains only as many engineers as is required to support the platform itself.
Hard to say. In business we'll still have to make hard decisions about unique situations, coordinate and align across teams and customers, deal with real world constraints and complex problems that aren't suitable to feed to an LLM and let it decide. In particular, deciding whether or not to trust an LLM with a task will itself always be a human decision. I think there will always be a place for analytical thinking in business even if LLMs do most of the actual engineering. If nothing else, the speed at which they work will require an increase in human analytical effort, to maximize their efficacy while maintaining safety and control.
In the academic world, and math in particular, I'm not sure. In a way, you could say it doesn't change anything because proofs already "exist" long before we discover them, so AI just streamlines that discovery. Many mathematicians say that asking the right questions is more important than finding the answers. In which case, maybe math turns into something more akin to philosophy or even creative writing, and equivalently follows the direction that we set for AI in those fields. Which is, perhaps less than one would think: while AI can write a novel and it could even be pretty good, part of the value of a novel is the implicit bond between the author and the audience. "Meaning" has less value coming from a machine. And so maybe math continues that way, computers solving the problems but humans determining the meaning.
Or maybe it all turns to shit and the sheer ubiquity of "masterpieces" of STEM/art everything renders all human endeavor pointless. Then the only thing that's left worth doing is for the greedy, the narcissists, and the power hungry to take the world back to the middle ages where knowledge and search for meaning take a back seat to tribalism and war mongering until the datacenters power needs destroy the planet.
I'm hoping for something more like the former, but, it's anybody's guess.
Does it? How exactly is the common Joe going to benefit from this world where the robots are doing the job he was doing before, as well as everyone else's job (aka, no more jobs for anyone)? Where exactly is the money going to come from to make sure Joe can still buy food? Why on earth would the people in power (aka the psychotic CxOs) care to expend any resources for Joe, once they control the robots that can do everything Joe could? What mechanisms exist for everyone here to prosper, rather than a select few who already own more wealth and power than the majority of the planet combined?
I think believing in this post-scarcity utopian fairy tale is a lot less imaginative and grounded than the opposite scenario, one where the common man gets crushed ruthlessly.
We don't even have to step into any kind of fantasy world to see this is the path we're heading down, in our current timeline as we speak, CEOs are foaming at the mouth to replace as many people as they can with AI. This entire massive AI/LLM bubble we find ourselves in is predicated on the idea that companies can finally get rid of their biggest cost centers, their human workers and their pesky desires like breaks and vacations and worker's rights. And yet, there's still somehow people out there that will readily lap up the bullshit notion that this tech is going to somehow be used as a force of good? That I find completely baffling.
Many people seem to have this ideal that UBI is inevitable and will solve a bunch of these sort of problems.
But I don't see how UBI can avoid the same complexities as our tax systems, where it will be used to try to influence behaviors, growing cruft along the way just like taxes.
To me it's completely baffling how people imagine that with human labor largely going obsolete, we will just stick with capitalism and all workers go hungry in some dystopian fantasy.
Many cynics seem to believe rich people are demons with zero consideration for their fellow humans.
Rich and powerful persons are still people just like you, and they have an interest in keeping the general population happy. Not to mention that we have democratic mechanisms that give power to the masses.
We will obviously transition to a system where most of us can live a comfortable life without working a full time job, and it's going to be great.
> Many cynics seem to believe rich people are demons with zero consideration for their fellow humans.
Do they have considerations for their fellow humans? I certainly haven't observed that they give a shit about anyone or anything that isn't their bottom line. What exactly has Zuckerberg contributed to this world and to his fellow man, other than a mass data harvesting operation that has enabled real life genocides?
What has Bezos done for the average Amazon warehouse worker, other than stick them in grueling conditions where they even have their toilet breaks timed, just to squeeze out every single inch of life out of his workers he can? What have the people working for Big Oil done that is beneficial to humanity, other than suppressing climate change research and funding lobbying groups to hide the fact that they knew about climate change since the 70s? What have the tobacco execs done for humanity, other than bribing doctors to falsify medical research indicating that tobacco isn't harmful? I could go on and on about all the evils brought on to the world by psychotic executives and their sycophantic legions sucking the teet hoping for a handout, but we'd be here all day.
Sure, there's a few philanthropists out there bobbing around in the ocean of soulless psychopaths that are doing some good things, but they're very much the exception.
> Not to mention that we have democratic mechanisms that give power to the masses.
Even (especially?) just looking solely from a US POV, these democratic mechanisms are quickly and actively being eroded by these "considerate" billionaires like Thiel (who is quite openly & proudly naming his companies using literally evil things from Tolkien's works). They're talking about taking over Greenland to distract from them all being ousted as pedophiles for fuck's sake, what "democractic mechanisms"?
> We will obviously transition to a system where most of us can live a comfortable life without working a full time job, and it's going to be great.
I again don't see how this is "obvious", and you haven't outlined anything about how this utopia is supposed to work other than extremely vague statements. How is this utopian state more obvious than the one we are currently freefalling into, a dystopian police state where your every breath is being tracked in some database that is then shared with anyone with 3 pennies to pay to access the data?
Even in the utopia scenario, that experiment has been taken to its natural conclusion on rats back in the 70s and the results were...interesting, to say the least. (google "Universe 25"). I feel like in many ways, a devolution to feudalism and tribal warfare would be preferable.
I'm now putting more queries into LLMs than I am into Google Search.
I'm not sure how much of that is because Google Search has worsened versus LLMs having improved, but it's still a substantial shift in my day-to-day life.
Something like finding the most appropriate sensor ICs to use for a particular use case requires so much less effort than it used to. I might have spent an entire day digging through data sheets before, and now I'll find what I need in a few minutes. It feels at least as revolutionary as when search replaced manually paging through web directories.
I feel like I'm living in a totally different world or I'm being gaslit by LLMs when I read stuff like this and other similar comments in this thread. Do you mind mentioning _what_ language / tech stack you're in? At my current job, we have a large Ruby on Rails codebase and just this week Gemini 2.5 and 3 struggled to even identify what classes inherited from another class.
If you are selling a house you have to list on rightmove. You're not going to choose to list on fewer sites. The question then comes if you're selling, why list anywhere else.
As a buyer it's terrible - I want to be able to see size of property (from the EPC, as I trust that more than the estate agent), the sale history, the EPC data, the council tax band, the map of the plot.
I can find that all out manually by hunting for the real address and going from there, but it should be there directly (and filterable)
As a seller you're forced to use rightmove as that's where all the buyers are
As a buyer you're forced to use rightmove as that's where all the sellers are
As a competitor how can you argue to an estate agent they should spend money with you as well as rightmove
> I think the recent rise in popularity of Claude Code in particular was bringing this to the surface more often, but never to the point it rose to a massively reported issue.
I'm not sure you can make that argument in good faith; especially as everything is forced to be a discussion and dupes are aggressively closed - so how do you quantify "massively reported issue"?
Discussion upvotes, discussion activity, and Discord reorts. I read every discussion and have been doing this project specifically for a few years now. There is a stark difference between a widespread and common bug and something like this.
Like I said, this bug has existed for 3 years at this point and Ghostty is likely used by hundreds of thousands if not a million+ people daily (we don't have any analytics at all but have some side signals based on terminal reports from 3rd party CLIs). Trust me when I say that when there is a widespread issue, we hear it MUCH more loudly. :)
Dupes are not deleted, you can just search for them and see that there are not that many of those, and that's with this not being the only unsolved memory leak (https://github.com/ghostty-org/ghostty/discussions/9314 is a different one).
reply