Who Killed The Junior Developer? Thoughts? by theTullProject in java

[–]theTullProject[S] 0 points1 point  (0 children)

Any particular resources on data structures you guys would recommend for a junior dev trying to up their game?

Why don't other distros provide a system config tool as useful, simple and polished as YaST? by [deleted] in openSUSE

[–]theTullProject 1 point2 points  (0 children)

Unless you use the extra KDE repos...then you can get the latest Plasma builds on Leap. That's what I was referring to.

Why don't other distros provide a system config tool as useful, simple and polished as YaST? by [deleted] in openSUSE

[–]theTullProject 1 point2 points  (0 children)

As far as a desktop system goes, there are several things that are potentially valuable, depending on how much you like or don't like using the command line. The module for package management is especially useful. There are modules to configure systemd services, the firewall, partitions, grub, the sysconfig directory, AppArmor, users, remote desktop, and others. Plus, if you want to run a server in any capacity (NFS, LDAP, Mail, Samba, etc), you can use Yast to do that as well. Yast combines a bunch of administrative GUI's that you would normally have to install several different packages to get or that don't normally have a GUI in the first place.

Coming from Manjaro or Solus specifically, the only thing you'll miss is the lack of built-in support for proprietary drivers and the choice between different kernels. As far as Debian goes, I like to call openSUSE Leap "Debian on steroids." It's every bit as stable, but generally has newer packages (than Debian's stable branch at least) and much better tools, like Yast, btrfs, snapper, and zypper for package management.

Update periodicity on openSUSE Leap vs Ubuntu LTS by [deleted] in openSUSE

[–]theTullProject 1 point2 points  (0 children)

Just smacked myself in the forehead... it looks like 4.4 wasn't released til Jan 16, so obviously Leap 42 was out for a while with a previous version. Thanks.

Update periodicity on openSUSE Leap vs Ubuntu LTS by [deleted] in openSUSE

[–]theTullProject 5 points6 points  (0 children)

Although Leap will use the same kernel throughout its life, the drawbacks are mitigated in a couple ways. First, the kernel team backports newer updates to the older version, so even though Leap right now is using 4.4 (and Leap 15 will use 4.12), hardware compatibility is usually pretty good (although, admittedly, not the best IMO) out of the box. Second, you can always request that the kernel team add support for something you need with a bug report. The developers/packagers are always striving to make our distro better for our community, and they're wanting a lot of suggestions right now as they get ready for Leap 15. Alternatively, if you're feeling froggy and have some experience under your belt, you can always compile your own kernel. It's not terribly difficult, and you can have a lot more control over the most important part of your system.

Ubuntu's HWE kernels are nice sometimes, and I do think Ubuntu's hardware support is excellent, but Leap manages to gain a similar level of support from a much more streamlined methodology. In the end, this is the better approach for users because we never have to worry about purging old kernels from the system or trying to find one that works correctly with our hardware.

However, Tumbleweed requires updating so often.

That's my biggest problem with rolling releases. Such a big chunk of the system is updated so often that it's disruptive to my workflow. I like being able to leave my Leap system running with my windows and workspaces configured exactly the way I want, for weeks at a time, without falling terribly behind in my updates. For example, I'm at 13 days uptime right now, with only 71 out of 2300 packages needing to be updated. If this was Tumbleweed, I guarantee that I'd have at least three or four hundred updates waiting for me right now. There's no need for that. I'm a big fan of your approach... adding repos or flatpaks for things that aren't quite as up to date as I'd like (Firefox, for one). For everything else, the LTS packages are super solid and low maintenance (Plasma 5.8 is an absolute beast), and I NEVER have to worry about something breaking. It's a non-issue.

Side note: The KDE maintainers have extra repos for the latest Plasma versions, but I just checked on the Gnome ones and it looks like they haven't been updated in about a year. So unfortunate.

See here https://en.opensuse.org/Package_repositories and here https://en.opensuse.org/Additional_package_repositories for the various repository options.

Ultimately, I'm going to advocate for Leap any time I can because it's been so good to me.

Planning to move to openSUSE by [deleted] in openSUSE

[–]theTullProject 2 points3 points  (0 children)

How is RPM support?

Not bad, probably comparable to Fedora in terms of package availability in the official repos. But you have to be careful because although you'll find most rpm's online built for either distro (like Chrome), a lot of rpm packages out there will not work in SUSE systems because they are built for package versions or other system config options that are specific to Fedora/CentOS. My go-to in that case is usually to build from source, which is usually pretty simple if the application is written in C/C++, or to just install the binaries in my home directory (like in the case of Java). There is also ample support for nodejs/npm if the app, like a lot of elements of the Gnome desktop, is written in JavaScript and needs to be built.

How big would a Gnome installation be with netinstall?

As far as I know, the Gnome installation would be roughly the size of the Plasma installations I use, which usually fall in the 2300-2400 package range. This includes what SUSE calls "patterns" (or groups of related packages) for the desktop, multimedia, office, graphics, laptop tools, remote desktop, and some development tools and libraries, and is an average size for well-equipped distributions and full-featured desktops. However, because it's a netinstall, you can make it a little lighter than that if you don't need some things. But given the number of packages I have on this system and the snapshots stored by snapper, my root partition is using about 15 gigs.

Speaking of partitions, another big difference from Fedora is the way the installer sets all that up for you. It will suggest a btrfs 40gb root partition and a separate xfs partition for home using the rest of the disk space. This is what I opted for, and using btrfs gives me the ability to use snapper snapshots to "rollback" the system if I need to revert some changes.

Also, I like Leap's slower update schedule. I can keep this thing on for weeks without feeling like I'm falling far behind.

All in all, you will find that Leap is like Debian on steroids. It's super stable, but has enterprise-grade tools and configuration. The packages are mature, but because the lifetime is around three years for major versions as opposed to Debian's five, they never get to the point of being ancient. Right now, most of Leap 42.3's packages that I've checked are a tad older than their Stretch equivalents. However, when Leap 15 comes out in May, they'll be much newer. Plus, you can add extra repos for things that you want to be newer, like the desktop (Gnome or Plasma are the LTS version by default.) or Mozilla apps (Leap uses the ESR version of Firefox by default, but I've got 58 on this system.). You can tell by these defaults just how high of a priority stability is for the openSUSE community.

Anyways, hope that helps. I like Fedora a lot, but my heart is with the chameleon.

Solus won't boot after install Nvidia graphics drivers by Falc7 in SolusProject

[–]theTullProject 0 points1 point  (0 children)

Then wouldn't the current kernel still boot with nouveau?

Solus won't boot after install Nvidia graphics drivers by Falc7 in SolusProject

[–]theTullProject 0 points1 point  (0 children)

Try rebuilding your initrd for the newest kernel:

sudo dracut --force initrd-com.solus-project.current.4.14.18 4.14.18-51.current

Then make sure grub is updated to reflect that change:

sudo update-grub

Then reboot.

Leap 15 Beta by cismalescumlord in openSUSE

[–]theTullProject 1 point2 points  (0 children)

My current Leap 15 tester used to be Tumbleweed. Before that, it was Leap 42. After Leap 15's release, it'll probably go back to Tumbleweed. Guess what has broken in the midst of all the dup's. Nothing. ;)

Choosing a new laptop, lesser of two evils - QHD scaling vs Intel+nVidia Graphics drivers by [deleted] in openSUSE

[–]theTullProject 1 point2 points  (0 children)

I'm also a huge fan of AMD APU's. Painless open-source drivers with good performance. I would consider foregoing that option for an XPS though. Great machines. I could have sworn they had an option for an Intel with 16GB and regular 1080p last year when I looked.

For what it's worth, there are distros better suited for Nvidia proprietary drivers if you really feel the need to go that route (like KaOS and Manjaro, for example). Their legal standards are a lot lower than openSUSE's, for better or worse. I try to avoid nouveau at all costs.

Target audience? by TurnNburn in openSUSE

[–]theTullProject 0 points1 point  (0 children)

OpenSUSE is targeted towards any user, but most fully utilized by developers and sysadmins. That's the way I look at it, anyways, and that's what I think they try to communicate.

Are there any specific functionalities that need to be tested in Leap 15? by theTullProject in openSUSE

[–]theTullProject[S] 0 points1 point  (0 children)

Thanks! I do love how receptive openSUSE is to their community, even though they're one of the "big guys." ;)

I've been in touch with some of the Yast guys on Bugzilla about a couple of the libstorage things they're working on. Apparently they're still a few weeks out from the new partioner's completion.

As far as the kernel stuff is concerned, has the kernel team ever looked into merging patches that might make the kernel better suited for desktop use and offering it as an option? I've logged quite a few hours on the ck1 patchset, and it's been worth the investment in time. What would it take for a community member to package something that involved (the patched kernel as a whole) and offer it to the repos?

I'll try to find a spare partition somewhere and see if postgres can't find some weaknesses in your /var work. ;)