TurningCanadian

instead of "expression" you meant "exception", right?

That's not Java's fault though. IntelliJ IDEA is also built on Java and runs just fine.

It's a collective action problem. One person's subscription will not make the difference needed to improve journalism enough for them to get a direct benefit. Further, the main benefit would be that it exposes corruption, which doesn't generally impact individuals. Corruption's effects are spread amongst all the tax payers. Each individual is better off not subscribing and reaping the benefits of others' subscriptions, but everyone suffers if local journalism isn't funded.

It's similar to the climate crisis: there's broad agreement that things are bad and getting worse, but individuals acting in their own self-interest can't be counted on to solve it.

Further, commercial interests are generally anti-aligned with exposing corruption. They'd rather their bribes/lobbying be unquestioned, driving down the cost of it at the expense of the tax payer. We can't count on business to provide this service.

Finally, this isn't just about québécois and indigenous content. The last I saw, the $ was available as long as you had full-time journalists on staff, regardless of their focus.

I don't like Canadian telecoms, but in order to get the $, they have to be employing full-time journalists, which is the outcome we need.

What's the alternative?

I haven't seen anyone put any other alternatives up for debate.

I know Poilievre has talked about defunding the CBC, but I don't know of anything he has proposed that would result in more local journalists.

Do you have an alternative in mind? We need some way to get $ into journalists' pockets while also having some accountability.

Increased CBC funding? It's probably better to have a diverse set (i.e. not just one being subsidized) of news outlets, so the Liberal plan here makes more sense to me, though there's also an argument for not spreading things too thin across lots of tiny outlets.

Instead of taxing the streamers, require they provide local content directly? I think that this proposal is doing that indirectly. The streamers get taxed, but could pick up some $ from the CRTC if they start producing more local content.

Instead of taxing the streamers, tax people directly? That'd probably be less popular than taxing the streamers, so good luck with that.

There's a crisis in local news. It's an essential service that the free market has largely stopped providing -- the number of journalists following local politics has been decimated, and sometimes in a literal sense. Without someone with the time to follow that stuff corruption flourishes, and getting rid of local government is not an option. We need some sort of fix so it's nice to see someone trying.

https://www.securityweek.com/scathing-federal-report-rips-mi...

The panel said the intrusion, discovered in June by the State Department and dating to May “was preventable and should never have occurred,” blaming its success on “a cascade of avoidable errors.” What’s more, the board said, Microsoft still doesn’t know how the hackers got in.

...

It said Microsoft’s CEO and board should institute “rapid cultural change” including publicly sharing “a plan with specific timelines to make fundamental, security-focused reforms across the company and its full suite of products.”

You might be able to argue that Postgres' foreign data is a different form of pluggable storage engine. E.g. you can even use a CSV file as a backing store for a table with file_fdw.

https://www.postgresql.org/docs/current/ddl-foreign-data.htm...

https://dbaclass.com/article/how-to-access-csv-files-on-file...

iMessage is the monopoly part. They could make an App or even just an API available on other platforms but don't because they want the lock-in.

“The #1 most difficult [reason] to leave the Apple universe app is iMessage ... iMessage amounts to serious lock-in,” was how one unnamed former Apple employee put it in an email in 2016 “iMessage on Android would simply serve to remove [an] obstacle to iPhone families giving their kids Android phones,” https://www.theverge.com/2021/4/9/22375128/apple-imessage-an...

Not getting on board with RCS or any other way to improve SMS/MMS until they were (implicitly) forced was motivated by that desire to lock their users in to a messaging platform that only works on Apple devices.

I like sites whose cookie banner gives options instead of only having "Accept All". It makes you feel more respected as a user.

It seems like they're worried that interning of objects/records would be too expensive to do generally. It's hard to predict though: that overhead would only apply to new code using R&T and has to be weighed against the elimination of recursion for deep comparisons and freezing, fewer re-renderings when value-equal but not reference-equal objects are encountered, the greater possibility of memory reuse across deep clones, and other performance optimizations that would be unlocked by true immutability.

Aside from performance, true native immutability would bring huge improvements to how JS programmers can reason about their code. Not having to worry about mutation makes a whole class of possible bugs disappear. Having to rely on third party libraries (or deep freezing manually) for immutability is really holding back the language.

String's localeCompare:

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Passwords don't protect against spoofed login pages.

Sounded like the solution was to tell them that they've been out-ranked. That's the part that was missing from the text conversation. After that, of course they'll be meek.

only if you don't like documenting your APIs

An optimization pass will speed up the server runtime too. Well worth it.

Would be nice if YouTube URLs gave some context (e.g. author, title)

This one is:

@EONutrition

Mega Dose Vitamin Therapy: Viral Infection & Post-viral Illness

You also irretrievably lose access to your funds if an attacker steals your credential. Not a problem as long as you have flawless security. /s

TLDR: it's being worked on, but not ready yet.

There is a real taboo about mentioning veganism. That said, it's fairly mainstream these days -- any big enough BBQ will have to have some option. Lactose/gluten/shellfish/peanut etc issues (that aren't choices) are a fact of life, and any crowd will have at least one vegetarian/vegan that can benefit from some of the overlap.

It's not about convincing people to change their behavior directly though. People hate being told what to do. It's also hard to guilt someone into change. Some of the changes are just no-brainers though. Plenty of people try veganism and give it up. How many people try an EV then give it up? (I don't actually know, but it doesn't seem like many. They're so fun to drive.) More upfront cost, yes, and that may be the reason not to get one, but it pays for itself over time. Same with an induction stove. Who actually likes being in a superheated kitchen on a summer day? Who likes how much harder it is to clean a gas stove? The risk of burning yourself or starting a fire? Worst case: some of your pots don't work and you have to replace them.

You don't have to mention this stuff out of the blue, but if someone is thinking of redoing their kitchen? That's the time. Buying a new car? That's the time. Someone has money to invest? Get some solar panels instead.

You still have two votes: with your wallet, and with your ballot.

Think back to the times of slavery. You could've said: "I don't own any slaves, so there's nothing I can do". In the end, we did the right thing, but unfortunately after much human suffering. Hopefully we don't wait even longer this time around. There were many things you could've done to help. You could've avoided buying from places that used slave labor. You could've voted for abolitionists. You could've donated to the cause. You could've stood for justice when serving on a jury. You could've convinced your friends that things had to change.

You as an individual may be individually directly responsible for a small amount, but you are probably responsible for a greater than average amount. The little changes that you make will make a bigger difference than most people's. You can also be indirectly responsible for a much greater amount. Talking to your friends about the environment can have a greater effect than you acting alone. People don't realize just how much better EVs are, induction stoves are, heat pumps are, solar panels are, etc, if they haven't heard the benefits. Help to open their eyes.

Your vote also likely controls a far greater amount than you are giving it credit for. Margins of victory are often small, and a few people thinking of the medium and long term can make a big difference.

You could say the same thing about doing nothing. As evidence I submit the study referred to in the article.

The nice thing about a standard like K8S is how there are other clients to choose from.

You can do everything from the CLI with kubectl of course, but there are also a bunch of apps that will work with any K8S cluster:

https://medium.com/dictcp/kubernetes-gui-clients-in-2020-kub...

It's very nice to have a consistent interface across multiple cloud providers.

Anyone know if Record & Tuple (deeply immutable primitive values) is moving ahead or stalled?

https://tc39.es/proposal-record-tuple/tutorial/

There's a lot to caching that REST gets wrong. It thinks in terms of URLs being cacheable, but that's very limiting. GraphQL caches at the level of the objects in the response. Almost every REST API will return multiple objects from one URL. With GraphQL, newer data coming in from query2 can update components showing data from query1 if they both reference the same object even if query2 is a different URL. REST just doesn't have those smarts. Yes, a HTTP DELETE request will clear the cache for a particular URL, and there's no equivalent in GraphQL, (that I know of) but I don't think I've ever been able to take advantage of that in real life.

At the network level, GraphQL can automatically set cache headers depending on the content. REST doesn't know what you're sending, so it's up to you to know that when you start sending mixed data (to save clients a roundtrip), the cache header may be impacted. https://www.apollographql.com/docs/apollo-server/performance...

On the client-side, caching with GraphQL is far ahead of dealing with a REST API. It knows more about what data it has in cache so it's better able to automatically avoid network requests. Further, a cache-and-network fetch policy is just another parameter for your query and the plumbing for that is handled transparently.

React doesn't provide a systematic answer for handling state in apps if data is flowing up, down and sideways.

The built-in React way of doing that is with context.

React also needs to hydrate every element even when it isn't ever going to change

That is no longer true with Server Components https://beta.nextjs.org/docs/rendering/server-and-client-com...

There's still TLS Server Name Indication leaking the hostname.

the "honest consensus" is the "diversity of users"; users doing the validation at least. Your rewards can be as high as you'd like, but if one party is in control of most of the validation, you're screwed. It's not the number of nodes or what you pay them or anything like that that matters. It's the actual people/entities behind them that matter.

It needs enough diversity of users to be resilient against a 51% attack. If you don't have that, the value is 0. (You lose the benefit of the distributed ledger and may as well be relying on a central party's database at that point.)