slabity

You cannot compare the raw thermal conductivity of a fluid like air (that pulls heat via convection) to a solid material like plastic (that pulls heat via conduction). Especially when the fluid is being actively moved with the intention of cooling down the plastic.

On top of that, the lattice structure of the infill will mean that heat will not conduct away from the channels well regardless of the material used.

But you can definitely get printers to dump a blob of filament out without worrying about cooling problems

Yes, but we're not talking about dumping a blob of filament. We're talking about injecting filament into a well-insulated channel where it's physically impossible for it to receive any active cooling whatsoever.

That's not a situation where you can just ignore cooling.

So I'm pretty skeptical about this as well (see my other comment on this), but the particular failure mode you're discussing is not what's happening in reality.

Anyone who has ever cleaned blobs of filament off of a nozzle after a print failure can tell you what happens when you try to pump hot filament into empty space. Filament cools below the melt temperature quickly, especially when it comes into contact with your print.

That's completely irrelevant because this isn't printing into empty space at all. This is injecting molten plastic into confined channels, with no active cooling, made from material that doesn't conduct heat well. You're saying that the plastic will cool too quickly, but I believe the opposite will be true.

The problem that the author is describing is that the plastic is actually far too hot when injected and causes wall collapse. This is because the author isn't taking into account that FDM walls don't handle the required pressure near/above glass-transition points.

The failure mode you're describing is the complete opposite. If you were correct, it would result in cold plugs or extruder jams. It wouldn't result in wall collapse or layer delamination.

I've seen this technique a lot, but mostly as a post-processing technique where resin, fiber, or some other type of plastic is injected into the channels after printing is completed. It would be interesting to see this done during the normal printing process.

I am a little skeptical on the technique though. FDM printed walls are known to not handle pressure well, especially during printing when its past its glass-transition temperature. This process essentially uses the pressure from the extruder to inject a channel with molten plastic. Will this pressure could cause the walls to delaminate from each other or deform?

And how does this affect plastic that tends to warp significantly during printing? The molten plastic is injected into insulated channels that will not receive any active cooling. You're also parking the nozzle at the injection points, which will cause a lot of uneven cooling at the surface as well. For high-warping plastics like ABS, that could cause a lot of issues.

So I guess the underlying question should be, does this actually work? What is the measured difference in tension strength between parts printed normally vs with MAGMA infills? Specifically when using the same amount of plastic. There's no data or even pictures that indicate this is working.

Automatic coding systems have way too much economic value to be considered a "fad".

Which is why they very carefully worded it more as 'LLMs in their current form', twice.

Don't Look Up is about ignoring expert consensus on a clear threat, not about rejecting benefits out of fear. For the analogy to land, you'd need overwhelming evidence that these data centers are net-positive for host communities, but that's exactly what's in dispute.

You're right that there's tension between 'not enough power' and 'no new heavy loads' but it's not hypocritical to argue that megawatts of power should be allocated towards 7k jobs rather than a few dozen if possible. That's exactly the kind of tradeoff a power-constrained state should be explicitly making. The logic behind it is not satirical, it's just triage.

On top of that, this is not a blanket ban of AI datacenters. It's a temporary blocking of any new datacenters that require more than 20 megawatts until late 2027 pending a PUC study on how these datacenters will affect their existing grid. It also creates a new council for researching and coordinating the creation of new datacenters, so this really doesn't seem like any sort of NIMBY action here.

Honestly the only major issue I have with the bill is that it neglects to distinguish self-powered facilities that don't provide much strain on the grid. Though it could be argued that water consumption of these centers might be the reason for it.

modern factories are often highly automated and also don't provide too many local jobs.

The factories in Maine employ thousands of people. Bath Iron Works alone has over 7k employees.

The Lewiston datacenter that was planned to be built was expected to employ less than 30.

OnlyOffice didn't distribute under a pure AGPLv3 license. They made modifications to it.

On line 655 here: https://github.com/ONLYOFFICE/DocumentServer/blob/master/LIC...

Pursuant to Section 7(b) of the License you must retain the original Product logo when distributing the program. Pursuant to Section 7(e) we decline to grant you any rights under trademark law for use of our trademarks.

And on line 17 here: https://github.com/ONLYOFFICE/DesktopEditors/blob/master/LIC...

Pursuant to Section 7 § 3(b) of the GNU AGPL you must retain the original ONLYOFFICE logo in the upper left corner of the user interface when distributing the software.

IANAL, but from the wording above it appears that OnlyOffice has modified it in a way that makes it impossible to fork as a new project.

1. OnlyOffice is claiming that the license was violated

The part of the license violated was the removal of OnlyOffice's trademark and branding. Yet their license does not provide a right to use their trademark and branding. Those rights are still fully reserved by OnlyOffice.

This allows OnlyOffice to use legal means to shut down any fork or changes they are not comfortable with.

The sharp edges are exclusively an issue with the Framework 16 due to the spacers that allow you to change the alignment of the trackpad. It's definitely been one of my main annoyances with my F16 that I didn't experience with my F13. I've been scratched by them and had my arm hair caught and pulled.

However, Framework has already indicated that they are looking into providing an input module that spans the entire width of the device to eliminate the need for the spacers.

I don't really know what the "creaking screen" is about though. IMO the F16 screen and hinges are a higher build quality than the F13. I had to upgrade my F13 hinges to the 4kg hinges to keep it from bouncing and moving.

Damn, I apparently missed the memo that the backend service for Mozilla Monitor was shady while I used it.

Are there any actual services like this that work properly? I've noticed whenever it indicated that a service has removed my data, that same service would come back online as having my data a few weeks later.

Acerola recently made a video about how Silk Song has banding with dark colors due to poor dithering (and how to fix it): https://www.youtube.com/watch?v=au9pce-xg5s

Highly recommend for any graphics programmer that might think dithering is unnecessary or simply a "aesthetic choice".

https://play.google.com/store/apps/datasafety?id=com.empiric...

Sorry for being pessimistic, it's just whenever I see a health related app I immediately look at the data collected and data shared sections and get concerned. Especially if it's being shared with insurance companies.

Quick edit: That "messages" part might be only in-app ones. Google does not word that well in the summary.

Looks more like an ad for your app though... Which for some reason collects tons of data unrelated to health, like messages, location data, and photos/videos/files?

You think that's bad? I had my own Google Workspace account with Google Domains and then foolishly linked my Google Fi cellphone to it.

Trying to get that stuff resolved was such a pain that I eventually had to ask a friend who knew someone that worked at Google for assistance. Their support team had absolutely no public contact info available. I eventually managed to get my data and migrate the services I actually use (Google Fi and Youtube) to a non-workspace account.

The funny thing is that a few months later they tried to send a $60 bill to collections because they reopened the account for 2 days for me to migrate things off. I was originally going to pay it to just get them off my back, but Google's own collections agency wouldn't let me pay through card or check or anything. The only way I could pay was to "Log into your Google Workspace account" which NO LONGER EXISTED.

Now it's just an amusing story about incompetence to look back on, but at the time it was stressful because I almost lost my domains, cell phone number, and email addresses all at once. Now I never trust anything to a single company.

The internal pull-downs don't work.

They don't work at all? How the heck did something that important get past testing?

Guess I'm not moving on from the RP2040 anytime soon...

I just got a chance to see this video now.

Thank you for sharing this with me. This is the first time I've seen the `rnote` app on an E-ink device. I'm quite surprised in how functional it looks, though I can already tell the latency is quite high.

I'm definitely going to keep my eye on this device though. I think it will just be a few more years before the software has caught up with the hardware.

I think there may be a misunderstanding of my point.

The fact that GNOME works well on typical tablets isn't really relevant here. The PineNote is an E-ink device with very specific hardware constraints and use cases. It's primarily meant for reading and writing, and these tasks require software specifically optimized for E-ink displays and low-power operation.

I've personally experimented with desktop environments like XFCE and i3 on a reMarkable 2. While it was an interesting technical exercise, the experience wasn't practical for daily use. For comparison, look at the reMarkable's unofficial/hacked ecosystem (https://github.com/reHackable/awesome-reMarkable) - it's full of applications and utilities specifically designed for E-ink displays and writing/reading workflows.

This is why I'm hesitant about the "community device" designation. Simply saying "it runs GNOME" doesn't tell us anything about the actual user experience for reading and writing on E-ink. To be clear, my concern isn't that it runs GNOME - it's that this seems to be the only information available about the software experience.

I've been interested in the progress of the PineNote since the reMarkable company decided to put certain advertised features behind a subscription paywall.

Does anyone have any information on the OS being developed looks like? I have not been able to find any videos or screenshots that indicate what interacting with the device is expected to look like. I found this blog post here, but it shows it running a GNOME environment which is... Not at all what I would hope for in this type of device: https://pine64.org/2024/10/02/september_2024/#pinenote

Note: Determinate Nix is not a fork, it is a downstream. Our plan, and intent, is to keep all our patches sent to the upstream project first.

And what happens if the Nix community doesn't pull those patches, and instead goes with a different solution? Will your downstream adapt to the upstream project, possibly breaking things for your customers?

Even if the OS could perfectly deduplicate pages based on their contents, static linking doesn't guarantee identical pages across applications. Programs may include different subsets of library functions and the linker can throw out unused ones. Library code isn't necessarily aligned consistently across programs or the pages. And if you're doing any sort of LTO then that can change function behavior, inlining, and code layout.

It's unlikely for the OS to effectively deduplicate memory pages from statically linked libraries across different applications.

Not to nitpick too much, but while wood is "technically" a composite material made up of fiber embedded in lignin, I don't think it's very useful to include it under the broad category of composite materials. Engineered woods like plywood and cross-laminated timber definitely are, but it's more useful to classify regular wood as an organic raw material rather than a composite.

Why would defining it as a raw material be "more useful"? Why is defining it as a composite "less useful"?

But there's a GIF in the very first section of the README showing a bunch of different effects. What else is it missing?

Wow, that's some convenient timing. That makes pretty much the sole reason I wouldn't recommend FreeCAD irrelevant.

FreeCAD has improved immensely over the past 2-3 years in terms of stability and features. A decade ago it was not uncommon for me to experience crashes from it randomly losing its GLX context or the constraint solver segfaulting for some reason. Now it's rare for it to crash at all for me, though I still run into a lot of constraint solver errors that are a pain to deal with.

However, despite the recent improvements, I still cannot recommend it for new users compared to commercial solutions for the sole reason of the Topological Naming Issues: https://wiki.freecad.org/Topological_naming_problem

This issue has been probably the #1 problem I've had with FreeCAD since I started using it. And though I've learned how to design parts to get around the problem in most situations, it's a huge hurdle for newcomers to understand and get around. Luckily there's a fork that fixes a significant number of the issues: https://github.com/realthunder/FreeCAD_assembly3 and https://github.com/realthunder/FreeCAD

I've also heard of Ondsel, which is supposedly a much more user friendly version of FreeCAD that also includes some fixes to the issue: https://ondsel.com/

EDIT: Here's actually a better read of the topological naming issue, what's being done about it, and why it's difficult to fix: https://ondsel.com/blog/freecad-topological-naming/

It sounds like it should have been worded like, "Minimize cognitive load to maximize team effectiveness"

The original wording sounds like could go both ways, so I understand why the person you're responding to sees it that way.

Did you ignore this part that came a bit before that?

I decided to map the file into the address space instead of reading all of it. By doing this, we can just pretend that the entire file is already in memory and let the poor OS deal with fitting a 40 GB blob into virtual memory.

Why take a vaguely rhetorical statement and then complain it contradicts a more concretely accurate statement before it?

Other than power consumption, is there any reason to prefer a single workstation card over multiple consumer cards then?

A single $6800 RTX 6000 Ada with 48GB of VRAM vs 6x 7900XTX with a combined total of 144GB of VRAM honestly makes this seem like a no brainer to me.

The selling point is described quite well under "The Pitch" section of the README.

Unlike most other toolkits, this one doesn't actually handle its own rendering/contexts. It outputs the low-level vertex buffers and textures that you can pull into your own graphics pipeline. Which means you can integrate it into any sort of 3d application or backend that you want.

Or worse, a small player developing something and then finding out after the fact that a junk patent prevents them from even selling the thing to begin with.