ecma's comments

It's not clear to me if the author actually understands how staging works and how that affects the commands they suggest. They claim that stashing takes staged changes and then note that after stashing the working tree will be clean. That suggests the post is being dumbed down or the author is misunderstanding things.

Git guidance should almost always start with a brief introduction to the concepts you believe the audience doesn't know or fully understand. To begin with reset and not properly explain the index will just end up being confusing, especially with brief references to hard, soft and mixed resets later on!

Really? I'm not sure if this is bait or not, but 64b time_t extends the epoch over 200 billion years into the future. I figure we'll handle it in Linux 7.0 or 8.0 at the earliest :P

Thanks, I hate it. I'm a bit bemused about this bizarro case_N.h trickery. I'm also almost positive __COUNTER__ would be adequate and entirely remove the need for __LINE__ as suggested in the addendum which is likely to be quite large in any non-trivial source unit. I mean, something gcc this way comes I guess...

This puzzled me also. Perhaps it's been kicked down the road as an engineering problem and we'd end up with a hydrogen extraction system which is responsible for that part. We'd probably need to feed protons back in though...

The first paragraph of that question says 'address the possibility that a US company may have had spacecraft launched into orbit without the appropriate approval from the US government.'

This is a discussion of another offence against a different document and assumes the first offence against FCC regulations is valid. Be careful not to conflate the two, one causes the other.

I make heavy use of cardless cash via my bank's app when I need to visit an ATM. I haven't had my wallet with me for more than half an hour at a time this year.

This isn't wrong but I've got issues with some of the examples, especially the lack of a solution for #2 and #4.

#2 is referred to as an unsafe macro because of the multiple evaluation of its arguments. In some cases this is fine but it may need to be documented that the macro is unsafe for future users. It is also entirely possible to convert these macros into safe ones if you're willing/able to use GNU C extensions like typeof. The SEI CERT secure C wiki has a good reference for this at [0].

#3 presumes you want to compose functions but I'd suggest that by doing so you are writing bad C. Because of the lack of any type of side-band error reporting (exceptions etc) you must presume that your functions will always return a sane/non-error value. That's not a good assumption even for your own code and definitely not for the C library or any other libs. In addition, this is just another unsafe macro which could be made safe as above.

#4 doesn't explain the solution to the problem it poses which is annoying because it's the most important one IMO. There are a number of ways to make a multi-line macro safe for use in an unbraced expression body. My preferred way is to define the macro with a always false-post check while loop. e.g.

    #define MY_NAME_JEF(x) do{ \
        const char jef[] = "jef"; \
        printf("my name %s, not %s\n", jef, x); \
    }while(0)

Note the lack of a trailing semi-colon. This is because we expect the macro to be terminated with its own semi-colon. Stupid example but it gets the point across I suppose.

Check out the secure C wiki, it's full of gems which can help you avoid issues with macros, and much more.

[0] https://wiki.sei.cmu.edu/confluence/display/c/PRE31-C.+Avoid...

That's a K&R (Kernighan and Ritchie) style function declaration. Compilers still support it but the version you'd be more familiar with (ANSI C style) has been standard since at least the late 80s IIRC. ANSI C was standardised in 1989 but that process had been in progress for something like 5 years beforehand.

Did you genuinely find it difficult to parse the comma delimited representation near the bottom of the article? Just curious. It seemed very natural to me, a minor variation on British style thousand separators.

Not sure what you mean by a sub-session but my perusal suggests an entirely new conversation key is negotiated by current participants when those participants change. The spec doesn't say anything about requiring everyone to be online but I think it's implied. It may be that not everyone has to be online at the same time (which would just delay the negotiation IIUC) which is interesting but I wonder what would happen if an offline participate rejoins and doesn't get a full transcript from when they were last online with the carrier. Sounds entirely possible for an IRC/XMPP carrier with people not using bouncers.

TFA gives two very disparate examples of documentation failures (basic use of the dock vs service management and the init system). What does the author want to write? A book in the style of the For Dummies series? Something more like the Windows Internals books? Both, everything in between? Some of those surely already exist...

Well it's definitely possible unless I'm a moron (correct me if I am). If you have the primes up to √n you can find all primes up to n because everything else will be composite of the primes you know already. This is basically what TFA is doing. What I was suggesting is that it would be cool if you could avoid defining rules explicitly for (3n+6), (5n+10), etc and have them appear from some feedback loop where we go from a sequence of primes up to n, to n^2, to n^4...

CSS4, let's do it.

The highlighting and counting is cool but isn't this just colouring prime numbered elements (off by one) by knowing the primes up to √n? Bit of a circular problem! (:

It'd be pretty cool if CSS could define new rules based on counters and calculated properties. Then you might be able to bootstrap from something small like "2 is prime" and discover the rest of the primes up to n. Is this sort of wizardry possible?

Agreed, something they should have a plan for but not too worrying to see it with a few caveats at this stage.

I actually wrote a comment in response to loeg elsewhere in the thread and lost it by refreshing (and then lost interest, hah!) on the subject of conversion. I think there are some interesting problems around introducing a new FS and having to build "migrations" into it from the start. Migration feels like an expensive (in time/effort) word and I'd be concerned about issues coming up when you need to rewrite chunks of your NOVA FS because the per-CPU region has to become larger and everything else needs to shift along. It wouldn't need to be a full rewrite since only some data would need to be moved but it still seems clunky.

As mentioned in another comment, it seems like the solution being put forward is to oversubscribed the per-CPU data region for 256 CPUs but I wonder how long until that turns out to be a bad assumption. Who knows, maybe it doesn't matter. Maybe it's just out of scope for NOVA. One FS doesn't need to rule the world after all!

I would definitely expect a separate piece of hardware to be swappable without impacting on the rest of my machine. I can change/upgrade the CPU without breaking the north bridge or losing my RAID mapping so why should the data storage mechanism on my new NVMe device (which is where my mind leaps for NOVA) be any different?

What type of usage am I missing where losing/having to do an offline rebuild of your data would be acceptable during a hardware upgrade? NOVA seems to be aiming to address the recognised issue by overprovisioning (which I disagree with but such is life). I don't really understand your argument.

This is super interesting but

   due to the per-CPU inode table
   structure, it is impossible to
   move a NOVA filesystem from one
   system to another if the two
   machines do not have the same
   number of CPUs.

seems like a dealbreaker. What use is a FS if it isn't portable? At least it sounds like they're very aware of this issue.

I'd be very interested to see what they end up doing to make this behave better prior to upstream consideration. I wonder if a linked list journal of inode table changes (with space drawn from per-CPU freelists) would be safe/fast enough. That could be periodically coalesced and remapped to the NOVA device's non-CPU aware inode table.

I'll preface this by saying that I love radare2. It's my goto tool when I don't need to share work with IDA/Binja users and don't need to decompile something.

The radeco project is a train wreck. The current state of radeco-lib (unless it's been remediated in the last month) is disappointing and the only reason it compiles is because the last SoC student appears to have commented out the bindings that radeco is meant to use to get radeco-lib to do anything. I actually spent an evening attempting to undo that absurd series of commits but after getting a lot of the commented out back in place, not being a Rust programmer, hit roadblocks I did not understand regarding types and traits.

Unsolicited advice incoming. Please keep a close eye on your RSoC students this year. Their goals to achieve anything which they can present do not necessarily grok with the ongoing health of your project. I'd also love it if you would drop Rust and work with a more accessible language, at least while you work toward an initial version which spits out something resembling C code. Ultimately it's your project so do whatever you want but IMHO making everyone understand an inherently complex project in a language which is not straightforward is not the best option. Or at least add some documentation and make your lib and program build together...

Even if they have taken UI cues from elsewhere, I don't think this is a bad one. The search box is in the global context section and it's important to signal that it's going to behave in a non-global way. Having a flexible width text input or making it expand over the 'This Repository' hint (or whatever other context hint is there at the time) would be an easy solve for it being too small.

Part 2 is here: https://lwn.net/Articles/720550/

Can someone explain the actual use of sharing a terminal with someone while not being in person with them (in which case they could just watch you and shotgun the keyboard?)? I can't imagine watching someone else's terminal session without them talking about what they're doing and why would be particularly informative or help with onboarding. Maybe it's just one of those things that work for some people and not others?