winget-pkgs VS bc

7.0 is now available: https://github.com/microsoft/winget-pkgs/pull/147886

I researched this for a WinGet thing: https://github.com/microsoft/winget-pkgs/pull/110618

Ah, reminds me of that time I requested a .editorconfig file in a Microsoft repo: https://github.com/microsoft/winget-pkgs/issues/329

Take dropbox as an example. This is what the yaml manifest looks like for that if you install it through winget. It literally has a hardcoded link to an .exe installer hosted by dropbox and then just set the flags to silent. I am not spreading misinformation, you are.

It's not quite the same though, as there are different considerations when using a repository of things a unified group has decided should be included and built (or slightly modified existing) packages for and a repo where anyone can submit a package that will go through some level of vetting. In the end I still believe most this discussion is really about individuals and how much trust they apply towards different groups and sources and is not really about Linux or Windows in particular as much.

1: https://github.com/microsoft/winget-pkgs

I never used winget, but probably: - https://github.com/microsoft/winget-pkgs/issues/107858 - https://github.com/Genymobile/scrcpy/issues/4027

It's probably not on the Store, winget pulls from both the Store and a community collection of manifests on GitHub: https://github.com/microsoft/winget-pkgs

I think that's part of the problem, if you don't have that package manager to bootstrap your signature key ring, DNS is your next best bootstrap. It is, of course, a terrible bootstrap for trust, but it is one so many users on Windows have been relying on for such a long time.

For power users on any modern Windows 10/Windows 11 there is at least WinGet now. Its manifests repo is becoming a very interesting (open) source of truth for common Windows applications. Admittedly, it in most cases doesn't seem to be checking specific code signatures in most cases either, but at least includes SHA checksums.

For instance, 7zip's manifests: https://github.com/microsoft/winget-pkgs/tree/master/manifes...

It's too bad there's still not a great option for "average user that doesn't know/trust how to use a CLI", given how sadly polluted the Microsoft Store can be for many common, especially Open Source, applications. For direct instance, because winget kindly includes Microsoft Store results when searching, there is a "7zip 22" in the Microsoft Store that costs some amount of money (winget details say "PaidUnknownPrice" for the pricing information; I'm on a corporate machine right now with the actual Store access locked so can't search in the actual Store right now) and the Publisher is listed as RepackagerExpress.com. (That website currently doesn't go anywhere, giving it a spot check.)

Having seen this, I may boot up my personal machine and try to report this specific Store listing for violating the Store's Open Source policies, though I'm unsure if such whackamole is all that useful. (Seems like it might be a useful winget feature request for it to provide Store Report URLs.)

For example, see that Firefox has /S here.

https://git.gavinhoward.com/gavin/bc

It got me a C programming job that had nothing to do with the side project.

I would say that it only helped me in the interview process, but it did so in two ways:

* I could actually answer C-related questions on top of the more generic questions.

* It showed that I had skill in C.

> Imagine this code...In a world where you can't optimize based on UB assumptions, x can change in the body of f.

Yeah, so you allocate space on the stack (which is free, by the way, because space has to be allocated anyway for the new function's frame), store to it, and load from it.

An extra store and an extra load. Of stack space that was probably already in cache anyway.

So what? What a miniscule price to pay.

> You don't need to share memory across threads to opt in to data races. You can access whatever you want with pointer arithmetic if you want to be correct in the presence of UB.

So C should have bounds checks and define a failing bounds check as an abort. And then such optimizations could be correct. That's what so many other languages do, and it works.

> Or this code...f could be deleted. This could be UB.

Do you mean freed?

Yes, that could be UB. But the compiler should never say, "Oh, well, f could be freed here, so I'm just going to delete the `f->do()` call."

Bad example because compilers don't currently take advantage of it. They day they take advantage of that is the day that I quit programming.

> I do not believe this. I am one of the people at my company fighting to spend performance to buy safety.

Ha! I do not believe you at all! You are okay with compilers taking advantage of UB to elide a store and a load.

The only way you are telling the truth is if your company is full of malicious compiler authors.

> I just don't believe that the principle of least surprise can be implemented in the standard in the way some people say

It totally could. C could even have bounds checks without changing the ABI. They just don't.

> I don't believe that UB is totally unique from other forms of incorrectness in a way that should cause us to behave very differently about it.

It's the only form of incorrectness that:

* Will destroy everything.

* That compiler authors claim they have a right to take advantage of.

Yeah, we definitely should treat it differently. You are dead wrong.

> Do you run your production binaries with all of the sanitizers enabled?

No, because I don't work in the industry.

But in my personal code, I wrote my own bounds checks and enabled them. In C. In release mode. All your talk of "but you could make a pointer to anywhere" doesn't happen in my code.

I use structured concurrency to allocate and free items in only one place, in the same stack frame. When threads are created, they prevent the creating thread from returning from the stack frames that the children may have gotten pointers to.

I fuzz like you wouldn't believe and make sure all paths come back clean in ASan, UBSan, TSan, and Valgrind, including memory leaks.

I add all unique paths from fuzzing to my test suite.

I'm going to write my own malloc() that will have double-free and use-after-free checks.

I use unsigned types to avoid signed overflow, and such unsigned types more easily trip the bounds checks when they overflow because the bounds checks only need one condition.

Tell you what: I would like you to take version 6.7.2 of my bc [1] and get it to execute UB. Any UB is fine.

If you do, I'll enable sanitizers on my release builds of all of my software.

But you won't, and that's why I can forego sanitizers on release builds: I do enough work to ensure that UB won't happen.

And that's why I use unsigned types. Your bellyaching about their poor optimization will not change that.

[1]: https://git.gavinhoward.com/gavin/bc

While Julia starts scared and ends up feeling better, I've only gotten more scared of Unix signals over time.

Context: I've written a robust command-line utility [0] that must handle signals, and unlike most utilities that are I/O-bound, mine is CPU-bound.

An I/O-bound utility can easily use signalfd() (subject to the gotchas in the "signalfd() is useless" post that Julia links to, which you should also read). signalfd() will work for I/O-bound utilities because it turns those signals into I/O. Perfect.

However, in a CPU-bound program, signals are used specifically to interrupt execution. This is, to put it mildly, as difficult as writing code for interrupts in the embedded space. Why? Because that's really what you're doing: handling an interrupt that can happen at any time.

My solution was something I wish on no one: I used setjmp() and longjmp().

Horrors!

Yep. And it gets worse: I had to longjmp() out of the signal handler.

AH!

And it gets worse: to ensure that there were no memory leaks, I had to keep a stack of jmp_bufs and manually jump to each one, which would be in a function where memory had to be cleaned up.

Cue screams of bloody murder

You may insist that longjmp()'ing out of signal handler is not allowed; it actually is [1], but unlike most other "async-signal-safe" functions, you need to ensure you don't interrupt a syscall or other code that is not async-signal-safe.

So it gets worse: I have a signal lock that the signal handler checks. If it's not locked, the signal handler will longjmp() out of the signal handler. If it is locked, the signal handler sets a flag and returns. Then the code that unlocks signals checks for the flag and does a longjmp() if it's set.

He's dead, Jim!

I have another project that is a framework in C. This framework needs to handle signals for clients. It has to be general, so it has to handle CPU-bound clients. So I had to implement the same thing. I was able to make it easier, but it is also harder because I have that one thing that messes up every Unix API: threads.

Nuclear mushroom cloud

So should you be scared? It depends; if you can get away with signalfd() and know it's gotchas, maybe not.

But if you need anything more complex, yes, be very afraid.

[0]: https://git.gavinhoward.com/gavin/bc

[1]: https://pubs.opengroup.org/onlinepubs/9699919799.2008edition...

I am a programmer and a blogger, like the author. Unlike the author, I do not monetize my blog in any way (or I assume he does on Substack).

The author is both right and wrong, just about different things.

First, he assumes GPT will get exponentially better. If that were true, all cars would be full self-driving already. GPT will have an S curve or Sigmoid function.

Second, he assumes that GPT will always be able to produce things from differing voices well. However, as more data is used, these bots will only become more homogenous. You can see clues of this when it managed to make a Biggie Smalls rap, but did not with Woody Gunthrie, whose data is probably closer to the mainstream than Biggie's. (This is a gut feeling; could be wrong.)

Third, as things become more of the same bot-like feeling, even from people, those who have their own voice and touch will stand out more. You can see this in his essay, versus the two written by the bot. The voice of the bot ones feels more stilted to me. His feels more natural.

What people need to do is to develop their own voice and touch.

In writing, develop your voice. Write without help. Write a lot. Create a blog. Put random stupid stuff there. Let yourself rant. That random stupid stuff and those rants will not be mainstream, and if it's stupid and ranty, you won't have to care about quality. That lack of care will let you have fun, and that fun will become your voice.

This is how I developed my voice with my blog.

In code, develop your touch. Don't just code; design. Think about concepts. Think about UX and workflows. Iterate until everything is great. Then design the implementation and iterate until everything fits. Then, and only then, code. But as you code, iterate the design to remove things that no longer fit and add things that do. Dogfood your software. Use it for everything you can, even things that don't fit well. Iterate and change some more to make your dogfooding easier.

The end result will be software that is easy-to-use and fits the users' needs well. That fit will be your touch.

This is how I developed my touch with my most well-known project: `bc`. [1]

But you don't even need to stop there. With my `bc`, I spent time supporting users and implementing things for them. Obviously, I still designed changes before implementing them, but I listened to my users and gave them what they wanted within the constraints I had.

The end result is a `bc` that can act like the GNU `bc` or the BSD `bc`, whichever you want. It can also be its own thing with extra features.

Listening to users is another human touch. Make use of it. In fact, that's where I will make a living from my current project: my support for it will be best-in-class [2], and that's something GPT can never replicate because it cannot replicate my brain, my voice, and my touch, even when trained on my writing.

In other words, the author is write that the 90% is useless, but those 90% were the ones where you were at least partially imitating a bot anyway. Those 10% are the human traits.

If you want to have useful skills, be a human, not a fleshy bot.

Footnote: I feel bad for anyone that gets my code or writing as output from GPT. My code fits my head and no one else's. It also uses custom API's that don't exist anywhere else, which means such output would be useless. The same goes for my writing, though to a lesser extent.

[1]: https://github.com/gavinhoward/bc

[2]: https://github.com/gavinhoward/bc/issues/66

Username checks out because you missed the point.

Yes, I know calculators can encourage people to not think; I should know because I wrote one. [1]

But the current "AI" tech is so much worse on that front. It's a difference of degree, and that degree does matter.

By the way, when I was learning to fly helicopters [2], I used my calculator to calculate weight and balances, but I also did it by hand!

[1]: https://git.gavinhoward.com/gavin/bc

[2]: https://gavinhoward.com/2022/09/grounded-for-life-losing-the...

Shameless plug: my bc [1] has a random number generator that is much higher quality than the shell one. Because it's bc, you can generate random numbers of any size, and you can generate random reals as well.

It is also seeded.

[1]: https://git.gavinhoward.com/gavin/bc

>Notice that I said to find a memory bug in a release, not just any commit.

You did not say anything of the sort.

>But I also said to find one in the program, not the library.

You did not say anything of the sort.

You said:

>>The code is my `bc`. [1]

>>Find a memory bug, any memory bug, in my `bc` after 1.0.

>>[1]: https://git.yzena.com/gavin/bc

But okay, let's acknowledge the moved goalposts.

>I issue that challenge again: find a memory bug in the `bc` or `dc` program in a release after 1.0.

Tell me what subset of the repo named "bc" you consider to be "the program"

>Oh, and the double-free with `SIGINT`? Rust isn't going to help you much there. Signals are not part of Rust's model.

Crates like tokio-signal allow a signal to be converted to a stream of events, which can be handled along with any other events in the program, instead of interrupting the current fn in the middle and necessitating longjmp shenanigans.

Surprisingly, it is possible to do exactly what the author wants. I know because I've done it. However, it is as complicated as the author says it is.

The project in question is my `bc` [1].

Until version 3.0.0 [2], it used a "yield" architecture: every loop it could enter had a check for a signal. This got tedious, so I decided to make the jump to instant-ish reset.

I was lucky in several ways. First, `bc` is a really good program to reset; you just stop it executing, wipe all data away, and ask for more input with a blank slate. Second, it is single-threaded.

Nevertheless, it was still really difficult, especially to have no memory leaks.

First, I had to learn how to use `sigsetjmp()` and `siglongjmp()`. Yep, that was how I was going to do this. Once I learned, I implemented a stack of `sigjmp_buf`'s. Then, when a signal happens, each individual `sigjmp_buf` is used. This allowed me to properly free memory on the way.

In essence, if a function had allocated memory, then it would push a `sigjmp_buf` on the stack, and then when a `siglongjmp()` happened, execution would go to a label where that memory would be freed before continuing the jump series.

Then I implemented signal locks. It is safe to `siglongjmp()` out of signal handler, as long as it didn't interrupt code that was non-async-signal-safe. So I used signal locks for that, and when "unlocking" the lock, it would check for a signal and jump. And if the signal handler sees a lock, it just sets a flag and returns.

Then I had to go through my codebase and protect every bit of non-async-signal-safe code with locks. It was tedious, but the result is fantastic.

Nowadays, I'm working on a threaded build system, and when it gets SIGINT, it sends a message to threads to stop as soon as their children are done. If it receives a second, it just exits.

So yeah, every application is different, but it is possible.

[1]: https://git.yzena.com/gavin/bc

[2]: https://git.yzena.com/gavin/bc/src/branch/master/NEWS.md#3-0...

You're welcome. :)

> I've bookmarked your gitea bc repo, not just for bc, but as an example of a neatly managed FOSS project, like providing performance comparison, fuzzing, project structure, the fact of using self-hosted gitea itself, etc

Thank you! It's good to know that my project is actually good; sometimes I wonder if I am just full of myself. XD

> Skimming through [1], I see neither of Winget [2] nor Chocolatey [3] have any `bc` implementations as of yet. Maybe you can send them a PR? It may help adoption in other distros in the future.

I will do that. However, I might wait until I accept a PR that was just made [1] that will fix issues on Windows. I am not good at Windows, so there are problems.

> Hope your implementation wins ;)

Thank you. :)

[1]: https://github.com/gavinhoward/bc/pull/38