Have you scanned any headlines about ICE lately? Maybe do a quick search for news about Minnesota?

(I'm pretty sure that if you'd been putting your pants on in Minnesota, you would not have written this comment.)

Surely it can't be 100%, right? No event in any major city, even horrific events, actually affect everyone.

You can make it appear as if you have a better grasp on reality by just acknowledging that this is a much different enforcement mechanism than we've seen in the past, but you think that's okay.

Anyway there are now several known cases of people being detained or deported without deportation orders. This is another point that you could at least give the appearance of honesty and grasp on reality by acknowledging.

So what's more probable in your mind?

( Hypothesis A ) -- Mobs trying to interfere with law enforcement has caused DHS to focus on arresting and deporting immigrants without criminal background

( Hypothesis B ) -- DHS's focus on arresting and deporting immigrants without criminal background has required significant scale-up of personnel with minimal training (validated by DHS's own data) and required tactics that a large number of Americans believe to strike an unacceptable cost-benefit balance

( Hypothesis C ) -- The two facts (enforcement approach and public response) are not causally related to each other at all

At least people in the past had the integrity to acknowledge their positions head-on. One of the lamentable things missing today

One was returning from dropping off her 6 year old child at school.

The other was videotaping ICE activity with one hand while holding out the other hand to show he was no was no threat.

What is your point, exactly? Neither was doing anything illegal, neither was directly trying to interfere with ICE actions. (The first wasn't trying to interfere at all.)

Although normally I'd say wait for the full evidence to be revealed, in this case (1) there's already a wealth of evidence from bystanders, and (2) the investigations are actively being interfered with so official evidence is not forthcoming.

Those are the 2 citizens killed. CBP and ICE killed at least 25 other people in the field and at least 30 died in custody (one source cites 30-32, another 44).

Apparently, the violence is necessary to deport at (checks notes) a lower rate than Biden's. It might make sense if the current enforcement was aimed at serious criminals, but only the rhetoric is. The current enforcement is much less selective. More damage, less gain.

Let's assume there was. Then what on earth is the administration doing tracking down and putting cuffs on so many people who do not fit in that category?

Every seat in a detention center, courtroom, or plane filled by a random guy stopped in the Home Depot parking lot is a seat taken away from one of these allegedly numerous violent rapist/murders/whatever.

So even if you were stupid enough to believe all the transparent bullshit from this gang of liars, they'd still be fucking awful!

All this stuff does, in addition to squelching public appetite for immigration enforcement writ large, is keeps the actual bad guys inside the country even longer!

> As conduction and convection to the environment are not available in space, this means the data center will require radiators capable of radiatively dissipating gigawatts of thermal load. To achieve this, Starcloud is developing a lightweight deployable radiator design with a very large area - by far the largest radiators deployed in space - radiating primarily towards deep space...

They claim they can radiate "633.08 W / m^2". At that rate, they're looking at square kilometers of radiators to dissipate gigawatts of thermal load, perhaps hectares of radiators.

They also claim that they can "dramatically increase" heat dissipation with heat pumps.

So, there you have it: "all you have to do" is deploy a few hectares of radiators in space, combined with heat pumps that can dissipate gigawatts of thermal load with no maintenance at all over a lifetime of decades.

This seems like the sort of "not technically impossible" problem that can attract a large amount of VC funding, as VCs buy lottery tickets that the problem can be solved.

It really is as simple as just adding kilometers of radiatiors. That is, if you ignore the incredible cost of transporting all that mass to orbit and assembly in space. Because there is quite simply no way to fold up kilometer-scale thermal arrays and launch in a single vehicle. There will be assembly required in space.

All in all, if you ignore all practical reality, yes, you can put a datacenter in space!

Once you engage a single brain cell, it becomes obvious that it is actually so impractical as to be literally impossible.

That doesn't match my experience. I think AI tools have their own skill curve, independent of the skill curve of "reading/writing good code." If you figure out how to use the AI tools well, you'll get even more value out of them with expertise.

Use AI to solve problems you know how to solve, not problems that are beyond your understanding. (In that case, use the AI to increase your understanding instead.)

Use the very newest/best LLM models. Make the AI use automated tests (preferring languages with strict type checks). Give it access to logs. Manage context tokens effectively (they all get dumber the more tokens in context). Write the right stuff and not the wrong stuff in AGENTS.md.

I'd rather spend my time thinking about the problem and solving it, than thinking about how to get some software to stochasticaly select language that appears like it is thinking about the problem to then implement a solution I'm going to have to check carefully.

Much of the LLM hype cycle breaks down into "anyone can create software now", which TFA makes a convincing argument for being a lie, and "experts are now going to be so much more productive", which TFA - and several studies posted here in recent months - show is not actually the case.

Your walk-through is the reason why. You've not got magic for free, you've got something kinda cool that needs operational management and constant verification.

If you hate Xcode, this is definitely worth a look.

[1]: https://notepadexe.com

[2]: https://notepadexe.com/news/#notepad-14-linux-support

That's a pretty good deal.

If all of those people switch to cars, you end up with it taking an hour to travel 1 mile by car.

It's almost as if they have busses for a reason.

But anyway, your statement is actually not true anywhere in the US except NYC. Even in Chicago, removing ALL the local transit and switching to 6-seater minivans will eliminate all the traffic issues.

If you remove the jobs and housing, traffic does get a lot better. But it's not much of a city without jobs and housing.

Large stadium arenas are a special case, but they don't create sustained traffic, and their usage periods typically do not overlap with the regular rush hour.

It's not that tough, but there can be tricky cases.

1. Following Postel's law, don't reject "invalid" third-party input; instead, standardize how to interpret weird syntax. This is what we did with HTML.

2. Use declarative schema definitions sparingly, only for first-party testing and as reference documentation, never to automatically reject third-party input.

3. Use XML-like syntax (like JSX) in a Turing-complete language for defining nested UI components.

Think of UI components as if they're functions, accepting a number of named, optional arguments/parameters (attributes!) and an array of child components with their own nested children. (In many UI frameworks, components literally are functions with opaque return types, exactly like this.)

Closing tags like `</article>` make sense when you're going to nest components 10+ layers deep, and when the closing tag will appear hundreds of lines of code later.

Most code shouldn't look like that, but UI code almost always does, which is why JSX is popular.

    <swim-lane>
        <style>
            @scope {
                background: pink;
                b {
                    background: lightblue
                }
                @media (max-width: 650px) {
                    /* Mobile responsive styles */
                }
            }
        </style>
        something <b>cool</b>
    </swim-lane>

    @scope (swim-lane) { /* ... */ }

Shadow DOM is awful. Nobody should be using it for anything, ever. (It's required for putting child-element "slots" in custom elements, and so nobody should use those, either.) Shadow DOM is like an iframe in your page; styles can't escape the shadow root and they can't get into the shadow root, either. IDs are scoped in shadow roots, too, so the aria-labelledby attribute can't get in or out, either.

@scope is the right abstraction: parent styles can cascade in, but the component's styles won't escape the element, giving you all of the (limited) performance advantages of Shadow DOM with none of the drawbacks.

I love custom elements. For non React.js apps I use them to create islands of reactivity. With Vue each custom element becomes a mini app, and can be easily lazy loaded for example. Due to how Vue 3 works, it’s even easy to share state & routing between them when required.

They should really move the most worthwhile features of shadow dom into custom elements: slots and the template shadow-roots, and associated forms are actually nice.

It’s all the extra stuff, like styling issues, that make it a pain in the behind

For slots to work you need a container for the slots that the slotted elements do not belong to, and whose slots are separated from other slot containers. Otherwise you can't make an unambiguous relationship between element and slot. This is why a shadow root is a separate tree.

But, if you do that, what happens to the original `<super-row-header>` element that the user provided? Maybe you'd want to delete it…? But how can you tell the difference between the user removing the `<row-header>` and the custom element removing it in the course of its work?

What you'd need is for `<row-header>` to somehow exist and not exist at the same time. Which is to say, you'd have one version of the DOM (the Light DOM) where the slot element exists, and another version of the DOM (the Shadow DOM) where the `<row-header>` element doesn't exist, and the transformed content exists instead.

It's clever, I guess, but the drawbacks far outweigh the benefits.

Client-side components inherently require JS anyway, so just use your favorite JS framework. Frameworks can't really interoperate while preserving fine-grained reactivity (in fact, Shadow DOM makes that harder), so, just pick a framework and use it.

Sort by negative sentiment; Shadow DOM is at the top of the list, the most hated feature in Web Components. You can read the comments, too, and they're almost all negative, and 100% correct.

"Accessibility nightmare"

"always hard to comprehend, and it doesn't get easier with time"

"most components don't need it"

"The big issue is you need some better way to some better way to incorporate styling from outside the shadow dom"

> It's the only DOM primitive that allows for interoperable composition.

There is no DOM primitive that allows for interoperable composition with fine-grained reactivity. Your framework offers fine-grained reactivity (Virtual DOM for React/Preact, signals for Angular, runes for Svelte, etc.) and any component that contains another component has to coordinate with it.

As a result, you can only mix-and-match container components between frameworks with different reactivity workflows by giving up on fine-grained reactivity, blowing away the internals when you cross boundaries between frameworks. (And Shadow DOM makes it harder, not easier, to coordinate workflows between frameworks.)

Shadow DOM sucks at the only thing it's supposed to be for. Please, listen to the wisdom of the crowd here.

This just isn't true - composition and reactivity are completely orthogonal concerns.

Any reactivity system can manage DOM outside of the component, including nodes that are projected into slots. The component's internal DOM is managed by the component using whatever reactivity system it desires.

There are major applications built this way. They make have a React outer shell using vdom and Lit custom elements using lit-html for their shadow contents.

On top of those basics you can also have cross-shadow interoperable fine-grained reactivity with primitives like signals. You can pass signals around, down the tree, across subtrees, and have different reactivity systems use those signals to update the DOM.

If the child component had been a React component instead, the children would have participated in the virtual DOM, and React could do a minimal DOM update when it was done.

React can't even see the shadow contents of Lit elements, so React just has to update the light DOM and let Lit take over from there.

(Same applies to Vue, Angular, Svelte, Solid, etc. Each framework has a reactivity system, and you have to integrate with it to get its benefits.)

React's vdom without shadow DOM passes props to components, which all return one big vdom tree, and then there's one big reconciliation. React used with shadow DOM evaluates smaller vdom trees per shadow root, and does more, but smaller reconciliations. It's the same O(n) work.

But in reality it's often much _better_ with shadow roots because the common WC base classes like Lit's ReactiveElement all do change detection on a per-property basis. So you only regenerate vdom trees for components with changed props, and with slots that doesn't include children. So if children of a component change, but props don't, the component doesn't need to re-render. You can do something similar by hand with memo, but that doesn't handle children separately. The compiler will, of course, fix everything.

Every other reactivity system works fine across shadow boundaries. Even the super-fine grained ones like Solid. The only issue with signals-based libraries like Solid is that they pass signals around instead of values, so to get true no-re-rendering behavior with web components you have to do that to, which means picking a signals library, which means less interoperability. The TC39 signals proposal points to a future where you can do that interoperably too.

Yet, for actual web components, I entirely agree with you.