Is it OK to simply dd the 128GB disk to the 32GB disk using count to stop after the 16GB partition was cloned?

I think it would work, but it seems a little overcomplicated, you can just use the partition paths as if and of of dd directly, as long as the output partition is not smaller than the input partition. For example dd if=/dev/sdc1 of=/dev/sdd1 bs=4M status=progress

Your method would also copy the partition table I suppose, which might be something you want under specific circumstances, but then it would be a little harder to get the count right, just taking the size of partition 1 would be wrong, because there is some space before it (where the partition table lives) and dd would start at 0. You’d need to add up the start position and the size of partition 1 instead.

Personally I would prefer making a new partition table on the new eMCC, and create a target partition on it. Then you clone the content of the partition (i.e. the file system). This way the file system UUID will still be the same, and the fstab should still work because these days it usually refers to mounts by filesystem UUID in my experience.

If you make the target partition larger than the source partition, and you intend to use the full partition going forward you will additionally need to resize the filesystem to fit the new larger partition, for example with resize2fs.

In laptops the internal screen is usually attached over embedded Displayport (eDP) could be the same here. “native” doesn’t really say much.

Astronauts on the ISS are currently zipping along at at 7.67 km/s just fine.

And we’ve all been zipping around the sun at 29.78 km/s since each of our inceptions.

Since the thread has grown large and I had trouble finding the comment I’ll just link it here (sorry the link is instance specific, it seems you can’t make relative ones)

I checked Wikipedia real quick:

The Los Angeles Metro Rail is an urban rail transit system serving Los Angeles County, California in the United States. It consists of six lines: four light rail lines (the A, C, E and K lines) and two rapid transit lines (the B and D lines)

Looking further, since this happened in Boyle Heights, and only Line E runs through there, it must have been a Kinki Sharyo P3010. The empty weight of one car is 45t. On pictures I can see there were three cars, so 140t (plus content) were pushing forward there. But only the first half in front of the articulation point of the first car derailed. Looking at the schema picture on the bottem here (PDF) it looks like there are three bogies. So I guess we can assume roughly 15t (plus content) would need to be bounced off the track.

I’ve seen the result of the same thing happening here in Zürich to our Bombardier Cobra light rail which weighs 39.2t. So I’m not that surprised anymore, but it is still impressive.

How old is that dickhead again? Only 60? What a shame.

Maybe some Lua, as a treat?

If Qt or Java is doing it, then that’s still your program and not the WM, though?

deleted by creator

The server is used for hole punching, to open up a P2P connection thorugh NATs and Firewalls. If it doesn’t work the server also relays the traffic between the clients.

Getting an end to end connection through todays internet is unfortunately not easy for an average user.

Using modern UEFI booting with a 1GB shared ESP and grub2 has worked just fine for me in the last 8 years. os-prober has always just found the Windows install and generated the necessary boot entry for grub. Windows has never trespassed into the Fedora or Ubuntu folder of the ESP as far as I can tell.

A microkernel teaching OS by Andrew S. Tanenbaum.

In 2017 the world (including Tanenbaum) found out that the Intel Management Engine uses Minix internally. Intel just kind of did that silently. So Minix is still around.

nix-darwin is kind of nice too, but only really for CLI tools. You can let nix-darwin manage your homebrew for GUI stuff, if you want.

I’d still take linux if I could though. macOS is just work mandated.

Mine sure doesn’t. I send it to sleep (since you can’t send it directly to hibernate like a normal OS), and the next day the battery is empty and it won’t start. This happens about once a month, and I haven’t found the common variable yet.

I wrote a script to turn the power of the the Wifi+Bluetooth chip off, then enumerate the PCIe bus again to start it back up.

The chip sometimes hung itself when using both. I looked for the bug and even found an Intel engineer on some mailing list admitting that they had issues with coexistance mode.

Just turning the wireless off and back on wasn’t enough I needed to reeinitialize the hardware and that was the best way I knew.

Programming in C and C++ just seemed way easier on Linux at the time.

The assistants at university would frequently distribute virtualbox images with Ubuntu within which we were supposed to do the homework. At some point I decided that just putting Ubuntu on my laptop directly would be easier because GCC is just right there in the repos, plus I was a little interested anyway.

Then it just kept being easy, for Java, Haskell, Scala, Python, everything was just supported nicely. The network simulators we used were Linux native, the course where we were reverse engineering binaries used GDB, Android development was simple with the tools and simulator being in the repos.

That said for gaming I still use Windows. And my workplace forces me to use macOS.

If you prefer being right, rather than just accepting the extra information, then sure let’s go with that.

Not out yet.

Actually the 0x129 microcode was released yesterday, now it depends on which motherboard you have and how quickly they release a bios that packages it. According to Anandtech Asus and MSI did already release before Intel made the announcement. I see some for Gigabyte and Asrock too.

https://community.intel.com/t5/Processors/Microcode-0x129-Update-for-Intel-Core-13th-and-14th-Gen-Desktop/m-p/1622129/highlight/true#M76014

They said the cause was a bug in the microcode making the CPU request unsafe voltages:

Our analysis of returned processors confirms that the elevated operating voltage is stemming from a microcode algorithm resulting in incorrect voltage requests to the processor.

If the buggy behaviour of the voltage contributed to higher boosts, then the fix will cost some performance. But if the clocks were steered separately from the voltage, and the boost clock is still achieved without the overly high voltage, then it might be performance neutral.

I think we will know for sure soon, multiple reviewers announced they were planning to test the impact.

He looks ridiculous. Can’t believe people take that position seriously still.