WorldMaker

Profiles and Containers are a bit of a peanut butter and jelly situation. There's uses for both separately, there's a strong intersection of what they do well that you use either for (topping a slice of toast), and then together they also can make a beautiful sandwich.

Profiles form very different windows. You can decorate them to make them obvious at a glance which Profile is which. Up until recent Profile improvements, switching between them and managing them used to be a lot of work, including managing which one was the default for links from other applications.

Containers are tabs in a shared window. They get marked with a subtle color bar (the colors you choose for each container) and that's mostly it, they otherwise "blend in" to the same shared window. Reopening tabs in a different container is easy. Opening new tabs in a different container is easy. Containers share a few more things than Profiles do (but are still isolated in important ways such as cookies).

I have every site that needs my Google account pinned to always open in a specific container. The boundary is hard where I need it (the privacy protections) but soft for make workflows easier. If I find a YouTube embed in the wild somewhere that needs a login for one of the many restrictive reasons some do, I just click the normal link (or middle click for new tab) and YouTube opens in my Google container automatically. I don't need to copy paste between windows (or use Sync's sometimes slow tab sync engine). If I accidental hit a "log in with Google" button it opens up in the Google container and I know something is wrong because I don't expect random other websites in that container. (Relatedly, I finally installed uBlock Origin not to get rid of ads, but solely to get rid of that awful annoying content-obscuring popup for Google login on sites like Medium. I feel like there should be far more backlash on Google for being a bad actor doing that.)

I also use Profiles for alternate identities, things where a very different looking window are helpful to know I'm in the right place. Containers and Profiles are useful together.

This has been one of my use cases for the Multi-Account Containers extension for some time now. It's actually such a motivating use case that one of Firefox explorations into a "simpler" focused UX alternative to the Multi-Account Container extension is called "Facebook Container" and does only that, isolate Facebook, specifically into its own Container.

As noted, it can't defeat all forms of device fingerprinting, but it does defeat cookie tracking.

They are definitely orthogonal use cases. I find I prefer Profiles for different accounts/identities more than Containers (including profiles being very different windows of Firefox reducing confusion of which identity I'm looking at). Containers I like using for those hard privacy walls of pinned sites to avoid more "personalized" ads. But the flexibility exists to mix and match and use Containers and Profiles for either/both use cases. I don't think there's a "wrong way" to use them, just your personal preferred way.

But also it could have been found in the wild in C/C++ code, which both had no "native" Boolean type until surprisingly recently (C++17 and C23! as in 2017 and 2023 standards, irrespectively) so Bool is very much a possible real name and not part of the hyperbole.

There is a possibility space there. Some transistors are "naturally" ternary (which we use today for things like binary error correction). Also the Soviet Union went down the rabbit hole of ternary computers and programming languages, which is fascinating history to explore.

The interesting questions are if enough LLMs use ternary enough and for long enough into the future to make investments in ternary hardware worth it. Ternary hardware is probably less general purpose than the modern GPU design that is being used for LLMs today and the crossover of "general purpose floating point matrix math engine" for graphics as well as LLMs a useful one, particularly because we know the graphics revenue models pretty well (and gamers are pretty upset at GPU pricing right now because of LLM demand).

That is a possible reading, especially given the way the Empire's xenophobia manifests, if you assume all humans are culturally homogeneous in Star Wars, but I think the movies are somewhat clear that humans are culturally diverse. The human cultures in Tatooine seem very different to Alderaan or Naboo, for two somewhat specific notes in the films. The Imperial accent often being more "British" (RP) implies cultural differences with the periphery that at least mirror somewhat, say, the differences between Britain and much of its former Empire.

The Galactic Empire showing a clear citizenship "caste" favoritism of Citizen/Officer Humans, General Humans, Cloned Humans, Aliens, and then Droids, but also working with all of those at the same time in its military efforts (there are a few aliens in the Empire's military, there are a lot of droids) does seem imperial in the way the article suggests, especially because that core of clear "Citizen/Officer Humans" seems so relatively small versus they armies they command of all the other types.

You can organize the same system in terms of observers and subscribers.

Also, the differences between "hot" and "cold" observers and the use of schedulers.

I like that about the observable pattern that while hot versus cold is confusing, it is generally "explicit" in the dance of observers/subscribers. I also tend to like the way that observable schedulers and scheduling operators are often usefully explicit in halting computations while still being largely automated in the time domain.

Certainly my gut instinct with this specific library is seeing if the stuff being done with it might be a cleaner fit in something like RxOcaml, but I realize I'm in something of a minority in preferring explicit observable operators over implicit "computation signals".

I've seen this kind of thing fail in so many ways just as a user with a custom domain. Someone adds my real email (the custom domain) to a Google invite and my primary Google Account uses its own email (a Gmail account) that is in no way my primary email address and Google gets confused and won't let me access the thing sent to my real email because I'm trying to access it from my Google Account. (Plus additional variations where my custom domain was briefly hosted on what today is called Google Workspace and some things still seem to be misconfigured to point to shutdown accounts for my real primary address still apparently ghosts in Google Workspace.)

That's eternally a frustrating experience. It ranks among the reasons I groan every time someone asks if we can meet in Google Meeting instead of other options.

That's just dealing with one large giant of a company who you would think if anyone would have the software resources to truly untangle email addresses from account assumptions, they would have more than enough resources available.

Lots of little papercuts like that exist everywhere else. I have multiple accounts with various "Pledge Managers" because I gave Kickstarter a specific filtered address but still tend to respond to surveys and other things sent more directly to me with my primary email address. "For my convenience" most of these "Pledge Managers" tie their accounts to whatever email address they get from a Kickstarter export spreadsheet and then assume that each email address is 1:1 useful for marking an account as mine. It's often easier to juggle a bunch of reminder notes in my Password Manager which campaign is with which account with which "Pledge Manager" than to unify accounts. It becomes the opposite of convenience.

I've seen the same thing happen with + addresses, not just custom addresses at custom domain addresses. Add a + to a signup to get autofiltering when you sign up for a service and most services see `accountname+filter@gmail.com` as a different email address than `accountname@gmail.com`. Which is the correct behavior because `+` filtering is a convention not a guarantee/standard. But it again adds complexity in these sorts of "auto-invites" when you are trying to auto-correlate based on specific email address.

It seems important to me to not assume that the address an invite is delivered to is the primary address for that person nor the intended address for their account with you. It may be useful to associate that delivered address automatically as a "secondary" address in some cases, but to insist that it be the primary on the account that results from the invite is a papercut friction for at least some of your potential users.

The Galactic Empire as shown in the movies seems to have a very small core, almost all of the movies are set in its periphery rather than its central core. Tatooine is paying taxes to the Empire and subject to its troops, but doesn't seem at risk of being culturally seen as "Imperial". Alderaan wasn't subservient enough as a culture and is subject to genocide. Endor was certainly never truly imperial.

It's almost harder to define what the core of the Galactic Empire even is. We are told Coruscant is core to the Empire, but the glimpses of it in the Old Republic era certainly implied it was a very diverse place and we aren't really shown Coruscant in the films of the height of the Galactic Empire. To some extent the only truly "core worlds" and "core peoples" that we see in the films are the Star Destroyers and Deathstars, the military demanding taxes from every planet they pass.

The Empire may not be taking full advantage of the military power of a diverse people because of the over-reliance on clones and treating draftees as if they were clones when the clones start to run out, but beyond that it certainly seems to resonate like an Empire in the way this article describes an Empire to me.

Surely if the machine you go to for answers regularly makes things up you would just stop using it? Perhaps people have to be burned by something really bad personally before they realise the limitations? LLMs are very convincing and persuasive.

The last sentence reflects a lot of my feelings on the first question. LLMs have a sort of weaponized take on the ELIZA Effect. The better their memory the better they are at playing to human social desires to be listened to in an active conversation. At some point it stops mattering if the answers are right when the answers feel right, but really, like ELIZA back in the day, so much of what makes it seem special is just reflecting your own writing back at you in a convincing and persuasive way.

I think the laws we aren't worried enough about needing yet are digital estate laws, too. If I build a massive library in the real world there's no question it's a part of my estate plan for a will and is inheritable by family (or other persons I choose). I've got a massive Steam library. What happens when I pass? Steam's EULA implies that there are not necessarily survivorship rights, the account is mine personally and may shut down or disappear when I pass away. Almost every digital service EULA has and must have logic of that sort to protect itself/simplify account ownership as a concept.

We've got pragmatic answers of password sharing and Steam is one of the better example in the current moment because among other things it has some Family Sharing support. But I can't go to my lawyer and ask for a list of passwords (and device PINs and passkey details etc) to be attached to my will with the explicit idea of divvying up parts of my digital library to different relatives. Lawyers don't really want to discuss detailed digital estate planning today because it isn't allowed by these service EULAs and because they don't want to have to fine tooth comb every single possible service EULA. It's a catch-22 that probably needs real legislation or very expensive very public court cases or both to help push it to the forefront of people's minds (and make it enough of a priority that service EULAs have to adapt).

Potentially viewable as better than OpenJDK and Oracle (and OracleJDK) from what I've seen. A lot of .NET governance moved to the Dotnet Foundation which is built along the lines of things like the Linux Foundation. Microsoft is the major contributor to .NET and a major sponsor of the Dotnet Foundation, but most of their contributions are still flow through the Foundation legal/governance structure and subject to the same governance as anyone else today. .NET is almost entirely planned and developed openly on GitHub including things like meeting minutes for all in person meetings.

The JSON source generators are quite good, and a small performance boost worth considering even when not planning for AOT. The logging and RegEx source generators aren't even for AOT but for improving debugging tools [1] and performance.

Everyone should be exploring source generators already whether or not they expect to try out AOT.

[1] Debugging source generated RegExes is a dream, including being able to breakpoint inside a RegEx in the .g.cs file should you need to trying to get a tricky RegEx right. The code generated by the RegEx Source Generator is incredibly readable and includes great comments that explain what the RegEx does, step by step. Those comments show up as documentation comments on the partial .cs file side once the file is generated and can be used to double check that the RegEx you wrote matches what you expect it to do as you write/update the RegEx and the source gets regenerated (which happens pretty fast).

To be fair, VB.NET itself also thought itself the natural replacement/direct continuation. Its compiler version started at 7.

It sounds like they didn't reuse the enum keyword for this for the most backwards compatibility and to avoid confusion. Your example enum is an `int` today. Either you break existing code expecting an `int` sized thing or you need additional syntax and can't use the "clean" form that you are hoping for.

The null patterns predate these unions and the relevant section of the documentation is showing that you can use nullable unions, not that you have to or should use them. Other examples also show a fully closed Result<T, E> type that yeah would be great for projects hoping to eliminate more nullable code.

Use merge commits does not mean using "merge workflows with long running branches".

"Merge early and often" is just as useful of a concept as "rebase often". The workflow is often exactly the same. The only real difference is extra commits to mark the merge points, and the extra commits are mostly just a UI issue when code reviewing.

A good PR UI (and GitHub isn't always, but it tries) doesn't show commits brought in from the base branch. (I think GitHub would have a simpler thing if it defaulted to a simpler `--first-parent` approach (rather than trying to math from the base branch) with an option to drill down, but I'm not a a GitHub UX designer.

Don't confuse the workflow with the DAG shape, that is more aesthetic than not.

I've seen some really bad trainwreck merges in rebase heavy workflows, too. (Unwinding them is awful.) Rebases create just as many merge conflicts as merge commits do [0], but rebases don't save the evidence for them. Just because the evidence was lost of them doesn't mean the merge conflict markers were never there.

Any time you integrate two branches, no matter how long running or short running, you have possible merge conflicts. Like I said, I prefer keeping that integration log as a tangible source control artifact. I understand how many people don't care for it. But don't mistake it for solely an aesthetic choice. Merge conflicts are a necessary part of source control and sweeping them under the rug is one way with dealing with them, but in my opinion not exactly the healthiest way.

[0] ETA: Merge conflicts are not just a technical issue, but a communications and coordination issue. Software development is a social activity and as long as it is a social activity it creates merge conflicts.

I've had to deep regression analysis and archeology to make sure that regressions aren't recurring or stop recurring, because regressions can recur. An engineer that maybe read the wrong advice and got too eager in using a rerere cache only for it to cache bad regressions. Another engineer that missed a memo somewhere and regularly mismerges a feature thinking that work in progress is actually legacy code. A third engineer that accidentally committed temporary code used for testing that was more obvious looking at the exact commit where it was made than the PR it was made in.

There are so many such scenarios where more information is better. If you've got a good PR tool it might save caches of those branches pre-squash some amount of time and you can do some of that sort of archeology in your PR tool, but even GitHub will sometimes garbage collect PR commits from deleted branches eventually.

The git DAG being a two-dimensional data structure is a useful tool. I find that I want to preserve as much information as possible, including using `git merge --no-ff` in additional scenarios that many use `git rebase` for because I don't know when I will need that (integration or testing or process change) information, but if I find that I need that information it is good to have it.

It's related to the same reason we don't throw out commit messages on ancient commits. In my experience, no matter how outdated that information gets, you are going to find surprising reasons to need it. Source control isn't just about recent history, even if that is most of your day-to-day needs. Sometimes you do need to revisit the past and you don't always know exactly what you will need from that past until you do need that information search.

The point is your ability to find needles in a haystack increases. A PR often is bigger than a 10-line change, but is often made up of smaller 10-line changes.

The ability to drill down with a second `git bisect` run (now with a known base and end commit, and even the ability to again use `--first-parent` to ignore merges inside the PR commit range) into the original contents of the PR is the ability to automate finding your needle in a 10-line change with its own git commit message and its context in the original conversation flow in the original PR.

That's a powerful ability.

Sure, you can probably comb the complete 100 or 1000 or 10,000 line PR to find the exact lines that caused that regression, you've narrowed down already to one useful haystack, but it's nice to have an optional second layer to break your haystacks down further sometimes.

(Especially if it turns out to be a regression from a merge commit inside that PR. Accidental bad merges happen all the time. Spotting them is hard sometimes. Spotting them after a rebase/squash happened is sometimes impossible because there's no unique record of the conflict resolutions unlike with a merge commit.)

Fun fact, you can also automate more of that existing workflow with the rebase interactive TODO list. Roughly something like:

    pick $ACOMMIT1
    edit $ABMIXEDCOMMIT # split out A parts
    pick $ACOMMIT2
    exec make test # test everything compiles
    update-ref bugfix/A
    exec git switch --detach main # new branch point
    pick $BCOMMIT1
    edit $ABMIXEDCOMMIT # split out B parts
    pick $BCOMMIT2
    exec make test
    update-ref bugfix/B
    exec git merge bugfix/A
    pick $FOLLOWUPCOMMIT
    exec make test
    update-ref intermingled-branch # or bugfix/C

If that's the case, is there a way to get `git rebase` to have the same behavior? I've got decades of `git rebase` burned into my fingers at this point.

One of the GitHub blog posts of git changelog highlights implied that this new power of `git history` was certainly under discussion for a possible feature addition to `git rebase` but it is partly still a discussion because it is a higher-level function and if the goal is to keep `git history` the "high level" and `git rebase` the "low level" then such features probably make sense to remain only in `git history` for now.

It also sounds like there are camps thinking `git history` is only the learning path to make a better `git rebase` UX and eventually the commands will reconverge somehow.

Both sides of that conversation sound worth exploring to me, and I'm curious to hear how that conversation continues.

A PR is an atomic thing, but at a higher level. It's an integration point. Merge commits are a great representation of an integration point. `git log --first-parent` gives you an integration log. Without `--first-parent` you have a "conversation log" with details about how PRs were formed.

`git bisect --first-parent` lets you start with your integration points (your PR merge commits), and because presumably you have Continuous Integration and make sure integrations points build and test successfully that should be a rather quick discovery run, and then when you discover the PR that introduced the issue, you have an opportunity to drill down into the even smaller specific change inside that PR that introduced the issue.

Merge commits are a navigation tool and an integration log. It seems useful to me to prefer them over rebases and squashes.

The implication seems to be that `git history` is the higher level, safer `git rebase` for common scenarios. If you are already comfortable with `git rebase` you might just keep using it and never need `git history`. If you are learning git as a junior developer (or teaching/mentoring a junior developer on it) `git history` becomes a good, safe stepping stone for a handful of common tasks.

I've been in workplaces where I wished I could disable `git rebase` for all junior developers because they kept learning its footguns faster than its capabilities. A stepping stone seems like a really good idea to me.

One interesting new twist in the Windows 11 removes extension points/makes extension points harder to use is first class built-in git version control integration: https://learn.microsoft.com/en-us/windows/advanced-settings/...

It is not as convenient and it is not yet as capable as things like Tortoise have been in the past, but it is still an interesting thing to see paths explored in Windows like that, even if somewhat hidden in "Advanced Settings".

git tags are more lightweight than they seem. It's why the UX defaults to not sharing tags, with the idea that you may need/want local-only tags. They also share the same "namespace" that you could have tags like `myname/some-personal-tag`. (I've used `project-name/v1.2.3` style tags in monorepos rather than solitary versioning the entire repo.)

`git tag -d` deletes tags and `git tag -f` moves them (forces them to change).

For the most part whether you prefer a branch or a tag for temporary marks is an aesthetic choice, though the twist is maybe using annotated tags. The annotated tag allows you to leave a commit message for yourself why you made the temporary tag in a way that you can review later. Just like optionally adding a stash message (which also reflects why stashes work under the hood more like tags than like branches).

Yes, `git switch` and `git restore` are both marked stable now and have relatively clean UX. It can be worth reskilling out of `git checkout` habits and into these two separate commands.

To my understanding today it depends on the JS engine and more importantly what JIT stage that code is in. JITs optimize const/let in ways that they can't optimize var now.

Which is to say that if someone tells you that you should in general never use const/let for "performance" they are probably wrong, but yes there probably are still edge cases and microbenchmarks that make var look faster on some engines.

I watched a couple battles at the most time dilation over the shoulders of college friends. They would have entire days of needing having EVE open on their laptop through every class and that gave me enough of an understanding to realize I probably wouldn't enjoy that.

I got a lot out of Empires of Eve which tells a lot of the big stories of Eve in a very approachable multiple volumes of history books: https://www.empiresofeve.com/

The author put so much amazing work into those, including interviewing people that were there for many of those battles and compiling great visualizations to help make the battles easier to read.

More than one Turing Complete VM inside the font renderer stack, at that. One of the biggest recurring CVE generators in both Windows and Macintosh was 1984's legacy of the Adobe Type 1 font format [1]. Everyone had to license it for backward compatibility with PostScript documents. It shared enough Turing completeness with PostScript despite being a subset.

Both Windows and Macintosh spent years trying to isolate type rendering from kernel operations specifically because of Adobe Type 1's legacy alone, including the fact that it was an ugly vendored 3rd party spaghetti. IIRC, both Apple and Microsoft ended up paying Adobe tons of money to rewrite their Type 1 Font Manager code from scratch rather than keep paying Adobe to write that code. (TTF and OpenType were also both somewhat direct responses to Type 1's legacy and mistakes.)

[1] https://en.wikipedia.org/wiki/PostScript_fonts

Yet the remake of Halo: Combat Evolved is getting a ton of attention from the fanbase and broader gaming community. If the next Halo is good, that fanbase will come back around.

The fanbase already has the Master Chief Collection. The remake seems doomed to fumble worse than MCC's notorious launch issues and it should be obvious to anyone looking at the project on paper. MCC was a team with ownership trying to learn the ins and outs of decades of work on the Slipspace engine to recreate each step of the Halo journey in an upgraded/consolidated form of its own engine. The new remake is a mostly outsourced team that basically owns nothing trying to recreate Halo mechanics in UE5 with the help of LLMs and other AI upscalers. That's nothing like what the real fans should want for the franchise. It reeks of corporate mismanagement misunderstanding what IP is for. It also reeks as a slap in the face for the hard work on the MCC (and yeah 5 and Infinite, fumbles and all).