Language Selection

English French German Italian Portuguese Spanish

Moving A GNU/Linux Installation To A Different Partition

Filed under

When I had first installed the Gentoo GNU/Linux operating system, my initial plan was to use it just for a couple of weeks before overwriting it by installing some other new distribution from Distrowatch. But I started to like it so much in less than a month’s time that I replaced Debian Sid with Gentoo as the primary operating system on my personal desktop(the server still runs Debian Sarge). Almost an year now, I haven’t regretted the decision ever. What I did regret a few days ago, though, was the amount of disk space that I had allotted for Gentoo during its installation - a meagre 11GB partition! Mortals like me lack the foresight required in such situations.

I had never considered ‘moving’ an installed operating system to a different location until then - I thought it to be such a lousy way to lose the oppurtunity for a fresh installation of the OS from the scratch(avoiding the mistakes that were committed the last time). But installing a Gentoo system from the sratch! Heavens forbid. It had taken 3 days for me to get the a bare minimum Gentoo system up and running, nothing more than the GNOME desktop manager. Another 4-5 days to install the most basic applications. I was not prepared at all to go through similar 1 week of downloading, compiling and installing the packages again by starting from the scratch. I decided to move my existing Gentoo system to a new, bigger partition. Not just the data but the entire bootable operating system.

Full Story.

More in Tux Machines

Super long-term kernel support

In the longer-term, CIP is looking toward IEC-62443 security certification. That is an ambitious goal and CIP can't get there by itself, but the project is working on documentation, test cases, and tools that will hopefully help with an eventual certification effort. Another issue that must be on the radar of any project like this is the year-2038 problem, which currently puts a hard limit on how long a Linux system can be supported. CIP is working with kernel and libc developers to push solutions forward in this area. Read more

LibreSSL 2.7.1 Released, OpenSSH 7.7 Being Tested

today's howtos

Programming: Python 2.*, Functional Computation, and Plagiarism in CS

  • 1.5 Year Warning: Python2 will be End of Lifed
    The end of upstream Python 2.7 support will be January 1, 2020 (2020-01-01) and the Fedora Project is working out what to do with it. As Fedora 29 would be released in 2019-11 and would get 1.5 years of support, the last release which would be considered supportable would be the upcoming release of Fedora 28. This is why the current Python maintainers are looking to orphan python2. They have made a list of the packages that would be affected by this and have started a discussion on the Fedora development lists, but people who only see notes of this from blogs or LWN posts may not have seen it yet.
  • Why is functional programming seen as the opposite of OOP rather than an addition to it?

    So: both OOP and functional computation can be completely compatible (and should be!). There is no reason to munge state in objects, and there is no reason to invent “monads” in FP. We just have to realize that “computers are simulators” and figure out what to simulate.

  • Why we still can’t stop plagiarism in undergraduate computer science

    The most important goal is to keep the course fair for students who do honest work. Instructors must assign grades that accurately reflect performance. A student who grapples with a problem — becoming a stronger programmer in the process — should never receive a lower grade than one who copies and pastes.


    University administrators should communicate their support. Instructors should know that, not only will they suffer no retaliation, but that the university encourages them to enforce university policies. This might require administrators to acknowledge the inconvenient truth of widespread plagiarism.