Announcement

Collapse
No announcement yet.

When does Kde neon

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    When does Kde neon

    based on LTS Bionic Beaver? Right after the release or much later?
    Last edited by Snowhog; Mar 20, 2018, 01:42 PM.

    #2
    KDE Neon is not about kernels, it is "The latest and greatest of KDE community software packaged on a rock-solid base." That base is currently Ubuntu 16.04 base. I don't know what their next base will be but my assumption, and choice, would be 21.04.
    "A nation that is afraid to let its people judge the truth and falsehood in an open market is a nation that is afraid of its people.”
    – John F. Kennedy, February 26, 1962.

    Comment


      #3
      They definitely plan on using 18.04 a base, but have no timeline for it.

      Sent from my LG-H931 using Tapatalk

      Comment


        #4
        Originally posted by claydoh View Post
        They definitely plan on using 18.04 a base, but have no timeline for it.

        Sent from my LG-H931 using Tapatalk

        I just checked the EOL for 18.04 and it is a 5 year LTS. Given the favorable buzz about it, and its LTS nature, I am looking forward to it. My current EOL status is:
        :~$ ubuntu-support-status
        Support status summary of 'jerry-Aspire-V3-771':

        You have 60 packages (2.1%) supported until April 2021 (Community - 5y)
        You have 1611 packages (56.7%) supported until April 2021 (Canonical - 5y)
        You have 204 packages (7.2%) supported until April 2019 (Community - 3y)

        You have 10 packages (0.4%) that can not/no-longer be downloaded
        You have 954 packages (33.6%) that are unsupported
        The "--show-all" option gives the entire scoop.
        "A nation that is afraid to let its people judge the truth and falsehood in an open market is a nation that is afraid of its people.”
        – John F. Kennedy, February 26, 1962.

        Comment


          #5
          Originally posted by GreyGeek View Post
          I just checked the EOL for 18.04 and it is a 5 year LTS. Given the favorable buzz about it, and its LTS nature, I am looking forward to it. My current EOL status is:

          The "--show-all" option gives the entire scoop.
          te he ,,,,ya I get "You have 1073 packages (34.6%) that are unsupported" which of course includes ALL the kf5 and plasma stuff as ,,,,it's neons not ubuntu's

          VINNY
          i7 4core HT 8MB L3 2.9GHz
          16GB RAM
          Nvidia GTX 860M 4GB RAM 1152 cuda cores

          Comment


            #6
            Thanks for the reply. I prefer KDE Neon, but unable install to second PC. Kde Neon iso from 22-Mar-2018 10:34 every time crash before end installation. "Grub instalation problem". PC is with UEFI. Kubuntu Bionic without problem...

            Comment


              #7
              Originally posted by Pepan View Post
              Thanks for the reply. I prefer KDE Neon, but unable install to second PC. Kde Neon iso from 22-Mar-2018 10:34 every time crash before end installation. "Grub instalation problem". PC is with UEFI. Kubuntu Bionic without problem...
              Is secure boot disabled?

              Comment


                #8
                Latest comment from Jonathan Riddell (with some redaction for privacy and brevity):

                ---------- Forwarded message ----------
                From: John~
                With the Ubuntu 18.04 GA release just under a month away I am curious what the update process will look like for existing system and when a Neon 18.04 release will be available for fresh installs.

                I believe that the default Ubuntu behavior is to leave existing LTS installs alone until the first point release (18.04.1) which comes 3 months after the .0 release. Will Neon behave the same way?

                I believe that it is possible to force the upgrade to the new LTS prior to the first point release. When might one expect all of the neon packages to be in place for an upgrade to Neon 18.04? What is the recommended place to watch for announcements about Neon 18.04?

                In addition to my existing systems I'm in the process of obtaining a new machine. I'll be performing a fresh OS install when it arrives. Will an updated installation ISO likely be one of the first things that rolls out or will I be better served by installing Neon 16.04 and doing an in place upgrade when Neon 18.04 is available?

                Is it appropriate to call this Neon 18.04 or is there some other preferred name.

                p.s. I really appreciate the work that you guys do in putting this release out; its great.

                -john


                ---------- Forwarded message ----------
                From: Jonathan Riddell ~
                To: Discussion of the KDE neon project <neon@kde.org>
                Date: Wed, 28 Mar 2018 09:34:19 +0000
                Subject: Re: Neon on 18.04

                Packages are being compiled and images are being built. We'll test upgrade options and turn those on when they're reliable. We've not done this before so there's no concrete plans.

                Jonathan

                Please Read Me

                Comment


                  #9
                  This may be the first time in a LONG time that I break my rule about version release upgrades and do exactly that to my 16.04 Neon. Thankfully, I'll have my Btrfs snapshots to rollback to if something goes wrong!
                  "A nation that is afraid to let its people judge the truth and falsehood in an open market is a nation that is afraid of its people.”
                  – John F. Kennedy, February 26, 1962.

                  Comment


                    #10
                    Since my Kubuntu-based Neon developer's stable setup is working so well, I'm ready to leave things be until the 18.04-based Neon comes out. On the other hand, I'm currently using ext4 and want to switch over to btrfs, so I may not want to wait. I've been running Kubuntu 18.04 from its Alpha version to now on VMM, and it looks pretty impressive. My Hamlet dilemma is to decide between Neon and Kubuntu. I'm not sure yet. But I want to switch over to one of them, enable btrfs and eliminate Windows 10 as I no longer have any need for it and it takes up too much disk space. Fortunately, the alternatives are excellent in their own way. For now, I'll stick with what works and hope I don't need btrfs in the meantime.

                    Comment


                      #11
                      What's really neat is that when you install Kubuntu 18.04 you can select the Win10 & phantom partitions and reformat them with Btrfs. Then after you install the new Kubuntu, using Btrfs as the root file system, and boot into it, you can add the former Win10 and phantom partitions to your pool and all of it will be treated as one pool, effectively one drive.

                      Or, since you don't need Win10 you could simply delete ALL the partitions on your HD and create one large partition and format it with Btrfs as the root file system, using "/" as the label. This will create the @ & @home subvolumes which are mounted in /etc/fstab as / and /home.

                      At any time while running your system you can open a Konsole and issue
                      sudo -i
                      mount /dev/sda1 /mnt
                      and when you use "vdir /mnt" you'll see
                      @
                      @home
                      If you create a subdirectory
                      mkdir /mnt/snapshots
                      then you'll see
                      @
                      @home
                      snapshots

                      Then you could issue
                      btrfs su snapshot -r /mnt/@home /mnt/snapshots/@home20180424
                      btrfs su snapshot -r /mnt/@ /mnt/snapshots/@20180424
                      sync

                      to create a snapshot of your live system.
                      Then
                      umount /mnt
                      exit
                      exit
                      and you're done. Takes less than 3 minutes.

                      After umounting /mnt and exiting root and exiting Konsole your running system cannot access @, @home or backups in snapshots. They are in the Btrfs root, which is higher than /.

                      Some people create a snapshot subdirectory under / and then store snapshots in it, but that exposes the snapshots to user space, so I don't do that. The snapper application does things that way.
                      Last edited by GreyGeek; Apr 24, 2018, 07:33 PM.
                      "A nation that is afraid to let its people judge the truth and falsehood in an open market is a nation that is afraid of its people.”
                      – John F. Kennedy, February 26, 1962.

                      Comment


                        #12
                        I know next to nothing about btrfs but am willing to learn since so many people find it useful. I presume what you wrote above includes how to make snapshots. I was thinking of using an external 1 tb drive to store my snapshots on. Is that possible? Recommended? How would I do that? In btrfs, I am no more than a newb.

                        Comment


                          #13
                          Originally posted by oldgeek View Post
                          I know next to nothing about btrfs but am willing to learn since so many people find it useful. I presume what you wrote above includes how to make snapshots. I was thinking of using an external 1 tb drive to store my snapshots on. Is that possible? Recommended? How would I do that? In btrfs, I am no more than a newb.
                          If you formatted that 1TB external HD with Btrfs you can do the following as root:
                          mount /dev/sdX /backup
                          where sdX is the 1TB drive, replacing X with its actual letter.
                          "/backup" is created with
                          mkdir /backup and is a normal subdirectory of root, just like snapshots is of /mnt.

                          Now, use the btrfs send & receive commands:
                          btrfs send /mnt/snapshots/@YYYYMMDD | btrfs receive /backup
                          btrfs send /mnt/snapshots/@homeYYYYMMDD | btrfs receive /backup
                          sync

                          Both snapshots have to be of the read only (-r) variety.

                          These two commands take the most time when using Btrfs.

                          On my system, a 750GB HD (residing in an HD Caddy that replaced my CDROM drive) is mounted as /backup. The two send & receive commands take about 10 minutes for @YYYYMMDD and about 15 minutes for @homeYYYYMMDD. However, while those two commands are running I can continue to use my system and suffer no appreciable performance penalties.

                          When the send & receive commands are done I do the following:
                          umount /backup
                          exit (to exit root)
                          exit (to close Konsole)
                          I never actually CD to /mnt.

                          At no time while creating the snapshots, nor while sending them to the external HD, do I have to shut down my system. I continue to use it for anything and everything. During the 30 minutes or so those snapshots are being sent to /backup I have played Minecraft, browsed the web and watched videos, browsed this forum, did email, worked with SageMath on projects, did apt updates, etc. The only thing I didn't do was to shut down this laptop. My laptop is a 2012 Acer V3-771G with an i7 CPU and 6GB of RAM. I do not have a swap file (Btrfs does not use a swap file, even though some applications might.)

                          I generally keep the last four sets of snapshots and delete the older ones. Unlike ZFS, Btrfs does not destroy more recent snapshots if you revert to an older snapshot. Here's my space usage:
                          Code:
                          1
                             Device size:           691.19GiB
                             Device slack:              0.00B
                             Data,single:            64.00GiB
                             Metadata,RAID1:          3.00GiB
                             Unallocated:           624.19GiB
                          
                          /dev/sdc, ID: 2
                             Device size:           698.64GiB
                             Device slack:              0.00B
                             Data,single:            65.00GiB
                             Metadata,RAID1:          3.00GiB
                             System,single:          32.00MiB
                             Unallocated:           630.61GiB
                          
                          jerry@jerry-Aspire-V3-771:~$ sudo btrfs device usage /mnt
                          /dev/sda1, ID: 1
                             Device size:           691.19GiB
                             Device slack:              0.00B
                             Data,single:            64.00GiB
                             Metadata,RAID1:          3.00GiB
                             Unallocated:           624.19GiB
                          
                          /dev/sdc, ID: 2
                             Device size:           698.64GiB
                             Device slack:              0.00B
                             Data,single:            65.00GiB
                             Metadata,RAID1:          3.00GiB
                             System,single:          32.00MiB
                             Unallocated:           630.61GiB
                          
                          jerry@jerry-Aspire-V3-771:~$ sudo btrfs filesystem show /
                          Label: 'sda1'  uuid: 12980ae8-4117-4cc5-bbb8-8065e82af93d
                                  Total devices 2 FS bytes used 119.78GiB
                                  devid    1 size 691.19GiB used 67.00GiB path /dev/sda1
                                  devid    2 size 698.64GiB used 68.03GiB path /dev/sdc
                          Two drives, sda1 and sdc, comprise my Btrfs pool. Their useful space is 698GB+691GB= 1.39TB. So far, I've used 135GiB for all of my data, and that includes four sets of snapshots.

                          I haven't discussed rolling back from a disaster or unwanted changes, but that exercise takes less than 5 minutes total, which includes the reboot.
                          "A nation that is afraid to let its people judge the truth and falsehood in an open market is a nation that is afraid of its people.”
                          – John F. Kennedy, February 26, 1962.

                          Comment


                            #14
                            Thanks for the info. I think I will copy the post to a hard drive so I don't have to look for it. By the way, how do I format the ext hd as root? It's already been formatted, but I can do it again after I copy whatever is on it to another ext hd that I use as backup.

                            Comment


                              #15
                              Originally posted by oldgeek View Post
                              I know next to nothing about btrfs but am willing to learn since so many people find it useful. I presume what you wrote above includes how to make snapshots. I was thinking of using an external 1 tb drive to store my snapshots on. Is that possible? Recommended? How would I do that? In btrfs, I am no more than a newb.
                              You can use an external hard drive, but your success will depend on how it's attached. If it's USB, the btrfs developers don't recommend using it as a part of a btrfs pool (array of drives or partitions) it because it can become un-attached too easily. If this were to occur during a file operation or subvolume transfer, data corruption can occur. As long as you use it as a stand-alone file system you should be fine.

                              In my experience, an interrupted send|receive (backup) operation only results in an incomplete backup that must be deleted and the backup operation restarted - not really a big deal. The other way to use the external drive as a backup device would send your backup to a file, transfer the file to the backup drive, and "receive" it to a file system once it's safely on the drive. This is only because the send|receive operation can be lengthy thus increasing the exposure to an accidental disconnect.

                              I have made direct backups (transferred read-only subvolumes) over a network using ssh. That work well.

                              Please Read Me

                              Comment

                              Working...
                              X