modderation

I'm early on in my Kubernetes journey and have opted to focus on Talos. Would you be able to share a bit more about the issues and limitations you encountered?

You can always order the pro parts along with a regular display from the regular Framework 13. Some assembly required, but the bits are all interchangeable, so you can have your non-touch display.

Alternatively, you can also "not touch" the touch display :)

Intel got a lot of attention during the keynote, but the Ryzen AI 300 series mainboards are available if you want them. It's one of the first few choices in the configuration flow.

It's either a a Career Limiting Event, or a Career Learning event.

In the case of a Learning event, you keep your job, and take the time to make the environment more resilient to this kind of issue.

In the case of a Limiting event, you lose your job, and get hired somewhere else for significantly better pay, and make the new environment more resilient to this kind of issue.

Hopefully the Wikimedia foundation is the former.

As a guess, large-scale volumetric or photogrammetric "datasets" could be difficult to stream over lesser interconnects.

Can this be generalized into a higher-level metalanguage? Notably, one called FURTRAN with broader support for other fuzzy creatures?

Probably with KubeVirt.

Some instructions for Windows 11: https://kubevirt.io/2022/KubeVirt-installing_Microsoft_Windo...

Ceph storage uses a hierarchical consistent hashing scheme called "CRUSH" to handle hierarchical data placement and replication across failure domains. Given an object ID, its location can be calculated, and the expected service queried.

As a side effect, it's possible to define a logical topology that reflects the physical layout, spreading data across hosts, racks, or by other arbitrary criteria. Things are exactly where you expect them to be, and there's very little searching involved. Combined with a consistent view of the cluster state, this avoids the need for centralized lookups.

The original paper is a surprisingly short read: https://ceph.com/assets/pdfs/weil-crush-sc06.pdf DOI: 10.1109/SC.2006.19

Depends on the setup, but programmatic access to a Gmail account that's used for admin purposes would allow for hijacking via key/password exfiltration of anything in the mailbox, sending unattended approvals, and autonomous conversations with third parties that aren't on the lookout for impersonation. In the average case, the address book would probably get scraped and the account would be used to blast spam to the rest of the internet.

Moving further, if the OAuth Token confers access to the rest of a user's Google suite, any information in Drive can be compromised. If the token has broader access to a Google Workspace account, there's room for inspecting, modifying, and destroying important information belonging to multiple users. If it's got admin privileges, a third party can start making changes to the org's configuration at large, sending spam from the domain to tank its reputation while earning a quick buck, or engage in phishing on internal users.

The next step would be racking up bills in Google's Cloud, but that's hopefully locked behind a different token. All the same, a bit of lateral movement goes a long way ;)

This looks interesting! I've been building a similar tool that uses TreeSitter to follow changes to AST contents across git commits, with the addition of tying the node state to items in another codebase. In short, if something changes upstream, the corresponding downstream functionality can be flagged for review.

The ultimate goal is to simplify the building and maintenance of a port of an actively-maintained codebase or specification by avoiding the need to know how every last upstream change corresponds to the downstream.

Just from an initial peek at the repo, I might have to take a look at how the author is processing their TreeSitter grammars -- writing the queries by hand is a bit of a slow process. I'm sure there are other good ideas in there too, and Diffsitter looks like it'd be perfect for displaying the actual semantic changes.

Early prototype, heavily relies on manual annotations in the downstream: https://github.com/NTmatter/rawr

(yes, it's admittedly a "Rewrite it in Rust" tool at the moment, but I'd like it to be a generic "Rewrite it in $LANG" in the future)

It's even more fun when you extend it to negative integers, reals, and the complex plane!

Matt Parker (Stand-up Maths) delves into this in a very approachable manner: https://www.youtube.com/watch?v=ghxQA3vvhsk

I'm guessing it'd look something like this on a 1-dimensional number line:

    --- >   | > >> . << < |   < ---

I think it's an interesting thought experiment. What would happen if the stock market were quantized to a blind one trade per-minute granularity?

I suspect this would put everyone on more even footing, with less focus on beating causality and light lag, placing more focus on using the acquired information to make longer-term decisions. This would open things up to anyone with a computer and a disposable income, though it would disappoint anyone in the high-frequency trading field.

How about "Vidja" -- the .fr domain seems to be available, the top google hit is for an IKEA floor lamp, and it is generally a silly English mispronunciation of "video" (you kids and yer vidja games...) :)

WORM prevents after-the-fact modification, but it isn't very helpful in the case of persistent threats.

The concern is that the tampering has already been committed to the backups. When was the "Break Glass" password last rotated? Is it protected by one or more Yubikeys that were manufactured before they fixed that nasty exploit? What other attack vectors are baked in through malfeasance or human error?

Perhaps you are the Sheriff? My baby shot me down, but they did not shoot the Deputy.

That's a useful step, but the options are still Full Cloud Dependency or DIY with Zero Security.

Why haven't they implemented rudimentary access control with printer-side Basic Auth (or the equivalents auth for MQTT and FTP). Add optional SSL support to prevent tampering/MITM on a potentially hostile network, and the unauthenticated access concerns listed in [1] should disappear.

Any problems related to potentially damaging instructions should be best-effort mitigated by the firmware and otherwise indemnified by a "your own fault for using a third-party slicer" clause in the EULA.

Bambu Labs shouldn't need to be in the authentication/authorization path, unless we're actively using their cloud environment.

Just as a thought experiment, would it be viable to send up an array of traditional hard drives? Arrange them all for use as reaction wheels, then spin them up to persist/de-stage data while changing/maintaining targets.

Probably worse than sending up well-shielded flash, but I don't think the Seagate/WD warranty expressly forbids this usage.

Who needs a house fire? A bit of quartz glass, a blow torch, and an oxygen supply, and you can convert your unused diamonds into carbon dioxide without losing the house*

Nile Red uses this approach to make Diamond Water: https://www.youtube.com/watch?v=n0wvDwSnzcw

* You might still lose the house if you opt for the bigger diamonds.

But is it web-scale?

He also covered this in a more recent talk [1] which has some better audio and a direct feed of the slides. It also comes with an entirely different set of interesting stories for anyone inclined to listen :)

1: https://www.youtube.com/watch?v=6JwEYamjXpA&t=2489s

a table of commits-modifying-this-thing [...] a linear list of commits doesn't convey branch/merge topology well.

Agreed. Presenting both the local diff and the location in the commit graph seems like a better bet for helping people glean understanding of a change's purpose and context. I'm also thinking of using a table of per-item changes that's tied to the commit graph for topologically sorted history and reachability information. This will probably be backed by a per-commit list of item identifiers with their hashed content for easier comparison.

It sounds like your abstraction is doing a great job of representing file structure. For the most part, I'm just looking at telling users that they should look at a set of related symbols and revisions after an identifier's body has changed. The user is then responsible for performing a review and updating the "last-approved" information.

As a more concrete example, I'm expecting users to maintain their own mappings to items in the upstream sources:

  #[rawr(
      codebase = "reality",
      kind = "constant",
      identifier = "f_pi",
      path = "src/constants.h",
      revision = "123abc456",
      notes = "This probably shouldn't change, but it would be good to know if \
      the upstream team makes non-Euclidean alterations to the simulator."
  )]
  const PI: f64 = 3.14159;

  #[rawr(
      codebase = "reality",
      kind = "constant",
      identifier = "f_pi",
      path = "src/constants.h",
      revision = "1897246",
      notes = "Required by Legal Counsel for compliance with bill #246."
  )]
  const PI: f64 = 3.2;

(Personally, I wouldn't want to hear that my non-free product was being implemented by someone's pet project :) Thankfully, I think we're heading in different directions, leveraging and presenting the same dataset in very different ways. In this case, I'm actually thrilled that someone else is implementing the machinery required by my pet project. Now I'm closer to exploring and following the fast-moving codebases that I wanted to reimplement in the first place!)

With regards to your call for interesting language support, I'd add a very low-priority suggestion for documentation and specification formats. Plain text, Markdown, simple HTML paragraphs and sections. If a new paragraph or sentence is added to a spec, or a MUST becomes a MAY, it'd be neat to surface the context of the change instead of a word/line diff.

As the Semantic History is not yet available, how do you envision it being displayed at the moment? What sort of information are you currently collecting? Is this tracked across the project history? To that end, are you building Tree-Sitter grammars and queries yourself, or are you using the pre-existing grammars and building the language support into Asqi?

For context, I've got a back-burner project that maps reimplemented code (manually mapped, with annotations or structured comments) to identifiable items in an upstream codebase and git repository. When the content of an item is changed upstream, affected downstream code could be flagged for review. It's still early in the design/prototyping phase, but it feels like there's some interesting overlap with Asqi.

Perhaps too late, but Rails 7.1[1] introduced composite primary key support, and there's been a third-party gem[2] offering the functionality for earlier versions of ActiveRecord.

[1] https://guides.rubyonrails.org/7_1_release_notes.html#compos...

[2] https://github.com/composite-primary-keys/composite_primary_...

Nope, all Bells will be Taco Bells after the Franchise Wars. I wouldn't trust any other restaurant for my telecommunications and networking needs.

Case in point, their 7-layer Burrito [1] offering maps perfectly to the OSI Model [2]. It is fully self-encapsulating (though occasionally leaky), and operates bidirectionally with full duplex support for correctly-configured clients.

[1] https://tacobell.fandom.com/wiki/7-Layer_Burrito [2] https://en.wikipedia.org/wiki/OSI_model

I agree that those flat surfaces would be great, except you'd have to shift other peoples' sticky leftover cups and bottles out of the way first. :(

I always like to add: 0 stress restore.

You should also be able to restore your data in a calm, controlled, and correct manner. Test your backups to be sure they work, and to be sure that you're still familiar with the process. You don't want to be stuck reverse-engineering your backup solution in the middle of an already-panicky data loss scenario.

Remain calm, follow the prescribed steps, and wait for your data to come back.

I'd recommend a read of RFC 2100: The Naming of Hosts [1] for more on the matter, as naming choices may drive one as mad as a hatter!

[1] https://www.rfc-editor.org/rfc/rfc2100

I'm curious if a limited English dictionary would eventually start picking up loan words for new concepts, gradually bloating back into the modern (or future) English vocabulary.

Out of interest, I'd point at XKCD #1133, "US Space Team's Up-Goer Five" [1] and Thing Explainer [2][3] for examples of what gets lost when vocabulary is cut down.

[1] https://m.xkcd.com/1133/ [2] https://xkcd.com/thing-explainer/ [3] https://en.m.wikipedia.org/wiki/Thing_Explainer

Even worse, they might even try to _hire_ you!