Hacker News Reader

rbrownsuseon MicroOS and Kubic: New Lighter Minimum Hardware Requirements

> 285 MB without bare metal hardware support.

All you need if you're never going to update it or you're going to take steps to ensure the installed workload doesn't eat up excess space.

rbrownsuseon OpenSUSE MicroOS

yup

rbrownsuseon OpenSUSE MicroOS

Well..that's been addressed now: https://kubic.opensuse.org/blog/2020-11-23-requirements/

rbrownsuseon *SUSE Dev Survey – Please Help Improve OpenSUSE for Developers

https://atlas.hashicorp.com/bento/boxes/opensuse-leap-42.1/

rbrownsuseon *SUSE Dev Survey – Please Help Improve OpenSUSE for Developers

Did you know easily available Docker images for openSUSE are already in the Docker hub/store?

docker pull opensuse

;)

https://hub.docker.com/_/opensuse/

https://store.docker.com/images/99f9bd45-4c65-4e45-aa36-234e...

rbrownsuseon The sad state of Linux download security

the site states that openSUSE does not sign it's checksums or provide instructions on how to verify them

Both claims are demonstrably false.

rbrownsuseon The sad state of Linux download security

Incredibly, there does not appear to be any way whatsoever to securely verify downloads from respected openSUSE.

Seriously? the author has no idea what they're talking about

http://software.opensuse.org

"For each ISO, we offer a checksum file with the corresponding SHA256 sum. For extra security, you can use GPG to verify who signed those .sha256 files. It should be 22C0 7BA5 3417 8CD0 2EFE 22AA B88B 2FD4 3DBD C284."

https://en.opensuse.org/openSUSE:Tumbleweed_installation

http://download.opensuse.org/tumbleweed/iso/openSUSE-Tumblew...

http://download.opensuse.org/distribution/leap/42.1/iso/open...

All signed, happy and healthy...and regularly checked.. people really should double check before making statements like this..

rbrownsuseon Why You Should Use Tumbleweed

My pleasure :) thanks for reading!

rbrownsuseon Why You Should Use Tumbleweed

:) fair point..I'll let the YaST team know (or you could if you happen to be on freenode, they live in the #yast channel)

Users know - YaST doesn't change stuff without telling you, that was the point I was trying to make earlier. Users of YaST no longer have to worry about it silently taking over config files, it either co-exists or doesn't do anything without telling the user with great big pop-up boxes first

rbrownsuseon Why You Should Use Tumbleweed

There is the graphical option, using http://software.opensuse.org and the 1-click install functionality there to add packages direct from OBS

on the commandline, there is a plugin for osc (the OBS commandline tool) https://build.opensuse.org/package/show/openSUSE:Tools/osc-p...

This enables 'osc install $foo' which will search the build service for package $foo and install it, which I believe to be the closest approximation of what you expect from AUR

rbrownsuseon Why You Should Use Tumbleweed

There is pretty extensive documentation on http://yast.github.io/documentation.html

It doesn't conflict with other configuration management systems. I've used openSUSE extensively with puppet and saltstack.

Many of SUSE's products use other configuration management systems as part of their toolchain, and SUSE are shipping SUSE Manager 3.0 with SaltStack, so their customers are expected to be able to use YaST alongside such a system

rbrownsuseon Why You Should Use Tumbleweed

Testing packages, and testing that an entire distribution works with those packages on it, are two very different things..

rbrownsuseon Why You Should Use Tumbleweed

the only one I can think of is the apache one. If you use the YaST apache configuration module it will warn you before taking over and changing any local changes. It actually does its best to do a merge of local changes and its own, but it's the one case I know of where that merge can be destructive.

rbrownsuseon Why You Should Use Tumbleweed

Will do..thanks for the critique

rbrownsuseon Why You Should Use Tumbleweed

YaST was written into Ruby, yes.

These days YaST no longer overwrites config files, except from a very few corner cases where it really really wants to be in control of specific config files for very specific reasons. But if it notices local changes, it warns the admin and doesn't take over unless the admin consents

So, no more unexpected config file obliteration :)

(and even if it did, YaST is integrated with openSUSE's default btrfs snapshot tooling, so YaST takes a snapshot before and after it changes anything, so you could always revert)

rbrownsuseon Why You Should Use Tumbleweed

Yes, we share one test repo amongst all the openSUSE distributions and SUSE distributions

SUSE use openQA for testing their enterprise distributions too, and keeping all our tests together and reused as heavily as possible really helps in all directions (and proves the argument that maintaining openQA tests isnt hard even when dealing with multiple codebases-under-test all moving at different paces)

I use Tumbleweed as my daily driver on all my machines besides my server (Leap).

In 2 years I've had no problems that I didnt cause myself (eg. rm -rf /) and even then snapper saved the day and let me rollback to a working snapshot (Tumbleweed, like all openSUSE/SUSE distributions have btrfs snapshots and rollback by default)

So I'd say its comparible to Fedora or Debian testing

And we'd like to see more contributors, not only adding more packages and maintaining them, but to openQA also so that Tumbleweeds quality doesn't just stay at that level but gets even higher

rbrownsuseon Why You Should Use Tumbleweed

People have been asking for that for quite a while..

https://digitalocean.uservoice.com/forums/136585-digital-oce...

There are plenty of hosting providers who do offer Leap and sometimes even Tumbleweed images.

My blog is hosted on Hetzner (they're local ;))

We have a solid presence on all the major Public Clouds https://en.opensuse.org/Portal:Cloud

Would love to be everywhere, so if any hosting companies want to get in touch about using openSUSE on their platform, my contact details are on the bottom of that article

rbrownsuseon Why You Should Use Tumbleweed

Sure they can (and Fedora are already using and contributing to openQA)

But you really need to be using OBS too in order to produce those builds in the fast, easily contributed way that we then (ab)use with Tumbleweed

Of course, other projects could use OBS also..either hosting their own or by using our servers even..after all it builds Arch, Debian, Ubuntu, Fedora and other packages

But that's what being open is all about right? Doing cool things because you need them and then benefiting even more when everyone else finally catches up and starts working with you on it :)

rbrownsuseon Why You Should Use Tumbleweed

The search seems to be doing something weird at the moment..

There is a second "openSUSE Tumbleweed" under the "unsupported distributions" category, and that has the more up to date nvidia packages I'd expect

If someone would like to take a look at the lovely ruby behind software.opensuse.org and fix that bug, I'm sure we'd love the pull requests :) https://github.com/openSUSE/software-o-o

rbrownsuseon Why You Should Use Tumbleweed

I'd say that's a fair assessment :)

SUSE isn't your typical 'for-profit', and the nature of the relationship with openSUSE reflects that

Thanks for the consideration

rbrownsuseon Why You Should Use Tumbleweed

1. kinda true, though the current version of the installer lets you skip the username creation so you can do whatever you want afterwards :)

2. formerly true - YaST lives happily with config files these days. When possible it co-exists, only a few specific YaST modules need that absolute control and only rewrites them by warning you well in advance. ie. Not true any more

3. I think we fixed that..it's a radio button now.. Encrypted LVM-based proposal https://lizards.opensuse.org/2016/03/15/highlights-of-develo...

rbrownsuseon Why You Should Use Tumbleweed

nvidia drivers - we don't recommend them because we have a habit of adding kernels quicker than NVIDIA can keep up with their proprietary drivers

If you really want to use them, I'd recommend the dkms drivers we have in OBS https://en.opensuse.org/SDB:NVIDIA_the_hard_way#Further_read...

And yes, I believe if you want you can install with sysvinit, though we are primarily a systemd distribution first (with extensive sysvinit compatibility.. people still love those runlevels)

rbrownsuseon Why You Should Use Tumbleweed

check_screen is a non-fatal check, really useful for stuff like you cite in that example "tell openQA to see if something is on the screen, then react to it"

assert_screen is it's fatal cousin "make sure the screen has this needle on it, or die"

assert_and_click is it's mouse-controlling companion, "make sure the screen has this needle on it, then click on it"

https://github.com/os-autoinst/openQA/blob/master/docs/Writi...

The above doc covers the basics, we also have a whole bunch of tutorials on YouTube

https://www.youtube.com/watch?v=-fqvaSO6nKE https://www.youtube.com/watch?v=a8LmqhwpVvg https://www.youtube.com/watch?v=EM3XmaQXcLg

rbrownsuseon Why You Should Use Tumbleweed

and one question that doesn't get answered by that link - yes, we properly separate non-free software from our free packages

rbrownsuseon Why You Should Use Tumbleweed

We do automated testing from our 'traditional' distributions, including versions that existed BEFORE Tumbleweed in it's current form..like 13.1, 12.3, etc..

So in that case, we're going back years ;)

rbrownsuseon Why You Should Use Tumbleweed

I wrote a rather long mailinglist post that should answer a lot of those questions..

https://lists.opensuse.org/opensuse-project/2016-02/msg00003...

rbrownsuseon Why You Should Use Tumbleweed

Yes, the open build service takes care of that for you

You don't need to tell Foo about your package, the build service will detect those relationships

If you build against Foo, and Foo changes, the OBS will rebuild your package for you

If it breaks your package, the OBS will keep the last version published while you can debug the build failure

rbrownsuseon Why You Should Use Tumbleweed

You'd be surprised how little a problem it is in the real world

In the case of UI changes, openQA can have it's 'needles' updated in it's webUI. Look at the new screenshot, compare to the old screenshot, tell openQA to like the new stuff, done.

In the case of functionality or workflow changes, yeah, tests need to be adapted, but the openQA test writing language is pretty human friendly, describing the steps that humans actually do, so it's not that hard to alter

And because we test at the point of submission before anything is merged to the distribution, we generally catch the behaviour changes as part of the package submission, then we have developers keen to get their stuff in the distribution happy to help tune up the tests ;)

rbrownsuseon Why You Should Use Tumbleweed

zypper takes care of most of that for us - it really is an exceptional package manager

We have some tests in openQA that keep an eye on upgrades, as well as some users who like to stagger their Tumbleweed updates for some weeks.

I think the record I heard was like 3 months (and our gcc5 migration happened during those months), and then they upgraded with no problem

rbrownsuseon Why You Should Use Tumbleweed

Apart from Debian Sid: has no testing, but Tumbleweed does - so those breakages don't happen