I'd be cautious for the same reason: thyroid cancers are also positively associated with obesity, and people who take GLP-1s are often obese.
Below a table, it says "adjusted for social deprivation index, hypo- and hyperthyroidism, and use of other antidiabetic drugs..." -- but nothing about obesity.
What if the GLP-1-prescribed patients tended to be more obese?
I guess you're just unaccustomed to America's loooooooooooooooooooongstanding free speech regs.
Many people in more restrictive countries (like Germany and the UK) are pretty shocked by what USians are permitted to say. Similarly, many USians are shocked by what folks in more restrictive countries are NOT permitted to say.
Krebs is an American journalist, living in America, writing for an American publication. The standard to use here is an American one, not any others.
> I guess you're just unaccustomed to America's loooooooooooooooooooongstanding free speech regs.
I'm reasonably certain that I know the extents of what you can and can't legally say in the US better than most people who live there. National differences in these things happens to be one of my areas of interest, but that is besides the point.
I'm viewing this through an ethical lens. Legality doesn't enter into it beyond recognizing that laws that deal with crime are often informed by morality.
chmod775 point is about ethics, not legality. (Though perhaps by "publication standard", you're saying that what's considered ethical is also judged by American standards?)
Ethics is the study of morality. And while you're correct that people have subjective ideas of morality, it absolutely does not matter for the sake of this conversation. You are detracting.
Just because in some place a practice is considered to be okay (morally, whatever), does not mean it is okay, has to be tolerated without comment, and is beyond criticism by those with differing views.
Just based on the value of fairness and that punishment should be decided in an actual court, not the court of public opinion or handed out by some guy named Brian, it is wrong regardless of where it occurs and I've made my reasoning for that pretty clear in this thread. I stand by that and you are still free to make some actual argument to the contrary. If the argument is just "in this country a lot of people feel it is fine", that's okay, just not very convincing to anyone I would imagine.
> Just because in some place a practice is considered to be okay (morally, whatever), does not mean ... [that it] has to be tolerated without comment...
Sure, I agree. If you were USian, I would defend to the death your right to speak openly and publicly about your concerns. [0]
And just because you feel strongly about your incorrect opinion about a widely-held-to-be-acceptable practice in USian journalism doesn't mean that I have to let that incorrect opinion pass by without comment.
It's a big world, and there are differing opinions on many, many things... morals (and the formation of explanatory systems overtop of the same) included.
[0] Whereas if you're in a more draconian jurisdiction that would prohibit such comments, I'll be publicly miffed about it and express my deep displeasure.
> Federal authorities have arrested and indicted a 20-year-old U.S. Army soldier on suspicion of being Kiberphant0m...
The article also claims to have spoken on the record with the accused's mother, so I have no reason to doubt the article's claim about the fellow's age.
Wait you have an API now??? Is it open, is there a waitlist? I’m on a plane but going to try to find that on the site. Absolutely loved your demo, been showing it around for a few months.
I’m surprised to find this on the 3rd or 4th page of Hacker News! It seems pretty impressive —- of course, the lack of code on GitHub might be partly responsible for that; there’s so much interesting AI stuff happening that an impressive page of results without either a detailed explanation, or an executable one, could easily fall through the cracks.
Me too! I came looking for this sort of meta-comment. I've re-read the paper book a few times now.
What makes it my favorite is how clear Norvig's writing is. It's easy to follow (both when reading it in English, and when following its execution if you're a programmer), and it introduces important ideas so effortlessly that, years later, it will give you a chuckle.
Anyone interested in clearly communicating about technical topics, and with a knowledge of Lisp's nature and some idea of what programming in 1991 looked like, might be tickled to read Chapter 1; even its first few paragraphs are refreshing.
They look pretty good, but I think it's responsible to hold off on calling them a success until they launch Neutron. From what I can tell, it's not very likely that they can be profitable with just Electron.
They're a heck of a lot more than Electron at this point. They're really in the satellite parts business at this point, with launch services as a side business. For the last two quarters, they made almost 2x as much on "Space systems" (solar panels, busses, etc) as they did on launch services. Launch is nice and visual so it gets all the attention, but it's only 1/3 of their revenue.
Ooh, LiveView pattern implementors! I have a question -- I've been tinkering with a custom Phoenix LV client in my 'shop time', so I wanted to ask: are you doing your diffs on a string-based representation, like they do in the internal Phoenix LV protocol? Or are you sending the DOM patches?
In the phx protocol, their diffs depend on having split the render into a tree of 'statics', 'dynamics', 'components',
and on each change, that structure is patched, and needs to be recursively zipped to a string, parsed into a DOM, and patches computed against the previous DOM.
I've been playing with a new client as a way of understanding it, and it's definitely a certain amount of work! Fortunately computing 'what needs to change to reconcile 2 html-like DOMs' is a project that's been wrapped into libraries a few times in a few languages (phoenix relies on other people having done that too, via the 'morphdom' library in JS, and Dockyard recently open-sourced an ergonomic Rust library I'm using in my client).
So -- it's a lot of client work, but it optimizes for bandwidth. Cool.
But I've wondered if there could be any benefit to optimizing for granularity of patches, and simpler clients -- by sending 'just the patches', ie the list of DOM operations that cause the desired end state. My intuition is that the bandwidth 'cost' would be prohibitive, because the list of patches required to perform the morph could be quite large for a change that appears small in 'what string has changed' terms. (maybe harder to debug, too? lots of trade-offs)
I just don't have the energy to try it that way too, hehe, on the off chance that my intuition is off base and it'd actually help improve things (simpler clients, and maybe the bandwidth hit wouldn't be too bad?); it'd require deep server changes as well, when up until now I've only been writing a client. So I was curious what approach y'all are taking.
Prior/related art in the Rust space: I know there's a non-Phoenix liveview project, 'dioxus', with a generic DOM liveview implementation that several clients have been created for, by making a state machine that operates on that list of generated Patches; however I don't know what that one sends, whether DOM patches directly, or Phx-style diffs that need to go phxDiff -> zippedUpString -> dom -> morphPatches -> applyToDom.
We take the Phoenix approach of splitting the DOM into static and dynamic parts. In fact, we even re-use the pheonix.js library on the frontend, so we just implement the backend part that speaks the same protocol as Phoenix.
I don't think that sending DOM patches directly would have a significant higher bandwidth cost, but it would have higher "implementation" cost for us. That's why we choose to just use an existing "battle tested" library.
Oh, hey that's great! So in your case, you're re-using the Phoenix client, and thus the Phoenix protocol lives on so as not to break that. Makes sense.
Thanks for the answer -- the current SDUI renaissance is a beautiful thing. Cheers :)
Didn't mean to distract from the main discussion either -- pre-emption is something that more people should want, I think, so y'all making it the default for WASM stuff feels super valuable. And surely the sandboxing is really valuable to some people too. (But day-to-day I probably won't use Lunatic, whereas LiveView-based SDUI is my current shop-time project).
Below a table, it says "adjusted for social deprivation index, hypo- and hyperthyroidism, and use of other antidiabetic drugs..." -- but nothing about obesity.
What if the GLP-1-prescribed patients tended to be more obese?