No need to worry about thieves. They mostly don't even steal laptops of TVs. It's just not worth the work and the risk.
Yes need to worry about floods or your house burning down. That's the real way to lose a home server.
- Posts
- 4
- Comments
- 1452
- Joined
- 1 yr. ago
- Posts
- 4
- Comments
- 1452
- Joined
- 1 yr. ago
In the middle of the print change the flow modifier to 0%.
That will turn off the extruder while leaving everything else as-is.
I suspect it's the X or Z bearings.
Please don't sand anything. If your problem is wear, adding wear will not help.
Another thing you can do is move the print head up, and while not printing anything just extrude 100mm of filament. Then you will only hear the extruder.
The only thing in the extruder that I would expect to make a noise like that would be if it's a geared extruder with seriously abused gears that are slipping. But then you'd see extrusion problems.
In general, the extrusion motor should be way to slow to create such high-frequency noises, unless your motor control is seriously wrong setup.
Unlikely that it's the stepper. It sounds like something's scraping. I heard similar noises after inconsistent extrusion on infill, so that the infill was standing up a little bit and the print head was scraping over it.
Could also be ball bearings or something else in there that's scraping over something. It is most likely something connected to the motion.
It's kinda crazy to me that people want to "live in nature" and what they do is live in a suburb with their paved roads and fenced lawns that are biologically dead. They have some grass and that's it. Nothing lives in there.
In the EU there's a limit on how much pedal assistance an e-bike is allowed to provide (250W). There is no limit on how much pedal assistance an exosceletton is allowed to provide.
Ok, then a sled/bob tour.
We are doing that post hoc. We have enough issues thanks to him that actually do go to production and now we are escalating again. Lets see what happens.
Look at how Vienna works. Contrary to other places, they did government housing blocks really well there.
- The blocks are spread throughout the whole city. That means, there's no really bad place where all the undesirables are concentrated. This mixes the population. For example, I went to a school in one of the inner districts. In my class we had fresh immigrants that could hardly speak German. We had kids from poor families. We had middle class kids. We had kids who's parents were immigrants but who were born there. We had a kid who's parents played in the Vienna Philharmonic. We had two really rich kids descending from former nobility. We had a kid who was the son of a well-known lawyer.
- The blocks do have an income limit when you get the flat, but that limit is very high (it easily covers everyone in the middle class) and it only applies when you move in. If your income increases afterwards you can still stay in that flat and still pay the same as anyone else. That means that you got a decent mix of people living in these blocks. There's not only poor people there.
- Most of the blocks are actually really nice. There's parks between the blocks with nice, old trees. Many of the blocks even have swimming pools or other special extras.
Check out for example this one here: https://en.wikipedia.org/wiki/Alterlaa
It can be done well. It doesn't have to be crap.
It's basically a whole city in a building. The big advantage for this is that the city is not taking up massive amounts of space.
American Fork, Utah, has 33k inhabitants on 19 square kilometres. The building in the OP has 20-30k inhabitants on 0.04 square kilometres, which would mean that if you house all of American Fork like that, you'd get between 18.92 and 18.96 of untouched nature in return.
What I find more crazy than a ship being able to carry around a dozen ships is that each of the ships lower in the stack are built strong enough to carry four other ships on top of them even though they aren't built for that use case at all.
Imagine stacking 5 cars on top of one another and the bottom one getting out of that without any damage.
The problem with the concept of a world police is that it's a political thing, not a law and order thing.
A political world police is just as good as a political regular police would be.
Imagine, police would just do whatever the majority are saying instead of, you know, using evidence to get someone before a judge and continue to use evidence to get someone convicted or alternatlively let people go free where there's no evidence.
ICE is pretty much what a political police looks like, and the US as the world police acted just like that.
Remember 911? Attacking Afghanistan might have maybe been somewhat justified, but attacking Irak, mostly because US troops were already there was totally not.
The "world police" was certainly not a successful thing and certainly not in regards to world peace. More often than not it was used to score points for the next national election.
My experience with embedded Linux was mainly working on some Linux-based SDN switches between 2014 and 2020. The jump from Linux kernel 2.6 to 3.x increased the memory consumption quite a lot. I honestly don't know if that improved since, but for desktop Linux the kernel got bigger, not smaller, in the meantime.
We really struggled fitting a small Web.py webserver and a process that communicates with the SDN system into the 128MB RAM. Especially using Python 3.x instead of 2.7 (had to switch due to EOL) bumped up the memory requirements.
I guess that is a reasonable point about longer term support for those CM's though that seems like a tragedy of the ARM ecosystem in general. The 2011-era x86 laptop I'm using right now runs current Debian just fine.
Yeah, I don't know what's up there. Intel isn't supporting my ancient 2010 netbook either and yet Antix works just fine on it. But apparently, for ARM someone needs to manually provide drivers for every device individually or something.
Maybe it's a device tree vs UEFI thing? Or maybe nobody working on the Linux kernel can be bothered supporting ARM natively? It's certainly weird.
It seems to me that most people use cooling fans on the Pi 5. I wonder if the 500/500+ need that.
Do you know if I can use the M2 hat on a regular 500? I mean this: https://www.adafruit.com/product/6427
I don't have a 500, but according to this, you need to populate an unpopulated M2 slot and some power management components.
Is the ESP32-P4 SPI memory painfully slow compared to the on-chip memory? Is there CPython for it? Having 32MB makes those MCU's interesting for some things that would have been beyond their capabilities otherwise.
Not painfully slow. With stock settings they have a 80mhz 16bit parallel connection. The internal RAM has 200mhz, can't find how many bit parallel though. At least on the S3 the PSRAM can be clocked to 120mhz, I think it's the same on the P4, but I don't know.
On my handheld physio game console, it's fast enough to keep the framebuffer there.
The two-layer cache probably also helps in that regard.
Unrelated, for something else I'm semi-involved with: do you know what is around these days in small cheap MCU's comparable to midrange AtMega? Let's say 16K of program flash and 2K of ram. Right now we use AtMega but those are fairly expensive. The application is a flashlight controller (toykeeper.net/anduril) so the hardware is cost sensitive. I've been wanting to look into porting to the WCH CH32V003. There is also a new much more powerful CH570 that lacks ADC's. I'm wondering what else is out there. I write embedded software sometimes, but I'm not a hardware guy.
I do have some experience with the ESP32-C3. It's much more powerful than your requirements while being much cheaper than the Atmega168p.
But I'm sure there's even cheaper stuff.
I have only Atmega/Attiny and ESP32 experience, can't really say much about other platforms. I'm sure there are some cheap STM32 around.
You can run Python just fine in 64MB (were you thinking 64KB?). I've written substantial multi-threaded Python applications on boards like that. It used to be a lot of memory! But increase it if you want. You can run Micropython pretty comfortably with 64KB by the way. CPython might need more like 1MB, idk.
With a full Linux with a somewhat modern stack? In the 2000s, sure. In 2025? I doubt that.
On https://www.espressif.com/en/products/socs/esp32-p4 it says 768K. 32MB might be possible with SPI ram.
Yeah, like I said: the SPI RAM (also called PSRAM) is in-package. It's not a separate package, but integrated inside the ESP32-P4 package. It's only called SPI RAM because internally the ESP32 transparently connects to it via SPI.
The OS actually does useful things (multiple processes with memory protection) which is the point of wanting to run it instead of an MCU.
The ESP32 family utilizes FreeRTOS which gives you multiple processes, but sadly no MPU.
Just depends if you really need memory protection on such a tiny devices. I guess, some use cases need it, but I wouldn't think too many.
Yikes, that is pretty expensive, considering that most cheap Android phones have way more compute power AND a phone with a display etc.
Raspberry Pis in all shapes (except maybe the Zero line) are pretty expensive for the hardware.
But you buy long term support. There's hardly any other SBCs with nearly that level of software and hardware long term support. They sell each of their devices for around 12 years and give software support for at least that time. For low-quantity production, that's amazing.
At a prior job we designed an optical network bypass tap with a CM3 in it to provide a REST api and a Web UI. It was so simple to build all that and the 12 years of support meant that we didn't have to redesign anything over that time.
Most other SBC manufacturers are quite spotty with their LTS and their long-term hardware availability.
Plus of course there is the whole Pi Zero series. Shouldn't these CM's cost less rather than more?
The cheapest Pi Zero 2W (which is technically identical to the CM0) costs €17.80, which is a bit more than the $18 minimum price from the announcement. The more expensive variant of the CM0 ($26) includes EMMC storage on board which replaces the SD card. €8 isn't exactly much for a large SD card.
At that point I'm not sure if there's a point running Linux on such a small device. With 64MB RAM, you won't even be able to run a Python interpreter, let alone any useful services.
You'd probably be better off using a microcontroller. The ESP32-P4 for example has up to 32MB in-package RAM and can deal with extra external SPI RAM.
Without the overhead of running a Linux Kernel, you might even get more performance out of that.
Reasonable points about the CM boards but I don’t see much attraction of the CM0 vs CM4 or CM5. Given that they aren’t after cost minimization, might as well take the extraperformance.
The CM0 is smaller and consumes much less power than a CM4/CM5. It's also way cheaper. They give a range of $18-26, probably depending on how much storage is on there.
In my region the CM5 is €50-€150 and the CM4 is €32-€102. That's a huge difference.
So if you just need a small, low-power compute unit for a cheap handheld device, the CM0 really does make sense.
All the CMs are quite similar to regular Pi boards, just with optional on-board storage and in a form factor that lends itself to smaller integration. They are mostly used for industrial purposes or at least for people who can make their own PCBs.
Remember, that image above shows the CM0 soldered onto a generic IO board, which is only used as a demonstration platform for what (and how) can be done with the CM0.
The CM0 is only that small PCB soldered on top of it.
That form factor is much better for industrial purposes than the original Zeroes because it's smaller, contains storage (so no finnicky, easy to break SD cart that you need to factor into the cost as well) and the castellated holes are much easier to solder automatically or at scale than through holes. And easier to route connections to and from as well.
Also the CM0, like the other CMs doesn't contain its own power regulation because it expects that the carrier project already has its own power management, thus reducing the efficiency penalty of doubled up power management.
If you don't know what to do with the CM, then it's not for you. But if you do know what to do with it, it's one amazing device.
One thing I would want to make with this is a tiny, super slim handheld computer with a keyboard or a small, slim emulation handheld.
Edit: Tbh, I don't think this could get much smaller, at least not with the ICs they are using. Sure, it would be amazing to have a Pico-form-factor device with pico power consumption and Pi5 performance for €5, but at least for now that are some quite unrealistic targets. Maybe wait another 15 years for that.
There are a lot of top-to-bottom languages in Asia. Some chinese languages for example are traditionally written top to bottom.
Bidirectional text only really occurs when mixing languages, like in the example above where RTL Hebrew is mixed with LTR English (or in this case specifically LTR file paths that have originally been created in the context of an LTR language and thus are LTR).
If there was actual TTB language support in Windows Explorer, and you had a file path incorporating both TTB file names and LTR file endings and drive letters, then you'd also have the same issue with mixing LTR and RTL, only that you are now mixing writing directions in two dimensions.
But I'm guessing even though Unicode's stated goal is to encode all writing, TTB is probably where they drew the line.
A lot of the systems are quite stabilized. No need for a new OS, a new browser, a new language.
Even if the old stuff isn't perfectly optimal, having to setup a fully-new ecosystem is so incredibly costly that it's just not worth it.
That's why you see new developments (e.g. Typescript or Kotlin) piggyback on older ecosystems (e.g. JavaScript or Java compatibility).
Typescript could have been better if it was a completely fresh development without being encumbered by the madness that is JavaScript. But without JavaScript compatibility and thus acces to the JS ecosystem, nobody would have switched to TS.
All these systems heavily benefit from network effects, which makes it hard to impossible for completely new systems to emerge.
This is doubly strong for consumer-facing software. Linux only became a viable mainstream option due to Wine/Proton/... allowing users to easily run Windows programs. Without Windows compatibility, Linux would still be at <1% desktop market share.
It's also the same reason why everyone's making chromium-based browsers: Because that way they all work the same.
Disruptive change happens when you get a completely fresh use case. Microsoft completely destroyed the likes of Commodore and IBM when home computers became something that everyone had in their homes.
Smartphones becoming mainstream allowed Google and Apple, who were both completely new to the mobile OS business, to win against established mobile OS companies, because nothing was entrenched in the late 2000s mobile OS landscape.
OpenAI, Anthropic, Midjourney and so on are wiping the floor with established software powerhouses in the AI space.
But after the disruption follows stabilization. A product that has reached market saturation will only be replaced by incremental, compatible improvements.