ghoward

Hey, what tool are you using for detection? I'd like to run it on my own comments and on my blog posts.

I do this too! [1]

It's amazing how well tmux works as a project setup tool.

[1] https://gavinhoward.com/2020/12/my-development-environment-a...

I would definitely write (or at least read) a few Bazel rules before writing a new build system that improves on it!

You have a point there; I didn't because everything I've seen is that people like the results of Bazel, but they hate writing rules, so Bazel rules seemed like something to not emulate.

But point taken.

And thank you for the explanation. It seems providers allow for multiple outputs on a target. My build system allows that, but bundling such outputs together is a good idea that I need to add.

Er, most of the capabilities of Bezel and Buck just appear.

That said, can you explain providers to me? I looked up the docs, and I'm no closer to understanding them.

I want to understand them and their uses do that my build system can have the same capabilities.

I agree.

My build system will actually have a command-line option to reverse the dependency resolution. Instead of building a given target, updating its dependencies as necessary, it will build the default target(s), marking the files given on the command-line as "changed" and resolving dependents up to the default target(s).

This will mean that building the "current file" will be a simple command-line switch that can be part of the file generated for that IDE.

But yes, I'm going to put in a lot of work to make IDE's work as smoothly as possible.

Yes, I'm a solo dev and not looking for contributors. My style is too eccentric to accept outside contributions.

Funny you should mention Bazel and Buck; I'm coming for them too! I'm also coming for Nix; I want its advantages to be easily accessible for mere mortals.

I think I can do better alone than those teams have because they have all made assumptions that weren't great. I'm learning from their mistakes.

Also, UX matters, and I'm putting a lot of effort into that.

But the other reason is that if you do Nix right, the capabilities of Bazel and Buck just appear.

Thank you for the encouragement!

That's the critical selling point of CMake in my estimation. When I'm on Windows, I can generate a Visual Studio project and use its excellent debugger and code analysis tools. When I'm on Mac, I can generate an XCode project. Or a CLion project, or Makefiles, or...

I've already addressed some of this in another comment ([1]), but you bring up more points, so I'll address it here.

CMake's model forces it to generate build files for other build systems. The better model does not force the build system to, but it also does not preclude doing so.

Separately from actually running a build (and that's important), my build system will be capable of generating files for VS, XCode, and other IDE's, but the files it generates will simply tell the IDE's how to integrate with my build system by telling them how to call it with the correct build profile. And yes, it will generate multiple possible build profiles, allowing VS users to select the solution the want to build from within VS.

But this means that my build system will not only integrate better with IDE's than CMake, it will still retain full control of actual builds.

This includes using debuggers and analysis tools, by the way. I wouldn't consider my work done on IDE integration until all of that is as easy as possible, and definitely as easy as CMake.

Isn't that exactly what an INTERFACE library is for?

Maybe? It might be enough. At first glance (and I fully acknowledge that I could be wrong here), it seems like CMake expects the "target" to be a library of some sort. That's not the sort of thing I would personally want.

I would want to be able to depend on any target for any target.

But again, I could be wrong. I've never been able to understand the CMake docs.

[1] https://news.ycombinator.com/item?id=33885476

Sure, but doing so doesn't mean that the generating build system had to have the same model as CMake.

Here's how my build system will do it: the programmer will list default build profiles. Then the build system will generate Visual Studio or XCode files that include all of those default build profiles, but those VS or XCode files will simply call my build system with the correct build profile.

Thus, when a build is run from VS or XCode, my build system is still in full control.

In essence, instead of generating build files for use by other build systems, my build system will generate files to tell VS and XCode how to call my build system. It will tell VS and XCode how to integrate it.

Disclaimer: author of a build system that will compete against CMake when it's released.

I'm not impressed, for two reasons:

* Backwards compatibility for the CMake language is not desirable. It would be better to allow files to be translated to the new language completely. Sure, CMake could support having files in the old language and files in the new language, but the CMake language is so bad that a break from it is the best path forward.

* The CMake language is not the only drawback to CMake, unlike the claims in the presentation. CMake's model is hamstrung as well, in several ways.

Here are some ways in which the CMake model is hamstrung:

* Generating a build file for another build system. This means that CMake always gives up control of the build. It can only tell the other build system the dependency graph and then sit back and watch. It can't regulate the build itself.

* No dynamic dependencies. If you need dynamic dependencies, you need to call into CMake to generate a new and separate build file for the second build system and then call that. And because the two build files that CMake generated don't know anything about each other, it's hard to regulate the use of computing resources between them; you either have to complete the one and start the other, or you risk over-extending on your computing resources.

* No way to generate a target that doesn't call an outside process. More generally, the only way to generate a target (unless my CMake knowledge is old) is to have the second build system create a child process. This is strictly less powerful than having the same scripting language available during configure also available in targets. For example, LaTeX is only properly built with a loop that checks for a fixed point. If you can't loop in your target, you have to use an outside bash script or something of the sort to make up for it.

* No way to have targets that do not generate files and have other targets depend on those targets. If a target does not generate a file, CMake does not know how to make other targets depend on it (unless my CMake knowledge is old).

* The model of "configure in Turing complete language and then build" also means that configuring often has to happen more than once before a build. You see this if you use `ccmake`: you configure, and new options appear. You set the options and configure again. More options might appear. Using plain `cmake` hides this by using defaults, but that just means the user might end up with a build they didn't want because they didn't get a chance to set all of the options they might care about.

Anyway, rant over.

Your comments in this thread were doing ideological battle on a classic flamewar battlefront. You even used the word "fighting" to describe what you were doing. Surely you can understand how lines like ""wokeists" have caused so much damage to this country" and "The community you love has done damage to [...] society" are flamebait?

No, not really. I was answering certain accusations with my opposing opinions.

Unfortunately, I can't understand where a person is coming from if I don't understand their definitions of certain terms, and I can't understand your definitions of flamewar and flamebait.

If you get into back-and-forths with an opposing user around that kind of thing, you're perpetuating flamewar. This is clearly not curious conversation.

I guess I misunderstand the purpose of HN because this line of yours makes it seem (to me) like I cannot debate political things at all, or rather, certain topics (does "around that kind of thing" means political things?), but that doesn't seem right either.

However, there are many ways to lower the expected value of a thread, and flamebait/flamewar is just one of them.

That's why I think putting the lowering of the expected value of a thread into the guidelines is the right choice: it covers more situations.

I think it's important to be specific.

I have shut off the discussion you didn't like, but it would be helpful to me if you were more specific about what you see as flamebait and flamewar. If I understand what you want me to not do, I'll avoid it, but I can't avoid something I'm unclear on. I also don't like self-censoring more than necessary (that is what the posted article was about, after all).

However, I expect that you're busy and won't be able to answer me, so extra self-censoring might be what I have to do. It makes me sad, though; I felt like HN was one place where I didn't have to do that, and now, it does not.

Edit: one thing that I could consider is trying to not answer every accusation that I'm a terrible person. Ten years ago, my Christian faith would not be attacked so openly. Now, people consider me a terrible person for believing those same things, and I find myself defending my faith a lot, albeit indirectly.

I will try to do that less on HN at least. Would that be what you are doing of me?

Please define "perpetuate flamewars" for me because I don't understand how you use that phrase.

I didn't attack the messenger, which is the definition of that phrase I usually use. I also very carefully only addressed the points the other person made.

Edit: also, I have read your comment from a long time ago about the expected value of a discussion. Perhaps that is the definition you personally use? As in, you consider any comment to be "perpetuating flamewars" once it is made in a discussion with a lower expected value than you want to accept.

I can't argue with that definition; in fact, I would accept it wholeheartedly, but (and this is just a suggestion) it might be better to make that the site guidelines, as well as to adjust your wording when you tell people to knock it off as you just did.

For example, if you came to me and said, "The expected value of this discussion is lower than the value that this site can accept, so please stop this discussion here," I think I personally would take it much better than being accused of perpetuating flamewars. And I would be more likely to obey.

You can still ban people for not obeying such requests too. I think you should.

Anyway, I hope this comment was helpful.

Guilt by association is a logical fallacy. That is not a good argument.

The community you love has done damage to the society you depend on. I have no viciousness towards any one of them except where they insist on remaking society in their image to the detriment of all others.

Ignorance through force of law would apply if the history were factual. But it's not. Preventing bad ideas from being taught is the opposite of codifying ignorance.

Parents seem to like it, though, so I don't see what the problem is.

And yes, people other than history faculty do know how to teach history better than history faculty. I don't trust academics.

I do.

And like many others, I can also look like I'm experiencing other emotions because I am. But I have a resting angry face, and it gets more extreme the more deeply I am thinking.

My wife works in a company with programmers, and they keep their webcams off during virtual meetings because, "We don't want people to see our thinking faces." Yes, that is an exact quote.

Because indentation-based languages have very limited formatting they can do. They can't do any indentation formatting.

Because they are.

And the saddest part is that Nix could be exactly there and solve another one of their problems at the same time: content-addressed outputs.

Funny. I've implemented something like this as well, but over `poll()`, and I made it handle child processes too.

I could probably change it to use io_uring and kqueue on those platforms, but I wanted to make a POSIX-compatible version first.

Without standardization, I have to rely on specific compilers. That's not great, either.

I'm also a C developer, but I do use the more modern versions.

There are four big reasons why:

* Atomics. These are the biggest missing feature in older C.

* Static asserts. I can't tell you how much I love being able to put in a static assert to ensure that my code doesn't compile if I forget to update things. For example, I'll often have static constant arrays tied to the values in an enum. If I update the enum, I want my code to refuse to compile until I update the array. I have 20 instances of static asserts in my current project.

* `max_align_t`. It's super useful to have a type that has the maximum alignment possible on the architecture.

* `alignof()` and friends. It's super useful to get the alignment of various types. Combined with `max_align_t`, it is actually possible to safely write allocators in C. Previously, it wasn't really possible to do safely or portably. And I have at least three allocators in my current project.

You're right that C11 doesn't have nearly the reach the ANSI C does, but it does have slightly more than Rust, much more if you consider Rust's tier 3 support to be iffy, which I do.

And it does have one HUGE advantage against Rust: compile times. On my 16-core machine, I can do a full rebuild in 2.5 seconds. If I changed one file in Rust, it might take that long just to compile that one file.

That's not to say Rust is without advantages; one of my allocators is designed to give me as much of Rust's borrow checker as possible, on top of API's designed around that fact.

tl;dr: I use modern C for a few features not found in C89, for the slightly better platform support against Rust, and for the fast compiles.

My home page could get on this site if I reduce the amount of CSS, but I already have it remove unused items from the CSS. Eh, fun project for another day.

I presume you are being tongue-in-cheek, and I agree, so it will probably be ruled for the cops.

But why would police treat a peeping tom differently when they do the same thing? It's so hypocritical.

I think you're right about the end result, and I do not like it. I also disagree with the Riley case: unless you have REALLY good binoculars, there isn't any way someone could tell what kind of plants are in a greenhouse at 400 feet.

I really hope SCOTUS smacks down the cops; "right of the people to be secure in their persons, houses, papers, and effects, against unreasonable searches and seizures" is pretty clear, and it doesn't matter that the Fourth Amendment was written in a time without electronics.

Also, this should apply to manual police surveillance of homes as well: there should be a warrant.

It is once again time for me to re-read The Mythical Man Month and watch his No Silver Bullet lecture. No better way to respect such a giant.

First off, do you have a blog? This information would be great as a blog post!

I think your ideas are wonderful, and I might try to implement as many of them as possible, just for privacy reasons, even if it is impossible for me to target the EU market.

In fact, because it's a code forge, there will be a client, just like Git is a "client" for GitHub. (It will be a self-contained VCS like Fossil.) So most of what you said will work.

In fact, you are exactly correct that I need the public key for signatures on code.

But there is one hang-up. While I could let the client handle checking for code signing, I still need to store the public key.

The reason for this is because the public key will also be for account recovery. Recovery via email will also be possible, unless I can't store the email address at all. But either email or public key will be required to recover accounts.

So unless I could make it so random clients could recover accounts for other users, I need to store the public key.

If you have ideas about how to get around that, please contact me. [1] Even if not, I would love to continue talking with you about this; I want to set the standard for protecting user privacy with my code forge.

Here is the bad part about this idea: Schrems II is actually saying that its not enough for the server/service to be in EU. If the company running the server/service is US owned, its still considered a data transfer to a US entity. So the signature verification service in EU would have to be run by someone not you/your company. And you'd ofc need to pay to use that service, no free lunch. So you'll have to consider if the value of being able to offer your product to EU customers worth the hassle and cost of this setup?

Yeah, I thought so. The biggest problem with that is that I have absolutely NO contacts in Europe that I can use. I may not even be able to travel to Europe to set something like that up. So because I only care about money enough to make what I need to in order to support my wife and me, offering my product to the EU is not worth it for the hassle and cost.

Btw something like the above would be privacy by design, which is a core principle of GDPR and if one makes a product in that way, that would be way more compliant than 99% of all software that existed pre GPRD and slapped compliance on after GDPR was introduced.

This is encouraging, though sad since I won't be able to make it work.

To be honest, I was hoping I could make an end-to-end encrypted code forge, but I also want to support FOSS projects, which have to do their stuff in public. End-to-end encryption would only work in that case if everyone had the client on their machine, which would not be likely for a VCS; there will be people that just want to download the code from the browser without needing an extra program to do so.

Again, I'd love to chat even more. Please contact me if you feel like doing so.

[1] https://gavinhoward.com/contact/

Please complain to your representative about that!

I have done that. Through all levels of government. But the establishment is going to do what it's going to do, regardless of party.

I'm in the process of building a NixOS-like distro. I'm 90% certain mine will use these.

I'm going to respect human rights. And I'm going to act legally, even if it appears I can't do business in the EU, which appears to be true.

Fair enough. Just wanted to make sure the take away wasnt that US companies cannot deliver services _at all_ to EU.

With the CLOUD Act, I'm wondering if it is illegal.

Just curious whats your product/service? And how is PII used (high level)? As a dev and sw architect, and strong supporter of GDPR, I think its interesting to (attempt to) find engineering solutions for the challenges posed by GDPR (and Schrems)

It's a code forge.

For users with accounts, I have to store at least email addresses, which I believe are PII. I also need to store public keys (for commit signing), which could be considered "identification numbers" covered by the GDPR.

Even if I got away with not using email addresses, I can't get away with not storing public keys, unfortunately.

I believe that once I store any PII, it's game over, right?

By the way, I'm all for strong consumer privacy protection too. I would want the US to implement something like the GDPR as well. So I'm a supporter on some level. I'm just mad at the US government for the CLOUD Act.