busybox VS gcc

Also known as Dash in Debian (it's satandard POSIX shell) and sh in Busybox that sadly tainted the original BSD source file with GPL2.

https://github.com/mirror/busybox/blob/master/shell/ash.c

More Good projects to learn from:

  - Busybox (https://github.com/mirror/busybox)

Also, it's barebones POSIX, and not the Linux extensions you commonly think of. But, that means the processes are a lot simpler, and the code is often less complex. So it's a good place for a beginner to dip into to see how .e.g mv works, compared to GNU mv.

Sure... There are symlinks in the installation, and there's a small main() function that dispatches execution to the appropriate function based on argv[0], but that doesn't significantly impact the C implementation of each individual tool. Those seem pretty straightforward, to me. A developer reading.. e.g. chmod.c isn't going to see any evidence of symlinks, and minimal impact from the external main() function.

BusyBox: https://github.com/mirror/busybox/blob/master/coreutils/ls.c

true false

Ok here is my followup. I didn't go into detail about kea hooks [0] because I didn't write any kea hook before, but from what I can tell it should cover all your needs. You have to write c code which I find absurd tbh, but if it has the functionality you are looking for it could be a solution.

I already posted my dnsmasq "solution" so I will skip this. If you want a code example I could whip you one up.

Then there is coredhcp [1] and you can write plugins written in go for it.

From time to time some hobby dhcp server pop up, but most fade away since (I guess) the existing solutions are "good enough". I for instance implement a automatic provisioning and configurating dhcp setup with tftp and pxe boot using dnsmasq. It automatically creates pxe configs based on the mac address and some other stuff (tm). Kea seemed overkill for this usecase and I'm quite happy with what I got.

Your use case of automatically fixing hostnames through ISC seems a bit overkill to me as well to be frank. My home network has a few VLANs and every device in it is managed manually. It's a one time setup and most automation is unnecessary (and some devices in my network flatout ignore some dhcp options....). Aaaaanyway I still think that most dhcp servers out there support some form of scripting (heck even udhcpcd has a lease notify script that could be hacked to offer some of that functionality even though this gets only executed after the fact so a bit useless [2]).

> oh wait, I wonder how much ISC was paid … to do exactly this EOL … by these major ISPs?

I don't know. Nothing?

> Plausible future: I can envision a special DHCP vendor-specific OPTION to use time-based blockchain hash to further solidify their hold.

Reading your cynic banter I'm quite happy of not having your DHCP problems. Looking through your github repositories I can find a bunch of configuration files for dhclient, but not much in form of ISC configs (only the nintendo fix you posted in your first post). Would be really interested in your setup.

[0] https://kea.readthedocs.io/en/latest/arm/hooks.html

[1] https://github.com/coredhcp/coredhcp

[2] https://github.com/mirror/busybox/blob/master/examples/udhcp...

https://github.com/mirror/busybox/blob/121b02d6b6c9f276e7f8da560e5996d3e389cd63/networking/ntpd.c#L175

> It's true, this was a CVE in Rust and not a CVE in C++, but only because C++ doesn't regard the issue as a problem at all. The problem definitely exists in C++, but it's not acknowledged as a problem, let alone fixed.

Can you find a link that substantiates your claim? You're throwing out some heavy accusations here that don't seem to match reality at all.

Case in point, this was fixed in both major C++ libraries:

https://github.com/gcc-mirror/gcc/commit/ebf6175464768983a2d...

https://github.com/llvm/llvm-project/commit/4f67a909902d8ab9...

So what C++ community refused to regard this as an issue and refused to fix it? Where is your supporting evidence for your claims?

Somewhat related: In 2020 gcc bumped the requirement for bootstrapping to be a C++11 compiler [0]. Would have been fun to see the kernel finally adopt C++14 as the author suggested.

I don't think that Linus will allow this since he just commented that he will allow rust in drivers and major subsystems [1].

I do found it pretty funny that even Linus is also not writing any rust code, but is reading rust code.

I would have hoped see more answers or see something in here from actual kernel developers.

0: https://github.com/gcc-mirror/gcc/commit/5329b59a2e13dabbe20...

> They’re saying that a lot of the restrictions makes things much harder than other languages. Hence the general problem rust has where a lot of trivial tasks in other languages are extremely challenging.

Like what? So far the discussion has revolved around rewriting a linked list, which people generally shouldn't ever need to do because it's included in the standard lib for most languages. And it's a decidedly nontrivial task to do as well as the standard lib when you don't sacrifice runtime overhead to be able to handwave object lifecycle management.

- C++: https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-...

- Rust: https://doc.rust-lang.org/beta/src/alloc/collections/linked_...

> No need to get defensive, no one is arguing that rust doesn’t do a lot of things well.

That's literally what bsaul is arguing in another comment. :)

> You’re talking up getting a safe implementation in C, but what matters is “can I get the same level of safety with less complexity in any language”, and the answer is yes: Java and c# implementations of a thread safe linked list are trivial.

Less perceived complexity. In Java and C# you're delegating the responsibility of lifecycle management to garbage collectors. For small to medium scale web apps, the added complexity will be under the hood and you won't have to worry about it. For extreme use cases, the behavior and overhead of the garbage collector does became relevant.

If you factor in the code for the garbage collector that Java and C# depend on, the code complexity will tilt dramatically in favor of C++ or Rust.

However, it's going to be non-idiomatic to rewrite a garbage collector in Java or C# like it is to rewrite a linked list in Rust. If we consider the languages as they're actually used, rather than an academic scenario which mostly crops up when people expect the language to behave like C or Java, the comparison is a lot more favorable than you're framing it as.

> If I wanted I could do it in c++ though the complexity would be more than c# and Java it would be easier than rust.

You can certainly write a thread-safe linked list in C++, but then the enforcement of any assumptions you made about using it will be a manual burden on the user. This isn't just a design problem you can solve with more code - C++ is incapable of expressing the same restrictions as Rust, because doing so would break compatibility with C++ code and the language constructs needed to do so don't exist.

So it's somewhat apples and oranges here. Yes, you may have provided your team with a linked list, but it will either

GCC is also written in C++, and has had C++ deps since 2013:

https://github.com/gcc-mirror/gcc/blob/master/gcc/c/c-parser...

Compliers/Interpreters are also very commonly open source (here is the source code for a popular C compiler). That means you can even modify the compiler's code and change its behavior if you wanted to.

according to this commit, the story here seems to be much more interessting than I initially anticipated.

For a more detailed explanation, see [2]. (Also the inspiration for the above example,)

[1] https://en.m.wikipedia.org/wiki/Transitive_relation

[2] https://github.com/gcc-mirror/gcc/commit/50ddbd0282e06614b29...