Announcement

Collapse
No announcement yet.

Jump into Jammy Kubuntu 22.04 LTS

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

  • Snowhog
    replied
    Originally posted by kc1di View Post
    I installed xserver-xorg-input-synaptics but it made no difference. trackpad still operational with mouse plugged in.
    Yes, I'm replying to an old post.

    After installing this package, you have to logout and log back in before all it's options are available, then you will see the TAB that controls this behavior.

    Leave a comment:


  • Snowhog
    replied
    Topic has been CLOSED. 22.04 Jammy Jellyfish LTS forum is now OPEN.

    Leave a comment:


  • claydoh
    replied
    Originally posted by rec9140 View Post
    LACK OF STANDARDIZED SOFTWARE DELIVERY regardless of distro, outside of source, mostly. I am all for that, VIA DEB's

    So , you want to force Debian's packaging on Arch , Fedora, Suse, and everyone else not using a Debian-based distro.......??


    Click image for larger version

Name:	google_gif.gif
Views:	274
Size:	916.5 KB
ID:	662005




















    The usual caveat: no one is forcing anyone to use anything.
    Don't like something? There are multiple dozens of distros to choose from, or one can do whatever work is necessary to bend the one used into something you like.

    Leave a comment:


  • rec9140
    replied
    Originally posted by arsivci View Post

    I sympathize with Ubuntu on this. FF releases new versions 30+times a year. Considering they have to provide support for 20.04, 21.10, 22.04, 3 releases at any given time, that makes 90+ releases/packages a year. I am not a huge fan of containerisation but I will allow FF and Thunderbird as exceptions; a little bit extra security is good for them. I'll give the snap version a try first. Depending on the performance, we'll cross that bridge.
    Afraid, I am a HARD, very HARD NO on snaps, ever, period. Its a yet another package system, which I don't like for many reasons, there is a reason I use something based on Debian, DEB's. I've got a lot of reasons on why I dislike snaps, #1 on that list is MANDATORY FORCED UPDATING, (I well aware of the delay, but you can not block it permanently.)

    There are a few routes I may take, so long as these pan out.. and I will test installing the tarball, but there are issues with that too again, auto updating, and what it takes for me to stop such behavior, tick the box in some about: setting, fine, if I have to start adding things to the firewall, and etc/hosts etc. to block IP's, FQDN's... then we are going to have problems.

    Thats the biggest one, not the only one, but its what ends things right then and there. Updates of software are done when I and ONLY WHEN I DETERMINE that should be done. OS or software. I am not coming into work and mass debacle of PC's that don't boot because of some upgrade gone awry cough grub cough. Thankfully because I don't let things do that, I don't have those issues!

    As for speed, you can review this...
    https://www.reddit.com/r/Ubuntu/comm...om_their_site/
    Seems to be quite a performance difference on the snap v. tarball

    Glad I made an install of this and de-snapd and kept all the DEBs for it as well.. Time to image this for the box update I had planned for this release... Time to make some more VM carcasses on testing of the tarball and DEBs from Mint and others.... This along with another red line is rather disappointing...

    As for the creation of the DEB's for 20-22 or any one else.. .maybe look at the source of the issue.. DEB creation... clearly the tools for this need some addressing, not a new package system. Make it so its easier for these to be created via automation... if you are investing huge amounts of actual human time into this, then there clearly is an issue.

    I get where snaps wants to get to, I think DEB's can achieve that much better. The bigger issues remain, LACK OF STANDARDIZED SOFTWARE DELIVERY regardless of distro, outside of source, mostly. I am all for that, VIA DEB's. And fixing the issues so that its easier to create such over what ever release span you need to regardless of distro. snaps (pfft) is not that solution, no matter how you want to sell it to me. No sale here.

    Leave a comment:


  • kc1di
    replied
    Downloaded and try Beta looking good so far.
    No problems to speak of everything I use seems to be working well. Looks good for Final
    Last edited by kc1di; Apr 01, 2022, 07:41 AM.

    Leave a comment:


  • arsivci
    replied
    Originally posted by jlittle View Post
    I'm not an expert on this, but my understanding is the reason is that it's hard work repackaging Firefox every time there's a new Firefox release, which can be urgent, and also every time a Firefox dependency changes. They have to commit to having staff ready to do it 365 days a year; the snap version can be set up to build and test automatically.

    With that there'll be compromises with how timely updates will be. Browser security fixes can be very important.
    I sympathise with Ubuntu on this. FF releases new versions 30+times a year. Considering they have to provide support for 20.04, 21.10, 22.04, 3 releases at any given time, that makes 90+ releases/packages a year. I am not a huge fan of containerisation but I will allow FF and Thunderbird as exceptions; a little bit extra security is good for them. I'll give the snap version a try first. Depending on the performance, we'll cross that bridge.

    By the way, I downloaded the beta yesterday, it looks awesome (just tried it live, no install). Many many thanks to the team.

    Leave a comment:


  • jlittle
    replied
    ubiquity crashed!
    Just had occasion to run the latest Jammy iso, and ubiquity didn't crash.

    Leave a comment:


  • jglen490
    replied
    jlittle, I don't doubt that building a .deb package takes time, and even sometimes the build is urgent. I'm not questioning what you have found. Urgent builds are often the result of an immediate need to fix a security issue. Dependencies are always a consideration when building a package of any kind. But, whether the package is a .deb or a container of some kind, it is still subject to urgency. And it should be subject to updating, when needed on a non-emergent basis.

    Somebody is always building a package of some sort all the time, and maybe a container is cheaper than a .deb. It just seems a bit strange.

    But, I'm in agreement with some others on this, if I want FF after I setup Kubuntu 22.04, it'll be from a tar, and snap will not be on my system. And eventually if that kills having Kubuntu, so be it. There are lots of distributions, some of them are even good.

    Leave a comment:


  • jglen490
    replied
    So, what's next to be containerized - after Firefox?

    Leave a comment:


  • acheron
    replied
    Originally posted by bendy View Post
    I don't understand why this change is being forced - the Ubuntu bug report says Mozilla are driving the change to snap, yet Mint are saying they will build their own deb for their repos as part of their new partnership with Mozilla...
    While Mint is popular, it is not Ubuntu. i.e. it is not installed and trusted worldwide by many enterprises, eduction institutions, and server applications. This means that that the distribution agreement Mozilla has with Canonical is quite major thing for them. How mint provide a Firefox build is quite frankly not. No offence to Mint, but that is the way it is.

    Leave a comment:


  • acheron
    replied
    Originally posted by jlittle View Post
    If I install Firefox from the .tar.bz on the Mozilla download site, will that avoid the snap version?
    Yes. I personally use the Firefox Developer Edition using the upstream tar builds.

    Leave a comment:


  • jlittle
    replied
    Originally posted by bendy View Post
    I don't understand why this change is being forced
    I'm not an expert on this, but my understanding is the reason is that it's hard work repackaging Firefox every time there's a new Firefox release, which can be urgent, and also every time a Firefox dependency changes. They have to commit to having staff ready to do it 365 days a year; the snap version can be set up to build and test automatically.
    I guess a ppa or other package source will appear in due course to provide debs for Ubuntu.
    With that there'll be compromises with how timely updates will be. Browser security fixes can be very important.

    Leave a comment:


  • jlittle
    replied
    Originally posted by acheron View Post
    The .deb is now just a transitional package that installs the snap and removes the conventional Firefox, so in place upgrades will do that.
    Bugger. (New Zealand English.) I don't want that. In my testing of the Jammy install I mentioned above, I noticed how slow Firefox was to start; that would annoy me on every restart.

    If I install Firefox from the .tar.bz on the Mozilla download site, will that avoid the snap version?

    Leave a comment:


  • Snowhog
    replied
    Originally posted by NoWorries View Post
    I would be interested for proof that btrfs would prevent these problems.
    Not prevent. Allow for extremely quick recovery.

    I'm at the early stage where I'm actually starting to Grok how btrfs works, and the power it provides the user. I'm not yet at the stage where I can explain it to someone else, but I see the light at the end of the tunnel (and believe it isn't an oncoming train!).

    Leave a comment:


  • oshunluvr
    replied
    The best way to solve the Ubiquty problem is to use Calamares. Ubiquity has been horrible for many years.

    Leave a comment:

Working...
X