wscott

The dedicated user isn't really required; it just expects that /home/linuxbrew/.linuxbrew exists. That can just be a symlink to your home directory. But yes, creating that symlink requires root on most systems. Brew itself doesn't require root or that pathname; you can put packages anywhere, but then many will have to be built from scratch since the pre-built packages don't work. And you need bubblewrap installed (which requires root) to use the sandbox, but again that is optional.

All that said, when you are running without a sandbox installing to a nonstandard location, not everything works consistently. I run this mode all the time. But it has been getting better.

You can hear the engineer in that second question. They hear a wild statistic pulled out of someone's ass and ask what is that sticking to the side?

That is normal on his blog. He is a brand that he has developed over many years, and he is constantly promoting that brand.

Yes, he has done a lot of good work in the past, but he has put as much effort into self-promotion and landed a series of interesting and well-paying gigs.

I can't blame him for that. It just makes me tired to watch.

The funny part is that the Tesla doesn't have a basic dumb cruise control. It only has "traffic-aware" cruise control which uses the cameras and doesn't use the new FSD code so it has lots of glitches and phantom braking and decides for itself what speed to use. My wife just wants to set the speed and have the car go that speed.

This kind of work is really valuable and much needed. There is also often a surprising amount of friction to making contributions to open source projects. This article did a good job and highlighting some of those difficulties and friction. But improvements to the official documentation is so much better than standalone blog posts to explain confusing concepts.

So, thank you Julia & Marie for persevering and making a solid contribution.

Indeed. When I entered "grandma's cookies" into the shared family instance is 'mealie' I was sure to include a copy of the "original" index card. (surely a copy) https://imgur.com/KMSuUhz

That card was has several fun comments and lots of history to my siblings who added to the crustiness of this card.

The original card I remember said to use lard or you can use margarine if you "haven't slaughtered a hog recently".

The recipe in mealie was modernized and tested more.

For reference here is the cppreference page the OP is trying to improve: https://cppreference.com/w/cpp/compiler_support.html

Personally I am not not sure the live search on this new page saves me time, but perhaps if you added the ability to only show missing features it could be useful. For example if I could pick that I am interested in c++23 and earlier and that I use gcc-14 and clang-16 it should list the features that won't work for me. That would be useful compared to trying to scan the full list.

Dataview can generate all of the data from Bases (and a whole lot more), but Bases is a lot easier to use as you can build queries in the GUI and the data comes out in nicely formatted table where you can edit the fields directly in the table rather than needing to load each data item one by one to make changes.

And still after using and making changes in the GUI the query is stored in a nicely formatted and editable YAML file.

Very small town in the midwest. The US is a big place and this is just one possible look.

The important thing to understand about why AVX512 is a big deal is not the width. AVX512 adds new instructions and new instruction encodings. They doubled the number of registers (16->32), and added mask registers that allow you to remove special cases at the end of loops when the array is not a multiple of the vector width. And there is piles for new permutation operations and integer operations that allow it to be useful in more cases.

The part Intel struggles with is that in many places if they had the 256-bit max width but all the new operations then they could build a machine that is faster than the 512-bit version. (assuming the same code was written for both vector widths) The reason is the ALUs could be faster and you could have more of them.

I was pleased to read such positive contagious excitement and someone who can still see the wonder of the American west. And excitement of trying new experiences.

On the website itself, "OS" "Included" and "Not Included" is strange. I don't see that I need "Not Included", unchecking "Included" should show you everything but instead it shows you nothing. I don't see the value of "no os included" verses a copy of Windows that I will overwrite.

So I would just have an "OS Included?" checkbox.

So, can we now write a plugin for Obsidian that syncs changes to Google Drive?

Reading the rest of the pricing page gives me the clear impression that it wasn't free initially and then changed it to free recently and the rest of the text on that page wasn't updated. If I am making donations why do I need to be reassured that I can have a refund if I don't like it?

https://www.globalenergyinstitute.org/average-electricity-re... us average: $0.18 Wyoming: < $0.09

yeah, cheap. But cold so a heat pump would still totally pay for itself.

I was immediately reminded of this Cosby standup: https://www.youtube.com/watch?v=qH_mHMgjcFY

Yeah, I know, I am not allowed to like anything Cosby anymore...

SPA?

That article gave an example of a "typical European floorplan". It did have multiple stairs they were just not normally accessible from all apartments. If you had some emergency-only provision to enter your neighbor's apartment and then bust their wall to access the apartment behind it, more than one egress would be possible. Some emergency doors where an alarm would sound perhaps? I come up with all kinds of problems with this, but that was my thoughts looking at that floorplan.

Design flaw. In IPFS every piece of data (even every chuck of large files) is globally indexable on the same namespace. You need namespaces and/or a path to restrict yourself to just the subset of peers that might actually have the data.

It would be possible to add a layer on top of IPFS to include some context with every hash lookup so the search can be more focused, but the original design just assumed it was ok to do a log2 search for every chunk.

I was confused by the comments here. Surely someone is going to post the Technology Connections video on the toaster. I see you did it indirectly. That video is great.

15min? try 50.

I always think I will watch just 10-15 and end up watching the whole thing and then wonder why learning about a crappy refrigerator was so interesting.

read cppreference.com

But the sort answer is all the other operators are automatically generated from that one if it is defined. So it makes the code simpler. And for many types <=> isn't much more complicated than the others

I was surprised to see `fmt/format.h` on that list, but I do have to admit that the objections seem reasonable. Perhaps because he(?) mentioned wanting to use -O0. Template code is almost useless without optimization. If -O0 is needed then I am surprised that all of the STL doesn't get pitched.

Ok, I was also surprised to see co-routines on the nice list, but I don't have direct experience there. I normally see complaints about them. I would like them to be good because some code is easier to express that way.

BitKeeper was able to merge that successfully by looking at the revision history and seeing that the changes involved just those lines. If one of them added a line between the two being changed then it would still be a conflict.

I spent a year looking at interesting merges (and commits fixing bad merges) in the Linux kernel and making a catalog of interesting cases before writing 'smerge' for BitKeeper.

It is impossible to make a perfect merge tool, but we can do a lot better than diff3.

The "diff3" style looks like this:

           <<<<<<< HEAD
                sc = sccs_init(file, INIT_NOCKSUM|INIT_SAVEPROJ, s->proj);
                assert(HASGRAPH(sc));
                sccs_sdelta(sc, sccs_ino(sc), file);
           ||||||| merged common ancestors
                sc = sccs_init(file, INIT_NOCKSUM|INIT_SAVEPROJ, s->proj);
                assert(sc->tree);
                sccs_sdelta(sc, sc->tree, file);
           =======
                sc = sccs_init(file, INIT_NOCKSUM|INIT_SAVEPROJ, p);
                assert(sc->tree);
                sccs_sdelta(sc, sc->tree, file);
           >>>>>>> c4892343......

That contains the same information, but you have to parse it yourself and it is not nearly as fast to see what changed.

However, it is faster to edit since you don't need to remove the diff markers.

The piece of BitKeeper I wish people would steal is the smerge gca conflict format. See https://www.bitkeeper.org/man/smerge.html Example:

               <<<<<<< local slib.c 1.642.1.6 vs 1.645
                    sc = sccs_init(file, INIT_NOCKSUM|INIT_SAVEPROJ, s->proj);
               -    assert(sc->tree);
               -    sccs_sdelta(sc, sc->tree, file);
               +    assert(HASGRAPH(sc));
               +    sccs_sdelta(sc, sccs_ino(sc), file);
               <<<<<<< remote slib.c 1.642.1.6 vs 1.642.2.1
               -    sc = sccs_init(file, INIT_NOCKSUM|INIT_SAVEPROJ, s->proj);
               +    sc = sccs_init(file, INIT_NOCKSUM|INIT_SAVEPROJ, p);
                    assert(sc->tree);
                    sccs_sdelta(sc, sc->tree, file);
               >>>>>>>

Here we have a code conflict and rather than showing you what the file looks like on the two sides it shows you what was changed on both sides relative to the GCA. So we get two unified diffs. The local side made this edit, while on the remote side we had that edit. Then it is obvious how to resolve the conflict without losing a change.

This works for the cris-cross case because that GCA is really a set of common revisions merged together.