It’s an Apple Silicon Mac Mini. Do you have a particular reason to think the new one is less efficient?
It’s an Apple Silicon Mac Mini. Do you have a particular reason to think the new one is less efficient?
I do think it can achieve that while waiting for network packets (see e.g. https://www.anandtech.com/show/16252/mac-mini-apple-m1-tested).
But in terms of money savings it would rarely make sense, as you need to make it back during the time you run the system. If we assume 6 years lifetime then it would only make sense to pay $120 more. But yes, I’d also go for a system that runs regular Linux :)
I don’t have one (and I don’t want one), but Anandtech measured the M1 version at 4.2W in idle. https://www.anandtech.com/show/16252/mac-mini-apple-m1-tested I think you can also get that from other Mini PCs (e.g. NUCs).
I would disagree with idle power not being important for a home server. Most of the time, your system will be doing very little and wait for something to happen. I also don’t think a typical server has a display attached. Wolfang explains this quite well: https://youtu.be/Ppo6C_JhDHM?t=94&si=zyjEKNX8yA51uNSf
I don’t have a Mac Mini, but for always-on systems, the idle power consumption can become quite significant.
If you pay 0.30$/kWh, running your old 100W gaming PC all the time would cost you 263$ per year. My NAS is 45$ per year…
It also depends on what you need/want from the machine. The Mac Mini doesn’t have any HDDs and can’t run a regular Linux distro, for example.
This seems very one-sided. Sure, the disclosure was not handled perfectly. However, this post completely ignores the terrible response by the CUPS team.
The point on NAT is certainly fair and prevented this from being a much bigger issue. Still, many affected systems were reachable from the internet.
Lastly, the author tries to downplay the impact of an arbitrary execution vulnerabilty because app armour might prevent it from fully compromising the system. Sure, so I guess we don’t need to fix any of those vulnerabilities /s.
I think when I messed it up, it worked when I tried switching to the proprietary drivers for the second time. I think you can try that without much risk.
In my case I ended up disabling Secure Boot anyway because it just got too annoying (a BIOS update breaking it was the final straw for me). The security benefit after you’ve enrolled a MOK seems dubious anyway. It would be nice if distros could ship signed kernels with the open-source Nvidia driver but I guess that’s not happening.
No, they’re almost entirely unrelated. Almost all CPUs will idle close to 0 W (with correctly working drivers). The main idle power contribution comes from the mainboard and other devices (e.g. disks). The Mini PCs you mentioned should have a very low total idle power, probably below 10W.
Check out Wolfgang on YouTube, he has some great videos on the topic: https://youtu.be/Ppo6C_JhDHM
I’ve also recently built my own NAS and I’ve gone through similar considerations. One of my mayor decisions was not to use btrfs because it’s not recommended for Raid Z1/Raid 5. With that, I landed on ZFS and TrueNAS Scale. Note that RAID expansion should be landing in both very soon.
Things with TrueNAS were pretty easy, very quick, and everything worked nicely. However, I noticed that it was constantly accessing the disks and preventing them from spinning down. I really wanted to keep the power consumption low (<20 W idle), so I eventually decided to just go with Vanilla Debian + ZFS. I can recommend that if you want to tinker with things yourself. Otherwise, I’d recommend TrueNAS Scale.
As for migration, you might be able to create a degraded pool initially, copy over the data, and add the parity disk last. Raid expansion would ofc also help there…
Did you perform a full shutdown of Windows (Windows doesn’t fully release the partition on a normal shutdown)?
The driver should already be installed but there seems to be an issue with brltty
registering the corresponding USB ID when they shouldn’t. You can probably fix it by following this guide: https://koen.vervloesem.eu/blog/how-to-stop-brltty-from-claiming-your-usb-uart-interface-on-linux/ (or this one: https://unix.stackexchange.com/a/670637)
Edit: Perhaps this has since been fixed in Mint 21 / Ubuntu 22.04.
You can make this work using ext and Timeshift rsync. I have also opted to exclude /var/lib/flatpak/
because it’s quite large. With that, my 5 snapshots currently take up about 34 GB.
However, I would recommend backing up your deb applications/packages (typically installed under/usr
), as those can be critical for your system.
This “new law” was passed more than a year ago… But, it’s still a step in the right direction.
Jeder der nicht exakt der gleichen Meinung ist sofort ein Atomtroll?
Ich würde den Atomausstieg nicht auf ein Einziges Jahr beziehen, sondern auf einen Prozess der gut 20 Jahre gedauert hat. Wikipedia scheint das ähnlich zu sehen:
In Deutschland begann der Atomausstieg unter der ersten rot-grünen Bundesregierung (Kabinett Schröder I) mit der „Vereinbarung zwischen der Bundesregierung und den Energieversorgungsunternehmen vom 14. Juni 2000“. 2002 wurde der Vertrag („Atomkonsens“) durch Novellierung des Atomgesetzes rechtlich abgesichert.[120] In der Folge wurden am 14. November 2003 das Kernkraftwerk Stade (640 MW)[121] und am 11. Mai 2005 das Kernkraftwerk Obrigheim (340 MW)[122] endgültig abgeschaltet.
dass Deutschland auch vor dem Atomausstieg nur einen einstelligen Prozentsatz des Stroms aus den Atomkraftwerken gedeckt hat. Es
Hast du eine Quelle dazu? Der Anteil war vor 2000 wohl bei knapp 30% der Stromerzeugung: https://ourworldindata.org/grapher/share-elec-by-source?country=~DEU
I understood Matthew’s position as “this should be discussed in the Workstation WG first”, not as a “no”:
in favor of the process outlined above (tl;dr: talk to the Workstation WG, and if that does not come to a satisfying outcome, file a Council ticket for next possibilities).
It also seemed more likely that they would promote KDE without demoting Gnome.
But was there a follow-up on that (e.g. in the Workstation WG)?
It seems that 18.04 was the last release for 32-bit x86 (i386): https://askubuntu.com/questions/1376090/latest-version-of-ubuntu-for-i386-architecture-32-bit
But you could just go for Debian which still supports it.