thrwaeasddsaf

I didn't. I've a hunch that it's a very deep rabbit hole, which means understanding and fixing those crashes is going to be a significant time investment.

I can't bill a customer for that time, and my boss won't be able to pay my salary if I spend weeks studying and fixing broken old debuggers instead of doing the work a customer pays for.

Either way, the debugging experience without something like rr sucks hard when it comes to heavily multi-threaded, asynchronous, event-driven systems. So even if gdb didn't crash, its usefulness is very limited compared to simple tracing.

"AArch32 support is WONTFIX, as far as we are concerned. Even if implementing rr on 32 bit ARM were possible I don't think anybody cares about it at this point."

So does rr work on arm yet? Nope. Back to good old printf.

On a realated note, the number of times I've had gdb crash on arm is so ridiculous that I don't really bother with it unless I absolutely have to.

Sounds like this is a new term for "your website hosted on your domain."

Do you have a good one in mind? All the open source tools I've tried are MISRAble

People are talking about debugging because debugging needs to be possible.

If you blow the stack in a debug build, your application fucking crashes. That makes debug builds useless and can make debugging some problems very difficult. Therefore we need a mechanism that guarantees the code doesn't blow the stack in debug builds either. "Only optimized production builds are executable" is not the path you want to go if it's avoidable.

If you don't have markup to enforce TCO in every build, some build will be broken or needs to use a different code path altogether to avoid such breakage.

> What's the argument for building in debug mode

Sometimes optimized binaries are just a nightmare to debug. Symbols do not help.

Which tools patch C's shortcomings?

What's the problem with that? You don't have to read these people's posts if you don't like them, just like I don't have to watch conspiracy bullshit on youtube. Maybe I want to read these folks' posts! The platform shouldn't make that decision for me.

With well designed communication tools, you don't need moderators to decide what kind of content you see. You and your immediate network will be your own moderators by implicit action and inaction (and if everything is designed right, you can also take explicit action to e.g. drop that flat earth shit from your feed that shows up because your best friend keeps reading and upvoting it).

This is exactly how the real world works too. I choose who to chat and hang out with, I don't need to call cops to remove marketers and idiots from the world for me.

> One has to stop somewhere, and this article decided to stop at C, as opposed to assembly.

As soon as you mention the stack, you've gone beyond C and started talking about something that is not C.

My work laptop has 0.5T SSD and it's 90% full. Turns out VMs, large repos, and OS projects are big. I know there are some large docker images too.

I don't know about you but I work on a laptop, and I work on multiple projects, and each project might use dozens of containers for builds, testing, releases, etcetra. If every container were a gigabyte in size, majority of the laptop's internal storage would be wasted on them, nevermind the time wasted pushing and pulling updates.

Maybe they should just kick out all those hobo beggars from red hat, intel, oracle, etc. and get some well compensated professionals on board.

> More difficult to read

Subjective, and I do not find it more difficult to read. On the contrary, I often find shorter and denser expressions (especially around obligatory fluff that doesn't actually do much) to improve readability and make it easier to focus on the interesting part.

> more difficult to edit

Subjective, and I do not find it more difficult to edit.

In general, as long as you're not using a magnetized needle as your editor, creating new declarations or moving declarators around shouldn't be a challenge. It is trivial.

Nevertheless, if we want to consider the relative difficulty of various trivial edits, it can go both ways as far as multiple declarators per line are concerned. It can be easier to edit when you have a set of related variables and you need to change the type once. If you split them on a bunch of lines, you need to remember to change every line, which is more work and larger diffs. Oh the horror...

> but the worst thing is how difficult it makes diffing code.

I agree that it can make diffs a little harder to read but I have not found that to be a big issue in practice (having worked on both styles of code professionally and as a hobby for more than two decades).

If diffs were such a major concern, then we probably should adopt an assembly-style syntax with one instruction per line and no nested indentation. That would keep lines inherently short, so you don't have to locate and read the small change on a longer line. And you'd never have to pick small changes from a large hunk that is large mainly due to changed indentation. (At this point, I'd like to make a point about how splitting everything to more and more lines isn't always good for readability but I think I made that point already.)

By the way, you might wanna try out one of these modern diff tools that can hilight the actual change on a diff line.

> You should try using some kind of code versioning, git is a popular choice.

I can assure you that "multiple variables per declaration" have never been a problem for me with git. Coincidentally, the source code of git itself does have multiple declarations per line so looks like it wasn't a big problem for the authors of git either. (Obligatory example: https://github.com/git/git/blob/89b43f80a514aee58b662ad606e6...)

I know SEI well.

I have worked on projects where linters enforce that style, and I hate it.

You can read their justification: a programmer or code reviewer might mistakenly believe that the two variables src and c are declared as char *.

"A programmer might not know the syntax" is as stupid a justification for enforcing these rules as "a reader might not be able to read long sentences correctly" is for enforcing a stupid rule over text written in a natural language. I'm sorry that you failed to see the analogy.

They also just drop a statement like "declaring no more than one variable per declaration can make code easier to read and eliminate confusion." I can drop my opinion too: "declaring more than one variable per declaration can make code easier to read and eliminate confusion." It can also make the code shorter and easier to scan & edit.

And I think analogies involving natural language are more relevant than you think.

I would rather read "U, V, and W are phases" than "U is a phase. V is a phase. W is a phase." It's the same goddamn thing, we're declaring things (and optionally initializing them).

I wish we could talk about style in objective terms, not just opinion. Opinions are kinda stupid. Here's my opinion: https://news.ycombinator.com/item?id=26790701 (actually that's just a faux opinion to make a point, but you get the point)

And if there are no objective facts, then maybe we could just stop calling other peoples' preferred style nasty and "bad habits" as if it were objective.

Sorry

I

can't

read

your

comment,

could

you

split

your

words

into

separate

paragraphs?

There is nothing wrong with multiple declarations.

> 3. Really bad work-life balance in general. When busy and everyone's WFH, boundary between work and life really got blurred. There's nothing like "gotta go, chat tomorrow" stuff.

You can only blame yourself for that. When I'm done working for the day, I log out, lock my screen and walk out of the room. And if the time to go happens in the middle of a chat, then so be it. My boss can tell me he's gotta go, and I can tell him I've gotta go, and that's exactly what we do. There is no blurring of work and life because I don't blur them.

If you think scope creep is an inevitable consequence of not making a protocol non-extensible, I have a thousand RFCs to show you..

Really you just need to outline some goals and rules and have the right people at the top calling the shots. Plenty of things are designed and developed with a conservative mindset where adding new features has to be very carefully justified.

I'd also like to point out that it's worthwhile to think of the complexity of all the systems you require, and not just one protocol/document format. Gemini may be simple, but when it is too simple, you will need a different protocol or format. So now you have two, with somewhat overlapping functionality that you can't merge if you insist on keeping everything absolutely minimalist. Only two isn't going to be enough.. so if you're willing to do what you do, complexity is inevitable, whether it is in a single protocol or spread across a clusterfuck of dozens of protocols.

Again, it is good engineering and good abstraction to find a solution that gives a lot of bang for buck, i.e. is reasonably simple yet covers multiple bases.

I haven't got much sources for you but what I've picked up over the years: a lot of OpenBSD's security is just old fashioned manual code review and audits, and there are not enough eyeballs. Someone like Ilja van Sprundel can go in the source code and find a bunch of issues without too much trouble [1]. I don't see any concentrated efforts to improve the status quo (where's formal methods, where's automated fuzzing, where are initiatives to employ more safe programming languages, static analysis, etc.). And while OpenBSD pride themselves on their mitigations, they aren't exactly state of the art and some of the more recent stuff (like trying to eliminate ROP gadgets) seems just futile. The biggest thing OpenBSD did with mitigations was enabling them by default for the base system and ports. What does anyone remember OpenBSD for in 2010-2020? Pledge, probably. That's a nice thing but more for containing the damage than actually making stuff secure in the first place.

https://www.csoonline.com/article/3250653/is-the-bsd-os-dyin...

My concern (and the concern of many others, I think) is that if OpenBSD suddenly got enough attention from the wider security community, including people who actively look for holes that can be exploited, there'd be plenty of important stuff found. Until then, these issues sit quietly waiting for a malicious party to discover them. There's quite some fanfare for OpenBSD, but how many of you are actively auditing the code? I'm subscribed to cvs@ and tech@ and I read them daily and I just don't see much contribution at all from outsiders. And when I do see it, it's mostly stuff like fixing typos or amending man pages. All the commits that change code with security implications tend to come from the core developers, and are reviewed by a handful of people at best. And I have seen some obviously broken stuff slip through.

Gemini may unfortunately be the best hope in terms of what gets adoption but I feel like it swings way too far in the other direction. I see this a lot: your choices are either massively obese or minimalist to a fault. Where is the middle ground? From an engineering perspective, I think that is the most interesting area: designing something that is small and simple yet surprisingly capable. That is also what I want from software as a user.

I think Gemini goes in the "weekend project" category whereas a modern browser is more like hundreds of man-years. I evaluated Gemini, wanted to like it, almost like it, but I think it just doesn't allow me to do what I want to do. It is too simple.

I think it should be possible to design something that is more flexible, yet for which a competent programmer can write a basic client implementation in a few weekends (with some features missing but the client still being entirely usable), make it feature-complete in an additional dozen weekends or so, and also add & finish all the extras and fluff and polish over the remaining year. From there on it's maintenance and bugfixes and minor features which can be worked on as a hobby by a small group without having to devote all their lives to it. These projects are also small enough that if someone's not happy, they can fork and customize (and still be able to "keep up" with whatever developments might happen in terms of standardised functionality).