chao-

Firefox's Multi-Account Containers changed the game for me back in 2018 or 2019, and is what got me to switch back to Firefox for 95% of my personal browser use. The "Always open {{domain}} in this container" and the ability to open a specific container with a keyboard shortcut seem like small things, but I can't imagine life without them anymore.

I never understood why it was set off to the side in an (official, first-party) extension, because I was always afraid they would one day stop supporting it. Now when I explain to people why I prefer Firefox, I don't have to explain "There's this extension, don't worry it's official, that allows me to..." I can just say "It has containers built-in. They're great. Try them."

I started writing a sarcastic comment to "prepare for $500 Apple-branded QSFP112 DAC cables", but realized (a) that's not too much higher than some already sell for, and (b) it's close to a linear scaling from TB5 price-per-bandwidth (not exactly, but close).

So I guess someone wanting that would be prepared for it.

It works because they are allowed to by the state, by a process specified by the state. The rules and ordinances of a county or municipality are subordinate to the laws of the state that granted them existence in the first place. There's a lot variety in "by a process specified by the state", which results in different structures: commissions, charters, mayoralties with councils, and more.

Sound isn't working in Firefox on Linux, but otherwise very fun. The only thing it's missing are Neil's favorite traffic cones ;)

Also glad that Neil is getting the protection he needs (and the public as well) despite the media attention.

I go with Alka Seltzer specifically because they have an Aspirin variant instead of Acetaminophen.

After a decade of exploring various mechanical keyboards (a few form factors, but mostly exploring the switches), I settled on a Topre Realforce around 2016 and fell in love. I later learned of the Topre silent switches (often branded as "Type-S"), and have used those ever since over many few boards: a HHKB, a Leopold FC660C with a PCB swap for programmable layers, various revisions of the Realforce.

I used a friend's ErgoDox a few years ago, and quite liked it, but what holds me back is the Topre switches. If only it was feasible to acquire individual Topre switches and put them onto a custom PCB...

Here's hoping someone on HN will swoop in and tell me "It's totally possible! Just _____!"

I am also struggling to see what clicking any of the options in the demo changes. I don't consider myself advanced in design knowledge, but I'm pretty average in visual perception.

Perhaps some or all of them don't work in Firefox for Android, and I'm just seeing a fallback behavior that does work?

Edit: Just tested in Chrome desktop and Firefox desktop on Linux, still struggling to see a difference in any of the demo regions (which I assume are supposed to demo the option when selected?). Also scroll behavior is graphically laggy/jumpy in Chrome, but not Firefox.

Played with this a while, and the metaprogramming supporting this is fun :) Once again proving that you can dream up a wild idea, and Ruby will support you in achieving your dreams.

Looking at Syntropy::ModuleLoader, "modules" get to pretend they are in some main-like flat scope, but actually are executing in the instance scope of a Syntropy::ModuleContext. A consequence of this is that it is difficult to imagine these modules (and their exports) interoperating with plain Ruby code that doesn't have access to the `#import` (or needs to eschew it for some reason).

This seems fine in the context of a "closed loop" framework: expect to only ever consume a Syntropy module's `#export` in another Syntropy module, and only using Syntropy's `#import`. That seems like the happy path, but it is a tradeoff: you really need to buy into this "module" system all the way.

There might be an escape hatch, if plain Ruby code (i.e. not another Syntropy module) has access to the instance of ModuleLoader. With that, you can grab an export value via `#load`, which seems fine as long as the thing you need to `#load` isn't a module or class.

Specific to exporting a module or class, it feels natural for me to want to assign it to a capitalized constant when importing. I expected this not to work, as Ruby will reject instance scope `SomeModule = 'some_value'` if I write it as source code (SyntaxError, dynamic constant assignment). However, when I `#instance_eval("SomeModule = 'some_value'")` it as a string (as Syntropy::ModuleContext does), Ruby accepts it? I'm surprised!

The downside is that these end up as some kind of shadow constants, relative to each instance of Syntropy::ModuleContext? That is, they can only ever be accessed by name inside of a string passed to `#instance_eval`. I need to think longer about what the implications are. It's certainly interesting.

Always cool to see a fresh approach to organizing Ruby projects!

Like the author, I have experimented with app structures that better suit my project needs than Rails' conventions (having spent more than half my career partially-or-mostly using Ruby, and most of that using Rails). Sometimes that meant building within Rails and bending it to my desires. Sometimes that meant a blank-slate project layout of my own with some glue bits to talk to Rack. Most of the time the juice was not worth the squeeze, but hope springs eternal.

The one-to-one URL-path-to-folder idea feels neat. I think it would be neat for smaller and/or strictly-API-based projects, but I'm not sure I would prefer it as a strict requirement for large projects. It definitely got my noggin joggin'!

Eschewing one-psuedo-namespace-constant-per-file as a unit of encapsulation and orchestrating your own import and export also got me thinking, but more skeptically. Working in languages that embrace a free-form import/export, I have found that I prefer the one-encapsulated-unit-per-file style. I am going to dig into the Syntropy implementation and see if it inspires me to feel differently about this.

Additionally:

A further disadvantage is that since everything is global, you might risk touching or referencing classes you shouldn’t, and since dependencies are implicit, those “references by error” may go unnoticed and cause some unexpected (read: undefined) behaviour.

I suspect the author knows this, but it is not the full story to say that "everything is global". Constants are global in that the Ruby VM's has only one hierarchy that for constant lookup. And because Ruby doesn't have namespaces (yet; we'll see what comes of Box), people reuse the constant hierarchy to approximate a namespace.

Local variables and instance variables in your "main" object scope are not global, either. Not only are the isolated from other object instances, the variables of the "main" object are not accessible from the class/singleton scope when declaring a class or module!

And none of these were decisions made by Rails.

This approach automates the loading of dependencies, using the directory structure as a representation of the app’s namespace (i.e. classes and modules).

If only this were true! The file at app/models/user.rb is not required to declare the constant App::Models::User or even Models::User. One of Rails' three original sins is the layout conventions of the app/ folder, and the conventions built on that.

Yes, technically almost all of it can be configured with some difficulty. My experiments with alternative project layouts using Rails have had mixed success. When you place models and associated core behavior `domain/core/` instead of `app/models`, it's a coin-flip as to whether another developer sees that and says "Oh neat!" or is annoyed. Or when you place pairs of Ruby "view models" and ERB "view templates" in the same directory (e.g. `views/posts/show.rb` alongside `views/posts/show.html.erb`) it throws some people off, even though to me it feels obviously and unquestionably more organized.

EDIT: Removed my comment, as I was referencing the HN article's link. It seems to incorrectly link to a separate comic that is coincidentally also about "surprise".

I agree with bazoom42 in the context of the correct comic:

https://wizardzines.com/comics/no-feigning-surprise/

Don't you think they have a legit skill issue here and should they be better off upskilling themselves?

Absolutely agree! Just because I understand how they got there doesn't mean I think it's a good state of affairs ;)

My post was already quite long, and I didn't want to append a treatise on what one should do when encountering those engineers. It depends on many details. Avoid hiring them, if that's a power you have. If you are stuck working with them, depending on your authority, encourage them to learn or force them to learn. If you're coming in to clean up after them... well, hopefully your comp is worth the annoyance.

We are all simultaneously in the position of encountering "the world as it is", understanding it, and doing what we can to improve it.

Starting a few years ago, I realized some junior and medior engineers never once considered the possibility of building a website (app, experience, etc.) in anything other than a heavy SPA framework. But they're not stupid people! If you directly asked "Can you build a website without React?" they know the answer is obviously "Yes." However, if you asked them to build a new website, they would unthinkingly start a new React project, mostly out of familiarity and a desire to get the job done.

A few of them would outright not know how to do anything else. No knowledge of how to stand up a boring HTTP server to send pure HTML. No experience building a form that validates or submits without JavaScript. These are not the people who post here on HN. They are not engaged in online discussions of new tools and skills (or old tools and skills!). These are people who learned just enough from a bootcamp, or their uni's single "web apps" course, to get a job. Since then, they have just-in-time learned whatever their employer required, or whatever particular tools someone else on their team chose for a project.

As an old, it took me a while to recognize/realize it, but I understand them now. Depending on their career path, someone will encounter the simplest aspects of HTML, CSS and vanilla JavaScript after they learn the complex, framework-specific aspects of each. It feels (to them) like more esoteric, advanced, or tertiary knowledge.

Tying it back to to the quote "that’s a lot more work for us", that's not necessarily an intentionally false claim. It probably does feel like a lot more work to perform a task using unfamiliar tools, even if they are less-complex tools.

Yes, that would work the same way! However, I was on an HEDT system, with no iGPU and many PCIe lanes to spare.

Having gone this route in the past*, once I accepted that I needed a second GPU dedicated as owned by the VM, most issues went away. No SR-IOV battles, just the simplicity of "Linux owns GPU A, Windows VM owns GPU B".

If I am remembering my build from the time, I had an RX 580 for Linux, and a GTX 1070 as passthrough to the Windows VM. At first, it felt like I was "giving up" on solving some problem that felt like it should be solvable, but it worked so well that I couldn't argue with the results.

It also assumes you have a motherboard with the right slots and enough PCIe lanes to get the performance out of two GPUs, and assumes you have a PSU with the power budget to support both GPUs. It definitely was a compromise, not perfection.

*Approx 2017 to 2020, before Proton or when it was was still new/immature. I now no longer care enough about games to play one when it doesn't just work on Linux. I assume the author does not feel this way.

Context: Notepad++ was compromised last year by a PRC state-sponsored group: https://notepad-plus-plus.org/news/hijacked-incident-info-up...

This is not purely a cosmetic release, as it does contain a few fixes.

There's also much more to Shopify than just Ruby feature work. I've heard tales of their infrastructure and it seems like it would be very exciting for the right kind of person.

Never worked there, probably never will, but they have my respect for the things I have seen, read and heard.

I know it as "when the Elves leave Middle Earth" from an essay of the same name:

https://steveblank.com/2009/12/21/the-elves-leave-middle-ear...

`method(:name).source_location`, but yes. Ruby is very introspect-able and it is fantastic.

Ah yes! I remember Merb now that you say it :)

I have my criticisms of Rails, but that definitely set it on a better path.

This has not been my experience.

I have taken applications from 2-to-3, 3-to-4, and so on, through 8.X.

If anything it has gotten better/easier over time. The most challenging upgrades were 2.X to 3.X (for reasons I can't recall), and then 6.X to 7.X (for an application that had issues adopting zeitwerk). In both of those situations, there was a lot of rote legwork, but once tests were passing, the application was working reliably. The other upgrades (3-to-4, 4-to-5, 5-to-6, 7-to-8) weren't happy-fun-rainbows-and-unicorns, but they weren't catastrophically complicated? Not even in fairly large codebases.

For each of these, a strong test suite was the best tool, which it sounds like you already know?

In my experience, the other impactful factors were:

(1) Reading the CHANGELOGs and knowing enough about Rails to know what they meant for the application.

(2) Using test fixtures (or fixtures with only some factories) for a quicker feedback loop for engineers.

(3) Having a true QA function in the company that isn't just engineers testing their own code.

one could also expect a functioning city to not have flooded streets

In some cities, certain streets are designed to flood during heavy rain, and are an integral part of routing the water away from neighborhoods and businesses, and into the drainage systems.

The Times was also in the midst of a leadership transition, and new management tends to want to move on from the old regime’s pet projects, even if they were successful.

Learning about B2B sales over the years, the size of this leadership-change factor has been among the most eye-opening (and among the most disappointing).

It cuts both ways: You can have a successful pilot that doesn't proceed because this-or-that VP was replaced, and to show off their bold new direction, the new VP cancels almost everything novel the previous person started. Or you can reach out just at the moment the new guy or gal comes in, right when they're looking for the pieces of their bold new direction, and you become part of that.

I would love to have later learned that leaders who evaluate opportunities separate from personal attachment are seen as more efficient, better, and selected favorably; that more successful companies are less subject to this sort of political/careerist whimsy. Alas. At least I have been fortunate enough to experience both directions in quantities that roughly balance out.

Refinancing a loan I passed on the lowest possible rate I could get, for a slightly higher one, specifically because they used Plaid.

I'm not the most privacy-focused individual, not nearly as paranoid as I could be, but Plaid's model is an OBVIOUS step too far.

sometimes you find someone akin to a hammer looking for nails, starts to label anyone a missing stair over the slightest incompatibility.

I 100% agree. This is why it is important for leaders not to rely on the judgement of a single person, but on the behavior of perception of the community as a whole (which I tried to mention as a caveat in my comment).

On the other hand, if you have an overeager moderator with too much discretionary power... well that's a different community problem, and it is going to go wrong in multiple ways, not just this one :(

Depends a lot on the community's topic, purpose, and size.

However, a sign that someone needs to be removed is if you find that the community writ-large treats them as a Missing Stair [0]. If they have refused direct requests from community moderators/leaders to address their behavior, or regressed after a short period of improvement, and if most of the community is required to do work to actively manage their toxicity, that is not sustainable.

It is a mistake I once made in managing a community. There was a person who was able to present as "pleasant enough" when the situation called for it, but who was often toxic when something didn't go perfectly (especially in a 1-on-1 setting). I allowed them to stay for too long, and the community as a whole suffered from the ambient sense of tension and hostility.

[0] https://en.wikipedia.org/wiki/Missing_stair

Hmm... when I really care about the quality of something, I basically write what I think/speak, then try to edit it down by half. I don't find it unsalvageable, but the editing does require an order of magnitude more time than the initial draft of thoughts vomited into the keyboard.

When writing on paper, either I will pause thinking enough, or will sometimes lose where a thought was going. I am much faster at typing than writing, so I end up with more, then edit/delete afterwards (if I feel like writing well). I am much worse at writing long-form thoughts than I was back in college, now that 99% of what I do is type.

An odd tradeoff of my verbal-based writing seems to be that I am a fairly slow reader. I read aloud in my head, albeit a bit faster than I could speak, but I still hear the words as an internal monologue.

When discussing this a few times with friends, I've learned how different everyone's experiences are when bridging thoughts=>speaking, thoughts=>writing, thoughts=>typing, and text=>thoughts (or even text=>understanding).

I write the words that I hear in my head, as though I am speaking. With the exception of timed, in-class essays, I always turned in papers far in excess of any minimum during high school.

In college, I took a constructive writing course because I thought "Hey, easy A!" After the second or third week, the professor told me that, while the class had a word minimum, I would also be given a separate word maximum. She said I needed to learn brevity and simplicity, before anything else.

The point being: I was able to cruise through high school with my longwindedness as a cheat code, never stressing about minimum lengths, despite my writing being crap in other ways.

Although I have regressed in the two decades since, it helped me a good deal. I am grateful to that professor for doing that.

There already are SXM5-to-PCIe adapter cards, but from what little I've seen, they are all a bit dodgy. If (if!) there really is some flood of used/decommissioned H100s/H200s into the market, perhaps that will motivate iterations and mass production of these, and they become more reliable?

It is not 100% out of the question. I would also love to see it happen, but am being realistic about the chances, as a check on my own usual optimism.

I think the more likely scenario is, rather than a flood of decommissioned Hopper-era servers being separated into parts, and the parts sold for "pennies on the dollar", we will see entire 4x H100 servers (CPU and RAM included) sold for "dimes on the dollar" to small-and-mid-sized businesses and labs. A formerly-$250K server sold for $50K after six years. Or $20K after ten years. Something like that.

Maybe not insurmountable in the "laws of physics" sense?

However, it may be so costly in cobbled-together parts, and in time to deal with unsupported drivers and/or VBIOS, that it is not worth it compared to using a proper server hardware with proper SXM sockets. Nvidia is also doing a lot of new, exciting things with networking that may make their SXM-based GPUs require even more just-so hardware support as time goes on.

Getting older SXM3 GPUs (i.e. for V100's, from 2017) working via PCIe adapters has been done reliably. However, here is someone who did that successfully, and spent a chunk of time last year trying to do the same for SMX5 (H100) and failing:

https://forums.servethehome.com/index.php?threads/sxm5-h100-...

We were all spoiled by the era from 2005-2020, when you could squint at a "server" configuration and see that it was expensive, high-binned, commodity hardware with some extra RAS and OOBM features. You could buy parts harvested from a retired server based on Xeon E5-1680v3 and drop them in your workstation. Or you could buy an entire single-socket Xeon E5 v3 server, plop in a GPU, and mostly use it as a workstation! As-is!

Now the serious servers have SOCAMM memory, 400Gbps networking, EDSFF SSDs, maybe are configured for CXL 3.0, et cetera. The hardware itself is so divergent that it isn't swap-in-plug-and-play with desktops, even for some high-end workstations.