Why I develop on Windows
blog.shortround.dev> I know a lot of developers who will opt to do all of their scripting in python these days, even putting #!/bin/python3 at the head of a script so that it runs through the shell.
...which is exactly what you're meant to do.
This is not an example of how bad Bash it, it shows that you didn't understand what Bash is. It's expected to use various languages to write code on Linux, nobody wants you to do things in a language that wasn't made for the task.
Imagine you had to use Python on the shell and, any time you open a terminal, needed to import os and do something like print(os.path.glob("*")) instead of just opening a terminal and typing "ls" to get your directory listing. Different tools for different jobs.
Also the point they try to make about bash looking like a foreign language and having weird syntax. Yes, that's the thing: it's a very specific thing called a shell, not just any old programming language that you're meant to use for things that are not shell scripts. If Python feels more natural to you, that's probably what you should be using. Don't feel like you need to use Bash for bigger tasks than a few lines of code for no reason other than because you're on a system that has it.
To be fair to OP, I would then go on to label these people as equally ignorant:
> A lot of people coming from the Unix-like world of macOS and Linux don't tend to know [PS]. Many people don't know it even exists at all. When I mention the Windows Terminal to people, they think I'm talking about the Windows Command Prompt, a crappy little program
I know that PS and the new terminal is not the same as cmd.exe, and that it has advantages like passing objects through pipes instead of stringly typing everything the way that sh-like shells work. But that's about the extent of it. (The powershell command names though, oh boy, even Java method names are better than that.)
> PowerShell also runs on Unix-like systems through PowerShell Core
I forgot about that. If anyone's interested in this, you may also enjoy learning that you can now run Windows Defender on Linux! And Internet Edgesplorer! The software we've all been waiting for, according to the Microsoft press release :D. These things amuse me to no end, but more seriously, getting to know PS better and trying out this object passing system does sound interesting.
Similar to how C# is secretly my favorite language, but it's just not well supported on Linux (mono and .netcore with monodevelop or the electron app called "VS Code" are just not the same as the Windows experience, e.g. Windows Forms and the real Visual Studio being huge omissions for me).
> Similar to how C# is secretly my favorite language, but it's just not well supported on Linux
C# is not-so-secretly my favorite language (though Clojure is a close second) and I use it pretty often on macos/linux.
IDE wise have you given Rider a try? Imo it's a totally viable Visual Studio replacement for most C# dev, though not as nice for all workflows or related tech.
Worth looking at if you haven't. It's not free, though, so that can blow depending on your tolerance for licensing. I've personally had an all-products pass with jetbrains for awhile now, so doesn't bug me, but ymmv
I also get a lot of mileage out of C# notebooks in VSCode. Honestly, I use C# for a ton of my daily scripting because I built up so many utility scripts over the years in LINQPad on windows, and they were pretty trivial to port
Dude, your comments are way too good to have an empty profile. No, I did not know of Rider, but next time that I get the C# itch again, I'll definitely be looking at what I've been missing out on!
Checking it out quickly, it's from JetBrains (a good sign for software quality) and has a 30-day trial so I'd know what I'm paying for. On the downside, ~175€ is quite steep given that it's not for a commercial purpose and I am currently fine getting my programming done in pluginless Vim. And that's not a one-time payment: that's for the first year. I can't just move on for a while and come back to expect to open up a project file and it to just work :/. I think this is not going to be for me at this price point, though the 30 days trial might be a challenge mode to start and finish a project that I might otherwise never finish at all!
Edit: And I wasn't even yet talking about your comment history. Spotted two insightful comments while skimming the top level of the first page of comments (I stopped there), and that already takes me all the way back to 2015. Not saying you must post more if you don't want to but e.g. the timer tip seems to have helped a lot of people :)
Just to clarify: when you buy you get a license for the current version that is yours to keep and then you get updates through the year, so you can drop back and use an older version if you don't want to keep paying.
Mind you I had the all products pack for a while now, so YMMV.
JetBrains makes damn good stuff. I do C# professionally and even though I use Visual Studio for the bulk of my work, it’s built in refactoring pales in comparison to what JB’s ReSharper provides. (Yes, VS has been catching up but it still has a long way to go.)
Anyway, yeah, Rider by itself isn’t cheap but for not a lot more you can just get the entire JB suite. It includes a whole ton of useful stuff that’s multi-platform and multi-language. When I’m doing Mac dev work, I find Rider to be much better for a lot of things than VS Mac is. (As long as I don’t need Azure integration.)
I could get my employer to reimburse it, but I find it all so useful both for work and for personal projects that I decided it was worth just paying out of pocket and not having to worry about it.
> Dude, your comments are way too good to have an empty profile
Thanks! I really appreciate that. Been kind of a bummer year so it's nice to hear (#layoff problems, so I'm definitely not the only one, and I think that's looking up recently)
I don't think I'd get Rider by itself, either. I was doing consulting for awhile and ended up getting the jetbrains all product thing personally because was jumping between Goland, Rider, Webstorm, and Rubymine, and Datagrip a lot (I honestly don't remember which are paid now). I got it personally because I ended up using it so much. I ended up using CLion (which is paid) for learning Rust, too, which was nice.
definitely check out the 30 day trial. And 100% JetBrains knows what they're doing
Have to dip, but feel free to ask whatever questions and I'll check it out when I get back. No pressure either way.
FYI I tried CLion for Rust, but did not feel any improvement of experience in comparison to VS Code + Rust analyzer plugin, so I cancelled CLion. In fact, VS Code somehow felt better.
I do use Rider 50/50 with big Visual Studio though. Mostly because I feel that the need to eventually switch to Linux is creeping as Windows adds more junk.
I've heard the VSCode + Rust analyzer situation has gotten really good. I think this might have been when it wasn't as solid? I'll have to check out the VSCode situation again sometime.
The one thing I don't like about Rider vs Visual Studio + ReSharper is that ReSharper has some really advanced structural/semantic searches that haven't made their way into Rider. I don't use it a ton, but being able to do queries across the AST annotated with semantic/type info is really useful if you're working on a legacy C# project that's been copy pasted fifty times--once per state (actual thing that I ended up working on)
otherwise, Rider is rad, and I have way more intellij platform bindings and such setup for them all
> The powershell command names though
Just wondering if you're talking about command name length or something else?
Asking because it comes up a lot and almost all the common commands have idiomatic short/terse versions (gci for Get-ChildItem, etc).
No shade, though. No reason you'd know if you don't have a reason to know it.
Would love to hear if I'm making the wrong assumption and it's something else you're talking about. I personally really love powershell, but also get why people love bash. I'm still pretty comfortable with bash because I work in *nix systems mostly, so it makes sense for me to know it, whereas the reverse (with ps) isn't really true for most devs
Yeah that's basically it, so thanks for mentioning abbreviations! I knew they had some aliases (e.g. ls, curl) but not that it was commonplace because any powershell tutorial uses the long form and capitalizes everything (indeed I don't interact with PS a lot). It all feels very design-by-committee. Not sure whether it's a good thing that guides never use the short form: long more readable, but the specific choices of words give me weird vibes and run off blog-width line lengths. OP shows that nicely with the bash version fitting on ~60% of the line (on my screen) but the PS version running out of the line.
A lot has been written about naming things and brevity versus clarity, and while I sit very firmly on the programmer's side as opposed to the math people side (single letter variable names, in weird fonts or languages if they (surprise!) run out of available letters), I think I am more of a bash person than a java person in terms of naming things. Word-ish commands like pushd, kill, read, etc. (taking some bash built-ins here as examples, rather than external programs which may be named arbitrarily) seem a lot nicer to me than either very long commands or acronyms where you basically still have to know the long form to remember it. I'd never have guessed that spps stands for stop-process yet that's the portable powershell form of 'kill' (just looked that one up).
I think this kinda shows the issue, and why I personally prefer ps (as someone who's bounced off bash and NEVER gotten the time to get decent at it, and who rarely needs to use any of these and never at any serious level, so massive grain of salt).
Kill is intuitive to you because you've probably been around tech your whole life, and tech has just used "kill" ever since. It's essentially as ubiquitous as "bug".
That said, if I had to teach someone brand new with next to no skills (the endless goal of making coding easier for the average person and so on), Stop-Process is a hell of a lot easier to teach, or rather, it's much easier to teach them to help themselves.
Since it follows the same naming template as every other powershell command, if you teach them how to use the basic commands like Get-Help/Get-Command, they're a hell of a lot more likely to figure it out themselves without needing assistance. You know that every cmdlet is verb-noun, and you know you're trying to stop a process, so something like
> Get-Command "*process*"
Gives you a short list that is extremely intuitive to figure out.
Now...for something as simple as "kill" you're not expecting a beginner to run a command with a wildcard search. You'll just tell them. But that entire philosophy is extremely helpful when you're in a situation where you do need to figure out the command and don't have the ability to just spend however many minutes on google, and if you teach PS right you get to a point where it's very easy to teach yourself.
Obviously how much this matters in a world of IDE's and search engines and now AI is questionable, but I think that if you redid bash today, it'd follow similar philosophies. Things like touch, grep, and arguably even echo really strike me as "favorites" just because of the inertia/ubiquity.
The convention is to use the short form whenever you are in a terminal for one-off commands, but go for the full name for script files that has to be maintained/read later — which is an absolutely sane policy in my opinion.
Bash is a write-only-full-of-bugs language, comparatively.
100% and I never thought of that before but I can see how you'd get that impression from tutorials.
The VSCode powershell extensions will also give you suggestion squigglies under all of your aliases in a saved script if they're not long-form, but I usually mix and match based on pragmatism.
My use of alias vs long-form usually comes down to two sort of situations:
* Ad-hoc at the shell: all aliases all the time (and make my own if I need to. welcome to my godless wasteland, population: me) * Shared scripts: Just like any code, do what's idiomatic for the team. Usually it's largely aliases with some long-form
In practice I'd say the formatting consistency situation on teams isn't nearly as bad as SQL but obviously not as good as Go.
For reference, I'm also a huge APL fan, so hit me with arcane symbols in my free-time all day long, but definitely pragmatic balance at work.
I also don't even think of them as acronyms personally. The acronym just sort of means the semantic action in my brain at this point, but I think that's mostly a fluency thing, and can't really speak to it being hurtful/helpful since I'm so removed from when I first started learning it
Regarding not thinking of them as acronyms: yeah I get that. I was wondering how to best phrase that sentence because, indeed, curl also does not stand for C Uniform Resource Locator in my head, or grep for global regular expression perl-style (if I'm remembering that one correctly). It's just curl and grep. However, whereas curl and grep are really treated as names, spps I can currently regurgitate only by thinking of stop-process, and I imagine most such abbreviations will be like that for a while.
totally agree, and yeah, "you eventually memorize all the arcane bits" definitely isn't a point in favor of powershell
there are also some commands I use all the time that don't have built in aliases like the json converters, so that makes cross-machine alias consistency for some important things not great
I think the long form is because people usually tab to complete the names. Personally once you learn them they dont get that hard to type
It's just a knee-jerk reaction people have in any thread where powershell is mentioned. "Hur hur long command names." Doesn't bring anything to the discussion.
I can see where you're coming from, but to me it's not some meme or joke. I find it similarly annoying in Java, for example, and it makes me want to use that language less. Obviously it's only a small part of the whole consideration.
Every common command has a short alias, or often multiple short alias. Get-ChildItem => "ls", "gci". Get-Content => "gc", "cat". These aliases are standardized, you can look them up with Get-Alias (or "gal" ;) ).
It means that working in the terminal, you can use short commands, and when you write a long-term script, you use the long names so that the script is more readable.
What I find great is that flags also have aliases that are standardized across commands.
This is why I'm annoyed at this meme. It just stems from ignorance.
What’s long in Java? It sure longer than the absolutely insane C convention of snrcph whatever, but these AbstractFactoryFactory things are just memes - the Java convention is to prefer full words, but that’s the same in I believe the majority of languages - JS, Rust, Python all use basically identical names, at most casing differs.
I assume you similarly also find Apple's swift/objc API's annoying. (If not, might want to objectively evaluate bias)
Yeah, it can definitely be kind of a meme, but also I've never had a bad time bringing it up in good faith. A lot of people don't even realize it's a knee-jerk meme response to them. OP also doesn't seem to just be MS bashing, and I think there's a reality that the typical linux/macos dev just doesn't have a compelling reason to sink time into vetting PS, whereas I had a reason to learn it and ended up really digging it.
But I do get what you're saying and think it's a common meme that's often unhelpful
It doesn't bring anything new to the discussion, but if it is the reason people don't use it, then it is relevant.
I don't use it, because I was Mac/Linux at home and Linux at work for so long - only now do I have a reason to.
I think that's important, tbh
I love powerful. I've used it for a long and even though I primarily work on macos/linux now, I install powershell core on everything.
That said, I _started_ using it because I was working on a windows box doing C# and managing windows servers.
There's just not a compelling reason for a dev to learn it outside of personal interest, and I think that's a completely legit mindset, since we all have limited time. I'm even fine with misconceptions--we all have them about something--as long as the person is being a decent human about it (which is why I've enjoyed this thread/comments)
It has its benefits, other people's scripts are very readable, and often you can just guess the correct command without having to look anything up.
Even with the default short aliases like gci there are only ~100 unique commands/commandlets aliased and 600 commandlets in a default install. Not to mention what happens when you start loading other commandlets. Trying to predicate your usage of PS on just using short commands is also going to fall short in documentation and searches. I recommend just getting used to the fact command names are long. <tab> is a good friend too.
Often mentioned failing of powershell commands is that they went with Verb-Noun, when the reverse would have been much more discoverable. You want to specify what you want to operate on first, Get-<Tab> will be much less useful then Process-<Tab>.
Otherwise, despite their length I do like these long names, you can have aliases for ‘ls’ and alia, and flags fuzzy match.
Is there a Powershell script to disable adware on a windows 11 box ?
lol, you know what's funny is that I actually used to have a script like that for windows 10.
I volunteered to help a local nonprofit image a bunch of laptops and they'd bought win 10 home licenses for something like 30 laptops. The whole thing was kind of a nightmare but got most of the adware stripped out, I think, but not all of it. been awhile, so hard to remember
>A lot of people coming from the Unix-like world of macOS and Linux don't tend to know [PS]
We all have different experiences of life but I have never found this to be the case. Linux users are savvy and curious about things even outside their bubble.
The only people I can imagine this being true for is the true greybeards who have been daily driving Linux for 20 years.
Well, you also have an insane amount of linux users who hate on systemd/wayland/gnome non-stop with complete ignorance. Though they are more of a vocal minority given that they are the defaults on most distros.
On the C# IDE front, Rider is excellent on all platforms (even on Windows I prefer it over VS), and a lot of production C# software is now running on Linux. It's not limited the way it used to be.
For PS, the other thing is I think people hear "object-oriented shell" and think every command has to be custom-built to interface with all the others and isn't pluggable like standard pipes, but that is untrue.
There was a time when Internet Explorer was possibly the best UNIX browser. We ran it on Solaris.
Yeah. Reading the 3-pipe solution in bash versus 4-pipe solution in Powershell felt like it was verging on parody. Yes, these object-oriented features are nice - but they're something of a self-imposed problem on an OS that's designed like a database. Even the tools we use to parse JSON in bash aren't all that bad, if you can keep yourself grounded in the world of text processing.
I'm glad that the OP has a workflow that they like, but I'm not really convinced the grass is greener on the other side. I've used a lot of shells, Powershell doesn't really wow me that much anymore.
Nah, passing text around is not a good thing, you can’t even write a properly maintainable script that queries the temperature of your hardware or whatever property you are interested in, these will be one-off hacks, breaking even from a change in locale.
If the long command names bother you so much most have short aliases, but it's worth remembering that the short ones are cryptic and not that instructive if you're not already initiated.
It's not that bad. I'm mostly balking at the idea of `ConvertFrom-Json | ForEach-Object { $_.name }` being any easier to remember than `jq '.[].name' -r`. Both examples seem to "convert" text to JSON with a parser, it's like arguing over the difference between awk and catting into grep. Neither really seem more advantageous than the other.
How I'd normally write that command in PS:
`$someJsonText | convertfrom-json | % name`
the `| % [property name]` is shorthand for pulling out some root level property on an object in the pipeline
(just for reference; not really trying to prove any point)
What I personally like about PS in this case is that the syntax of the operation feels very consistent with the rest of powershell, but that's not a dig against jq (I use it a lot when I'm on macos); just my subjective impression, and not an objective claim of quality.
The point is not about being easy to remember (powershell commands and their args can be autocompleted with tab so memorizing them isn't really important). It's about powershell being the object manipulation environment instead of a 3rd party tool like jq. This makes it easier to do stuff with your data with a .Net powered runtime rather than having to manipulate strings using tools with their own built in languages
I find the former much more self-explanatory than the latter but, for instance, can't ForEach-Object be written as for?
I'm still a PowerShell novice, but I believe ForEach-Object and ForEach are subtly different, and PowerShell has classic For(Init; Condition; Increment) loops also but it's even more different than those two.
ForEach-Object and ForEach are the same thing.
Get-Help ForEach-Object
...
ALIASES foreach %
I have seen that, and that's partially why it seemed so confusing to me but at least one difference is
https://learn.microsoft.com/en-us/powershell/module/microsof...The ForEach-Object cmdlet works much like the Foreach statement, except that you can't pipe input to a Foreach statement. For more information about the Foreach statement, see about_Foreach.And another appears to be performance
https://devblogs.microsoft.com/scripting/getting-to-know-for...PS /home/me> $time = (Measure-Command { >> 1..1E4 | ForEach-Object { >> $_ >> } >> }).TotalMilliseconds PS /home/me> [pscustomobject]@{ >> Type = 'ForEach-Object' >> Time_ms = $Time >> } Type Time_ms ---- ------- ForEach-Object 144.558 PS /home/me> $Time = (Measure-Command { >> ForEach ($i in (1..1E4)) { >> $i >> } >> }).TotalMilliseconds PS /home/me> [pscustomobject]@{ >> Type = 'ForEach_Statement' >> Time_ms = $Time >> } Type Time_ms ---- ------- ForEach_Statement 17.621Hey TIL, though, I knew there was a difference (the foreach statement is meant to be typed all lower-cased, since it is not a cmdlet but really a shell built-in but PowerShell is case-insensitive). Get-Help gets you information on cmdlets, not shell built-ins.
Though I was referring to the cmdlet, you're absolutely correct.
> even putting #!/bin/python3 at the head of a script so that it runs through the shell.
It's not the shell, it's the kernel that interprets the so-called shebang. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
Edit: oops, should have previewed, cryptonector beat me to it.
Yep, imagine how things would be like if the kernel didn't understand shebangs. exec() calls would fail for non-ELF executables and we'd be devising all sorts of ridiculous workarounds. We're lucky that didn't happen.
> Yep, imagine how things would be like if the kernel didn't understand shebangs. exec() calls would fail for non-ELF executables and we'd be devising all sorts of ridiculous workarounds. We're lucky that didn't happen.
Actually, that did happen. Quoting https://utcc.utoronto.ca/~cks/space/blog/unix/ExecAndShebang...
"In V7 (and versions before it), the exec*() family of system calls only worked on actual binary executables. In order to make shell scripts more or less work, the shell (and I think perhaps some other programs) reacted to an ENOEXEC error by assuming the executable was actually a shell script."
And yes, the ridiculous workaround (treating the file as a shell script when it's not an executable) seems to still exist to this day.
> > even putting #!/bin/python3 at the head of a script so that it runs through the shell.
Uh, not, in that case the shell is not involved at all. The kernel implements shebang and will automatically start the interpreter, whatever it is, without having to go through the shell.
so, a typical noob. Even though he claims he shined in the operating systems course.
My son shined in that course, but I'd be surprised if he knew this particular bit of trivia.
so they didn't learn about fork/exec in that course? I don't believe it wasn't mentioned :)
OS class is not about Linux, its about OS theory. You learn the algorithms for priority queues and preempting tasks and even build a simple OS (depending on the class). Very little of it is about how IRL operating systems/kernels like NT or Linux work, though they did use some examples to demonstrate. Forking was more in Systems programming class, but that class was more about C, system calls, linking, and gdb. Not much time was dedicated to the syntax of shell scripts.
"forking" has absolutely nothing to do with "the syntax of shell scripts".
Proving my point more and more here…
Again, try to remain polite. I understand how forking works. Knowing how shebangs work is not something they teach directly. Forking is.
so you know about fork but not about exec. It's not impolite to point out you didn't know something.
It's impolite to get offended.
No, im referring to your original comment calling me a "typical noob". It was an immature comment which contributes nothing, and again I think youre capable of more maturity than that.
Obviously, this conversation is based on your misunderstanding of the original post and so I dont think its a worthwhile use of either of our time to enumerate the chapters and system calls from a college class. Knowing how processes are created in a generic operating system is not the same thing as knowing how shebangs work on unix-like systems. Again, OS class is about how to MAKE an operating system, not how to use one
That particular bit of trivia wasn't covered. Why should it have been?
This was a rude comment, and I think youre better than this
I thought we were supposed to be using `#!/usr/bin/env python3` and not `#!/bin/python3`?
There are two commands that do work in shebang: /bin/sh and /usr/bin/env. Everything else will break sooner or later: BSDs, Nix, Linux distros with separate /bin and /usr/bin and so on.
Correct. What OP uses would run on none of the systems I work with as far as I know
Defintely, `#!/bin/python3` will not work inside venvs, I suppose.
Or any distro that doesn't put a python3 executable in /bin. Many current distros symlink /bin to /usr/bin, but not all do, and python3 would usually be in /usr/bin. POSIX only requires /usr/bin/env and /bin/sh to exist, every other path you might use in a shebang can be moved around.
That "very specific thing" does not imply it should be so bad as to be foreign, you could have your much more ergonomic python in the shell as well without all the bash baggage
There _is_ Xonsh, which is Python based shell.
Dude is productive using Windows. It works well for him. It could be an option for you or anyone else too. You've lost the plot here.
> If the software is written well, it will be sufficiently cross-platform and modular enough
Yes … well …
We brought on via acquisition a bunch of Windows devs. It turns out we can't even clone the repository onto their laptops: some files in the repo have ":" in the filename, which is forbidden. There's a "aux.rs", also a verboten filename in Windows. And then there were some that differed only in case, which honestly I don't know how we manage that, as the non-Windows side is macOS, and yet roughly once per year someone introduces two files, same name, differing case into the repo.
> that "CRT" shader
Okay … that's not what CRTs looked like. Like, the curve seems way overdone compared to my memory, and IIRC the "lines" affect was really only visible on TV/camera. I have no memory of noticing it IRL, and I spent plenty of time at a command prompt.
(E.g., this random example — https://i.redd.it/1s3ny22b2va51.jpg — matches my memory pretty closely.)
(Also there were flat screen CRTs, but those were relatively late to the game and were rapidly obsoleted by actual flat screens.)
Edit: but also I want to play a round of Hack¹ with that shader.
¹i.e., quest for The Amulet of Yendor; you might know the newer incarnation, NetHack, but I didn't play that until flat screens, I think; the CRT time would have been on Hack.
Yeah, that looks like it's simulating the rolling lines that could show up in a video of a CRT, which is just an artifact of the camera and display both refreshing in similar fashions/at similar rates but usually not being locked to each other. A similar fixed lined/brightness gradient on a still photo is an artifact of a snapshot vs the persistence of vision effect that makes the screen look uniformly bright.
Some people were more sensitive to CRT flickers than others but it didn't look like that, even at 60hz (a low rate for a PC monitor). It was more a flashing-the-whole-screen-on-and-off-constantly effect; the effect of moving lines in videos move far slower than 60hz.
I had a bug last week. Some people on the team had certain files missing in ZIP-files generated by our back-end. So I downloaded the ZIP-files from the back-end and it worked fine for me. Asked them to sent me the ZIP-files directly, I could extract all files. I had no clue why it didn't work for them but I knew that they ran Windows. So I installed Windows 10 22H2 in a VM and as it turns out, having "->" in the filename causes Windows to ignore those files when extracting a ZIP-file.
> There's a "aux.rs", also a verboten filename in Windows.
That's not true.
> And then there were some that differed only in case, which honestly I don't know how we manage that, as the non-Windows side is macOS, and yet roughly once per year someone introduces two files, same name, differing case into the repo.
Sounds like a crappily maintained repo.
It is true.
https://stackoverflow.com/questions/40794287/cannot-write-to...
https://www.howtogeek.com/wp-content/uploads/2018/11/img_5be...
And for the historical explanation for why these filenames are special even with an extension, see https://devblogs.microsoft.com/oldnewthing/20031022-00/?p=42...
"Suppose you wanted the listing file to go straight to the printer. [...] So you typed “PRN” as the filename. Now, the assembler doesn’t know about these magic filenames. So the assembler will try to create the file “PRN.LST” and then start writing to it. Little does the assembler realize that the output is actually going to the printer."
Windows path handling is full of special cases and subtle gotchas. See https://googleprojectzero.blogspot.com/2016/02/the-definitiv... for a very detailed list.
Look, I just created a file named "aux.rs" on my Windows machine. It's not true.
I've seen this plenty of times, but maybe if was fixed in the last year or so. My issue was when trying to delete a Linux source tree that was git cloned on Linux onto a flash drive. Maybe the filesystem had something to do with it, but it was entirely impossible to delete it using any tool I know of in Windows.
I think they have changed it so that you can by now create files with forbidden names and an extension. But that's a somewhat recent change.
Also you could always create such names with the right APIs, so one application could create such files, but another can't delete them or open them.
Same. It's definitely not true
> That's not true.
Well, just for you, I've searched the Slack history. IIRC, this was inside a WSL session in Windows, but it definitely originated on a Windows machine:
$ git checkout rename-some-files error: invalid path 'foo-crate-1/src/aux.rs' error: invalid path 'foo-crate-2/src/aux.rs' error: invalid path 'foo-crate-3/src/aux.rs' <more filenames with other errors>
One of those examples when religious backwards compatibility poisons the future for a much bigger user base
You can enable case sensitivity per directory. That moves the problem to making sure any tooling they use doesn't have an issue with that though. E.g. Sublime is capable of opening something like C:\Example\file.txt instead of C:\example\file.txt but trying to open both at the same time doesn't work. Normally Sublime would put the folder path in front of the name but on Windows it assumes the folder path is not case sensitive and performs the "is this file already open" check with case insensitive logic.
The story with enabling long file paths is even sadder. Explorer doesn't support them, for example.
> some files in the repo have ":" in the filename, which is forbidden. There's a "aux.rs", also a verboten filename in Windows
You're complaining 'bout 'doze, not devs. Come on, dude!
> (some business about CRTs but not whatever I expected with (absolutely correct-thinking) Line Feeds at the end of every line of text.)
Um . . .
Look, I understand that you didn't have enough experience to handle these outsiders, but that seems like the most understandable outsider group I can imagine. (And I don't have to imaging 'doze habits - I've seen a bunch up-close!)
Could they keep the files in WSL and run their IDEs in Windows?
IIRC, they were cloning in WSL, but AIUI at the time, WSL is still subject to the requirements Windows imposes on filenames.
(I'm not a WSL expert, so I could be wrong here.)
I believe colons being forbidden in filenames is an NTFS limitation and not Windows itself, but the specific whole filenames you can't use are probably part of Windows.
This colon thing has come up for me in the past when giving people access to a GNU/Linux file server with movies stored with colons in the names. I think using SMB or NFS on Windows, the files just didn't show. I refused to rename the directories for this one guy and instead copied the files to a second spot for him to grab. I really appreciate and enjoy putting colons in filenames and would not easily give it up.
WSL2 resolves these issues by creating a virtual disk instead of sharing the ntfs partition with Windows. Frankly though the fact that I had to type that sentence out is ridiculous.
Inside the filesystem shim, WSL will replace forbidden characters with unicode private use characters by adding 0xF000.
not sure about other IDEs, but VSCode has very good WSL integration for doing this iirc
You can type code inside a WSL shell and get a VSCode configured to work inside it.
Disclaimer, I dont use the crt shader, I just thought its cool that you can do that
Complaining that bash on macOS is old is valid, but it doesn’t seem relevant here. If you’re just going to use Powershell on Windows anyway, then surely bash doesn’t matter on either platform.
More relevant in my view is how well the workstation you use supports interacting with your build system. In many organizations, the actual build environment is only ever going to be Debian or alpine in a container, in which case, it doesn’t really matter which computer you have on your desk. If all your building happens remotely on a cloud instance, it hardly matters at all.
So by all means, use whatever computer you want. The great thing about the current era of computing is how little depends on the computer for getting work done. The author’s Chromebook story makes this point perfectly. Use what you have or what you like or what you can get, and get on with life, I say.
Mac OS switched to zsh a couple releases ago due to bash being GPL 3 so the shell isn’t old anymore and installing bash is as easy as brew install bash.
The default OS-provided shell is irrelevant; anyone who cares an iota about DX on their dev machine is going to set up their terminal and shell from scratch anyway.
Only if you use osx… on linux there is no need to do such a strange thing.
Right, because Linux users are famously content to accept OS defaults and have no interest in tool selection or customizing their setup.
/s
Hahahahaha.
Now show me a linux distribution where what you are saying is true.
RHEL, "welcome to everything is old".
Unfortunately it's also a headache to use Linuxbrew with RHEL because it keeps trying to install its bottled glibc which doesn't like the old (but heavily patched) kernel and breaks everything not statically linked to the system libc until you remove it.
in red hat you need to compile bash to have scripts run?
Yeah he says because you have to update bash he prefers using WSL2. As if you don't have to install that???
I think you misread. I dont prefer WSL2, I rarely use it directly. I prefer powershell
wrt relevance and relevance...
macos used to be relevant, but now (like the jackling house) all the unix underpinnings have been left to rot.
[1] https://en.wikipedia.org/wiki/Jackling_House
By the way, macos bash is technically in violation of the GPL, as it doesn't ship the source for rootless.h (no, not the x file by the same name)
From everything I've heard about Windows turning into user-hostile bloatware over the last few years, nothing in this post seems like a good enough reason to use it. Perhaps it's Stockholm syndrom, but I honestly like my Unix-y tools (bash, jq, awk) at this point
Also, regarding this example
{
$Env:MYSQL_HOST = "MyHost.com";
$Env:MYSQL_USER = "MyUser";
java -jar myprogram.jar;
}
(
export MYSQL_HOST="MyHost.com";
export MYSQL_USER="MyUser";
sh -c 'echo "using $MYSQL_USER@$MYSQL_HOST"'
)
sh -c 'echo "using $MYSQL_USER@$MYSQL_HOST"'
using MyUser@MyHost.com
using @At least one subtle difference, is a bare scope block like TFA has, will print out everything in it instead of the output you would expect, where as Bash behaves more like Invoke-Command -ScriptBlock {}.
Compare:
PS /home/me> { >> $Env:MYSQL_HOST = "MyHost.com"; >> $Env:MYSQL_USER = "MyUser"; >> java -jar myprogram.jar; >> } $Env:MYSQL_HOST = "MyHost.com"; $Env:MYSQL_USER = "MyUser"; java -jar myprogram.jar; PS /home/me> Invoke-Command -ScriptBlock { >> $Env:MYSQL_HOST = "MyHost.com"; >> $Env:MYSQL_USER = "MyUser"; >> java -jar myprogram.jar; >> } Error: Unable to access jarfile myprogram.jarPeople were complaining that Windows was "user-hostile bloatware" as long as there's been a Windows to complain about.
Sometimes a cliche is a cliche for a reason.
I certainly felt the hostility when I discovered the preloaded apps and ads in my Win11 install that aren't included in the much more expensive enterprise version.
https://news.ycombinator.com/item?id=35614190
> Microsoft plugging more ads into Windows 11 Start Menu
I mean, come on.
I dont really see the answer to the question in the article, maybe I missed it.
You can use PowerShell on Linux. You can use vcpkg on Linux (very well, even). You can learn C++ and you wont need the `_In_` and whatnot. If you use WSL2 for your development, are you even developing (fully) on Windows?
What you can't do is really own a copy of windows (any recent one), and have the freedom to decide what tools you will use. There is nothing protecting your system from locking you out of any setting, at any point, and requiring you to buy a different key, subscribing, giving them your data, or whatever else.
This, a million times. I am not principled enough to live without closed source hardware and software. But I've experienced too many changes to tools I didn't ask for and didn't want to try to advocate that closed source is better than open source alternatives.
> If you use WSL2 for your development, are you even developing (fully) on Windows?
Maybe it wasn't clear in the post: I dont use wsl except as a backend for docker. I use powershell, not bash
> There is nothing protecting your system from locking you out of any setting, at any point, and requiring you to buy a different key, subscribing, giving them your data, or whatever else.
Thats not something I care about
> Thats not something I care about
Well what's the point in having a debate about any of this if you've yet to experience closed source software taking something away from you?
I've followed a different path, but I've come to the same conclusion. Along my path, picking up languages like Haskell or Node early on meant using Linux. So since high school I've always had _a_ Linux machine available, but preferred to use Windows as the user interface.
Two thing I can say for any naysayers who use a Mac and do devops, backend development etc.:
1. Are you sure your environment that matches your deployment environment? Do you have confidence your server code runs the same on an Apple Silicon Mac as the (very likely) x86-64 and Linux environment your users use?
2. Have you ever noticed how shell scripts on Mac often... don't work the same on Linux? The way to fix that is of course use Homebrew, and, while brew has gotten leagues better, the quality pales in comparison to even Debian testing, Ubuntu main, or Arch and others.
As a devops engineer for many years, #2 was death by a thousand cuts. If I could, I'd have replaced every Mac user's userland with GNU coreutils from brew without their permission.
To square the circle of preferring Linux systems and Windows' UI, I've done just about every approach you can imagine to make that work, from syncing folders via rsync, to ssh or nfs mounted filesystems. I've used Virtualbox and VMWare and Hyper-V to locally run the Linux environment. There have been a few different X window managers and remote desktop tools, but none of them have been great.
WSL1 is where things really began to turn around - what an interesting project to make the NT kernel work as a Linux kernel. It didn't quite pan out, but that was OK.
WSL2 made major changes to how WSL worked, and now I can now run Kubernetes, Docker, 3d applications, machine learning (stable diffusion), have a real Linux shell and userland.
WSL2 is a true game changer for quality of Linux development on Windows. Being able to `docker run` Stable Diffusion or Llama or what-have-you is incredible.
I can imagine a PopOS - or another vendor-backed Linux OS - might persuade me eventually to shed Windows. In the meantime, I don't feel like I'm making any compromises.
> 1. Are you sure your environment that matches your deployment environment? Do you have confidence your server code runs the same on an Apple Silicon Mac as the (very likely) x86-64 and Linux environment your users use?
I’d argue that a lot of us are developing SaaS etc and the browser is our main touch point, so this isn’t necessarily as relevant.
I often run into the issue of forgetting to set node affinity in my deployments and my x86 backend not running on an ARM server we have for some reason (nothing we do requires ARM, so idk why we have those nodes)
Your shell scripts on Linux don't even work the same way as the docker image based on ubuntu. Resolving those issues is just part of the job.
I recently had this issue where my version of SSH was too new compared to that the servers were running and I was getting issues about the cryptographic algorithm being mismatched.
> I recently had this issue where my version of SSH was too new compared to that the servers were running and I was getting issues about the cryptographic algorithm being mismatched.
I think that when your encryption algorithm gets removed, after having been deprecated, is really time to upgrade instead of commenting on ycombinator.
Tell my old job not me lol
After 8 years on macOS, I was forced into developing on Windows back in 2015 when I was making a VR game. WSL1 hit at exactly that time and once I suffered through setting up the environment on ConEmu (Windows Terminal nowadays is wonderful), I never looked back.
I have gone the other way. Used to be a hardcore C#/.NET Framework dev on Windows and I still occasionally use Windows 11. However, since the advent of containers and dotnet core I've been doing lots of devops work. WSL2 is annoyingly slow and has its quirks vs a normal Linux. Docker Desktop with WSL2 backend is slow too. PowerShell is cross-platform so one can use it on Linux just fine.
A lot of praise for the "little known" (???) Path variable in windows. But dealing with windows path really sucks for one major reason: there's a shockingly low character limit [0]
Also idk if this is a problem for anyone else, but since admin privs are required to add to path, I need to fetch IT every time I need to add to it on my work machine, lol.
[0] https://superuser.com/questions/1385854/how-do-i-bypass-rest...
The PATH variable in windows has a low character limit but if your path is properly set up as a REG_EXPAND_SZ, then you can just add more and more variables to it and I dont think the expanded version counts toward the character limit. One reason you shouldn't save your path variable changes from your terminal is that it implicitly converts to REG_SZ on save
Yeah, that is what I do. It seems really sloppy though, a tactic for dealing with poor design
I'm a battle-scarred Windows developer (more by chance than by choice, mind you) and even I find Powershell exceptionally annoying.
The commands are verbose and the syntax is non-standard in a way that, quite frankly, is unnecessarily and exceptionally annoying.
But the worst thing is some super confusing aspect of how scopes for variables etc work.. which I've somehow forgotten already because the last few times I needed to write something in PS I straight-up got ChatGPT to do the legwork.
I have no idea what the point of this article is. It just seemed like rambling. Are you trying to get us to switch to Windows? To shame macOS into a better dev experience? To justify your own decisions to yourself?
I wrote it after reading several articles on Microsoft's docs page which are all stories of developers moving from Mac to Windows. All of those stories boiled down to: "WSL makes it easier to have the same development workflow on the PC as on a mac". I felt this was short-changing a lot of the other features of windows that I like and wanted to point those out and make the point that windows is, I believe, a good development platform even without WSL.
Also, many people here are saying "yes, I know all about powershell and the terminal and path variables, this is all obvious", but my experience IRL with developers who use macbooks is that they haven't touched windows since maybe 7 and literally did not know anything about the various features here. So if the information here is unconvincing, thats fine. If its not news to you, then you're probably not the kind of person I'm talking about
Addi
See, now that makes a lot more sense. As someone who owns a Mac for personal projects and uses Linux+Windows at work, the article felt like a random collection of facts. I think with that upfront information and a little structure it could be an interesting read.
PowerShell 7 can be installed on Linux and MacOS! Native too, not like cygwin bash.
Around the same time that came out, so did WSL so I never really learned PowerShell because now it's so easy to run real bash on Windows.
> Native too, not like cygwin bash.
Are you suggesting that cygwin's bash is not "native"? It isn't installed by default, obviously, but it is a native Windows executable, as are the other command-line tools generally installed with it.
cygwin has a different ABI, and does weird things for its POSIX compatibility. In that sense, it's not native.
No hate to OP, but almost every single argument in the article regarding Powershell boils down to them not knowing a thing about bash. I know this is the case, despite the claim in the article that they do, because it's clear from the text.
I also felt bash was cryptic before I decided to actually learn it. Now it's one of my favourite languages. All it took was reading "man bash", which is actually super clear and surprisingly enjoyable to read for a manpage.
As I was reading this article, initially I felt like I wanted to "rebut" the claims, but by the time I finished reading, I realised I would basically end up having to rebut the whole thing. (and doing so on a phone is simply not worth it).
Honestly, learn bash. It's actually beautiful. By all means, use PS too; but judging from your article, you're missing out on a lot of great stuff.
You're incorrect. I know bash and the syntax is not user friendly for me.
You only had a response to the powershell part?
> You're incorrect. I know bash and the syntax is not user friendly for me.
We're not disagreeing then. I specifically said I also felt bash felt cryptic back when I thought I "knew" it, but didn't really know it, as it turned out. Casual familiarity, or even frequent but superficial friction with bash definitely leaves one feeling they're dealing with incomprehensible symbols and hackiness most of the time.
But, the thing is, I'm not "guessing" you don't know it well enough. I'm inferring it clearly from how you described it in the text. Because it reminds me exactly of how I used to think about it too, before I invested the time and learned to love it. Perhaps you think you know it well enough, but the way you talk about it suggests you don't really. Unless of course you intentionally chose very contrived examples to push a point, but it didn't seem to me that that's what you were trying to do.
That's not to say that once you learn it properly you will certainly 100% percent love it and ditch PS of course. I'm just saying from the way you describe how you work with it, you don't sound like someone who's really really gotten comfortable with it and learned to rely on it. And if and when you did, I suspect you'd start liking it more. Happy to be proven wrong of course (not that that's important either way, we're just random guys expressing personal opinions over the internet :p ).
> You only had a response to the powershell part?
Yes. I don't really have a strong opinion (positive or negative) about the rest. Nicely written though, thanks for the read.
The bit that I did agree with quite a bit was the sad state of macs. But I don't think that necessarily makes the current Windows experience the pinnacle of development; it just makes macs worse. (how the Apple marketing machine manages to promote macs as "the best at X" when they're arguably pretty consistently the worst at X, for most Xs, is absolutely mindblowing to me).
> But, the thing is, I'm not "guessing" you don't know it well enough. I'm inferring it clearly from how you described it in the text. Because it reminds me exactly of how I used to think about it too, before I invested the time and learned to love it. Perhaps you think you know it well enough, but the way you talk about it suggests you don't really. Unless of course you intentionally chose very contrived examples to push a point, but it didn't seem to me that that's what you were trying to do.
Wow, so you have this incredible ability to telepathically read other people's minds and you don't use it to solve murders? It's incredible that you, and you alone have the ability to know what's truly going on in someone's brain simply by reading a paragraph on the internet.
I apologise I upset you. It was not my intention.
My intent was to get you to consider that maybe there's more to bash than you may think (based on what you were saying about it), because I think it's a very rewarding journey. The intent wasn't to disparage your ability in bash.
But in any case, PS is good too. Use what you enjoy most, I guess.
You still don't get it, and based on your personality you likely never will
Powershell, an inferior shell to Bash and an inferior scripting language to Python. But probably quite useful for administering corporate windows instances.
I personally disagree on both accounts. Bash is gibberish to me and the year I had to dev python professionally was miserable
I am also miserable when speaking chinese. But I have no dobut that to people who actually speak chinese, it isn't gibberish.
This isn't really an argument against what I said. You can pick and choose your shell language based on preference for syntax. You generally learn a human language because you have to for one reason or another. I think bash has an unintuitive syntax, and I think powershell's is more readable
If languages were intuitive, it wouldn't take years to learn them.
Okay? Are we still talking about preferred shells or are we talking about chinese
We're talking about how your argument made no sense, for any kind of language that exists.
Computer languages are not comparable to human languages; your argument is a misplaced simile
I've never had any problem with understanding bash scripts.
But I had to learn. No programming language is "intuitive", and certainly not power shell.
I'm disappointed that 90% of the discussion is on the first 3 paragraphs of the article. I wrote about C++ and DirectX, too.
Almost nobody works with DirectX outside of game engine developers working on low level parts of the renderer, and there are probably only a few hundred of those worldwide. That's why the new generation (dx12, metal, Vulkan) are so painful to use. No need to make them usable when so few people use them and they want performance and control.
I just think nobody read that far
Microsoft has made Linux development cool again after got derailed by macOS. Nowadays you can use almost all Linux tools on Windows. They also provide Windows Terminal which is rather excellent.
> Windows Terminal which is rather excellent.
I'd go more with buggy but functional once you know its limitations.
Copy and paste is broken, tab naming and management is broken, its still pretty rough around the edges.
Interested in copy/paste stuff - mind adding details? I use it very often and works for me.
For tabs I don't care much as not using them.
If you do copy on highlight (no need to press ctrl-c or similar) its pretty broken.
eg. create a split so you have 2 sessions on the screen, highlight text in split A, then highlight text in split B it doesn't un-highlight the text in split A.
There are also times when highlighted text doesn't make it to the copy buffer for whatever reason.
Yeah, I do use "copy on select" since mIRC/Putty days.
Coming back to split - checked, thanks!
For me, who prefers having separate windows, not splitting by means of terminal (splitting in tmux on rare occasions though), it's natural to act those independent on selection, giving me visual hint on what I was working on - I see it more as advantage.
Microsoft made win dev tolerable by including Linux.
To properly work with git I installed gitbash -- that is essentially Linux in a box, complete with git, ssh and the basic bash tools like cat.
To do more complicated things, you can install WSL, which is literally a virtual machine running Linux, well integrated with the Windows system.
The problem of course is that well-integrated is not the same as native, but MS does have some of the best languages available, C# is pretty great.
Git exists on windows without git bash. Just run `choco install git` and i recommend `choco install poshgit` too for some helpful terminal hints like current branch
Regarding NodeJS and being cross platform, why didn’t the company just use path.join?
Because developers are lazy. I've given up the fight that is "use the language's features for path manipulation" in code review at this point. People just wanna string concat.
In python if you use a Path class for the left hand item you can do `a / "b"` and it is cross platform.
Yes, yes it is. And getting people in code review to use that, instead of non-cross-platform methods, is like pulling teeth, IME.
I don't know. This lowers the bar.
I don't intend to lower the bar, but I'm tired of the same bad pushback of "it's not my favorite way."
It's not just strcat-ing paths together. It's … everything. I've seen databases with crap passwords (think "admin"/"admin"), because someone didn't want to take the time to generate one securely. I've seen systems subsist on a shared username/password (despite that being a security policy violation) because the sysadmins on the same security team responsible for Okta a.) can't take the time to get the assignments done and b.) don't understand Okta (or OIDC, or SAML, or …). I've seen people argue for "I need the list of user emails to import into MailChimp" — no, you most certainly don't: you need to write an email within the system's pre-existing mail functionality, since that respects the users' prefs as to whether they get your spam or not — and then escalate because that's not what they want to do, despite what they want clearly being wrong, and at worse, being a violation of anti-spam laws. I've seen people repeatedly fight factoring stuff into a library "well, we're just going need this code this one time, putting it in a library is too much work" — and they're the forth person/use-case to utter this — and then proceed to hit every corner case that such a library could encapsulate nicely. (But even after that: "so, now that you've hit all the bugs and corners, are you going to library-itize it?" "no, we only need it this once, it's not going to be needed ever again".)
I don't know how to raise the bar. HN itself perennially whines about interview processes that deliver any assessment of the candidates technical acumen — or lack thereof. Interviews will be Y/Y/Y/N with the lone dissenter being the only technical interview.
And there's no reward in trying to maintain the bar, AFAICT.
Sounds like you need to change the company then.
Superiority complex
I actually kind of agree with the point about PowerShell but I suppose the problem is everyone is so used to bash scripts that they've forgotten how many annoying pitfalls they have and how cryptic they are to anyone not used to writing them. A lot of resistance to PoSh is just about it being something different.
IMHO if you are already fluent in bash and aren't running or administering windows machines, there's not much point to switch. And I personally think PowerShell is nicer, but like 10% not 10x, and they do the same things. If you know some bash though, googling PowerShell and the bash command has been pretty productive for my learning.
I would agree with what you say, but that's not really a flaw with PowerShell.
"and there are simply no good command line input parsing libraries for Java."
Looks like author missed the most obvious and popular OSS one: https://picocli.info/
What a breath of fresh air. A well reasoned post about development on Windows when it seems to be the popular thing on HN just to shit on it [Windows].
I do a lot of work where I'm exporting data from SQL Server (often needing to rely on scripting semantics and transforming, not just a static dump), and really enjoy using PowerShell for this purpose (though in most cases, I run it from a Linux server or my own Mac)
I keep on seeing all this talk about Powershell, and it's inspiring me to maybe learn some, although I've already commenced pursuit of skill in bash and python
After 3 decades working on Windows, I recently got into Linux and stared learning bash through "The Linux Command Line, 5th ed." book and watching youtube videos. Powershell is so much nicer and a lot more productive to work with compared to bash. Unlike the bash commands that returns strings, Powershell commands return objects. Working in any OOP language and Powershell feels very natural.
Just to corroborate from the opposite direction, I have run exclusively Linux on my personal machines for nearly a decade, and I started a new job where I get to use PowerShell, and it's really amazing, the amount of grep/tail/head (or Get-ChildItem/Select -First/-Last) I have to do is so much less, it feels so much less klunky. Probably the only thing I don't like more so far is Get-Help, because it doesnt put you into a pager with search, it just dumps to text. EDIT: apparently I need Help not Get-Help for paging EDIT2: and I hate that PowerShell doesn't support readline/emacs keybindings
I thought the PSReadline module had some of that but then it might be a "nearly" compatible experience which can be really jarring when you hit the edge cases.
Maybe I just didn't have enabled, thanks for reminding me, seems good enough for me
What’s the dirs -v, pushd and popd equivalent in PS?
popd and pushd are aliases for Pop-Location and Push-Location, so they are the PowerShell equivalent. Unsure about dir -v.
dir itself is an alias for Get-ChildItem, but I don't know about -v (natural sort of version number)
dirs -v presents a numbered stack of directories. Pushd doesn’t just function on one directory but also takes in a number pointing to a directory on the stack. Nothing like this exists out of the box for PS and it’s one of the most productive features in Bash.
What do those do
Keep a stack of dirs where u can jump very quickly into.
Telling ChatGPT to write you a powershell script and then explain what every part of it does makes learning it really fast. It's super handy. Powershell scripts have solved so many time consuming problems for me, like having one-click shortcuts for changing my desktop resolution or fixing all the file names in a 20TB media archive.
apt-get install package-<version> is a nightmare, because it's hard to know which version is the correct one.
Yeah, it's so awful - and IMO windows solves this problem really well.
You just don't ever get to build anything - so problem solved! :)
Its not as popular to distribute projects as source on windows, but ive personally built a dozen or so libs and dependencies from cmake into msbuild/visual studio SLN files, so it actually does happen because I've found that Linux devs don't tend to distribute precompiled binaries at all. I think this trend it changing now though because I see a lot of github projects releasing binaries for a lot of different platforms in the releases section.
Aaand I probably don't remember last time I needed to set version explicitly, it's usually just a single version of everything, mind sharing your case?
>apt-get install package-<version>
It's apt install these days.
Look into guix and guix pack.
I wish it was just a matter of the `-<version>` thing... Debian metadata (control, rules...) and its build system (sbuild, rebuild) is arcane and feels old. Having to maintain a Debian feed is a major PITA.