ecma

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)

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.

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?

Just say that it's a signed log of the session. "Cryptographic proof" isn't necessarily incorrect but it has other connotations which don't make any sense here and make it sound like it's doing something it's not (think cryptanalysis or ZKPs).

why should that be so much harder for me?

And my friends*. My social group (25-30yo) is generally pretty morbid about the whole situation and most are resolved to wait for some sort of bubble to burst in Australia. Investing in other markets which are stable and easy to enter in the meantime.

It's interesting to read an American perspective from outside of the largest cities. I wonder if Australia's more spread out nature and few high density cities skew the problem more here.

This isn't just discretionary spending, it's total outflow of money earned (presumably after tax). They mentioned costs of housing, insurance and student debt repayments in the article as growth factors.

I'm dumbfounded finding this link on the top page. In news today, we found out that stream ciphers retain [zp]text length and unpadded form data is insecure. The nuance which seems to be missing in the understanding is that TLS confidentiality never intended (AFAIK) to include plaintext size. If it did, there would be a very interesting tradeoff around on-wire size and size masking. Even so, random per-message padding with known (e.g. protocol defined) bounds could be defeated by capturing multiple/many valid authentication packets or whatever the target is.

The only (but still important) lesson here is to pad critical form data as a site owner (assuming randomness doesn't buy you much) or have a good user password such that knowing the length doesn't make brute achievable. Even do a pre-hashing step on the client if you can guarantee it will happen and care to do so. I'm sure smarter people than me have given good advice about this somewhere.

The most frustrating thing about this is the presumption to name something like this. Bug names have always bugged me (hah) but this is a bit absurd. It doesn't even seem that clever :/

The Lagrangian answer covers this a bit more obviously by stating a solution which results in a closed curve of states around some equilibrium point(s) for certain initial variables. I think that matches your understanding of this as two peaks in a closed circuit.

Pretty uncharitable read of what I meant by "funny" really. Satire can be amusing without invalidating the referenced issue. Don't get so hung up on the issue that you can't laugh about things too.

Yes, see https://marc.info/?t=149028609000002&r=1&w=2 for some context. One of the other comments summarised why this is funny.

I'm assuming it's for jobs at FOSS shops, not necessarily shops which publish all their stuff with free software licenses. The latter sounds too niche although I'd love to see a board like that exist.

It's likely that this would push the tools toward being too opinionated. I spend a lot of time pushing little WIPs so I know where I am and my macros rely heavily on -m, e.g. I end up with a commit message like "WIP: don't merge these debugging lines" or "WIP: Tweak the IO timeout and profile". -m is also useful for making trivial commits, I don't use it for this often because it's easy to violate 50 chars but it's a perfectly valid use of the tool IMO.

Having been involved in several large scale (10s KLOC) source ports from Python 2 to 2/3 compat, I can say that IME it is trivial to make a mistake when handling these kind of changes. The complexity and regression risk is entirely dependent on the complexity of the codebase and I wouldn't be surprised if that factored fairly heavily into the Mercurial package teams' thought processes. The case for spending valuable people time on the harder problems in their codebase seems like a valid choice if the scale is large. TBH I wish I'd known about this a year ago...

It's also worth noting that the end goal may also not align with valid intermediate goals. I often found myself fretting about where to pivot to using a byte literal prefix, where to accept an unprefixed literal (to get pre-3.5 % formatting since the codebase used that in some places) and where I explicitly needed a unicode literal prefix (and dealing with the headache of what to do if we cared about 3.2 - the brief wasn't specific enough at first).

Just $0.02, I think everyone's experience, expectations and desire for purity will be different for porting efforts. It's worth noting that my porting work was supported by a large number of anally retentive unit and regression tests which made the effort much more frustrating but a heck of a lot more obvious when we messed it up!