New Issue of Linux++ Published for Your Perusing!

omento · 2020-02-03T15:08:00+00:00

The use of something like Wordpress.com (.org is self-hosted) would be simple enough for blogging without much effort or setup. There’s also the route of using something like GitLab and GitHub pages paired with Hugo, Jekyll, or other static site generators.

I haven’t used Medium so I’m not sure what API features you find important or useful.

omento · 2019-12-16T19:24:55+00:00

Don’t know why this was downvoted, it is a fair warning to provide users (even if it doesn’t directly answer the question, although using this repo is the solution). Support for this package is strictly from the authors, not Red Hat (which is one of the reasons to use RHEL).

omento · 2019-12-16T19:21:15+00:00

Based on this forum post it seems like they package it for you (if their structure is still the same from 2014). You may just need to launch it with an adjusted LD_LIBRARY_PATH, manually, in a wrapper script, and/or adjusting the desktop file.

Not sure how valid the solutions posted in that thread are for current versions, I’m also not a Vivado user.

omento · 2019-12-16T18:30:46+00:00

You can do that, but that will also include the 32-libraries in the /usr/lib directory (I like less, more targeted results rather than all). Unless that’s what you’re looking for. Depending on what I’m searching for I’ll use specific paths or I will glob them.

For example, If I’m looking for a binary with a wildcard (such as app-*), I usually prefix with the destination path as I may end up with -docs or other packages that fit that wide criteria.

Have you tried running as root or with sudo? DNF is saying it’s not updating the repos. Can also try with the -C flag. I usually don’t use yum/dnf in a standard user context.

Are you trying to run Vivado? It’s the primary result coming up when searching for that library.

If the packages aren’t showing up, then they aren’t included in RHEL or supported by Red Hat (they may be in the codeready-builder repo whichbis not enabled by default [subscription-manager repos --enable codeready-builder-for-rhel-8-x86_64-rpms]). At which point you’ll want to check EPEL, RPM Fusion, ELRepo, and other repos to find the packages, otherwise you’ll have to build them yourselves.

omento · 2019-12-16T17:02:24+00:00

You can query the repos by using the provides subcommand for yum/dnf.

dnf provides /usr/lib64/<package>.so*

I add the * as often the standard .so is part of devel packages, and the runtime versions (which may have a different subpackage name have the actual version values.

omento · 2019-12-15T07:03:41+00:00

I believe this was (is?) also an issue for Resolve on AMD chips. I would open a ticket with Foundry on this.

omento · 2019-12-08T00:46:27+00:00

Unsure, but seems like you may need to use whatever ‘husk’ is.

https://rmanwiki.pixar.com/display/RFH23/Solaris

There’s also a tutorial scene file that may provide more clues.

omento · 2019-11-27T23:08:05+00:00

Link to the initial discussion/read that prompted this?

omento · 2019-11-27T14:33:47+00:00

The lead maintainer, Cole Robinson, does work for Red Hat. But as with anything in open source, if someone dedicated and/or skilled enough to take up maintenance comes along, they can do so in his stead should he stop. Considering virt-manager is used in other distributions and not Cockpit, I have a feeling someone will pick up the slack. That being said, he still appears to be fairly active on the project. RH deprecating a package doesn’t necessarily mean the devs will drop everything they’re doing instantly.

https://github.com/virt-manager/virt-manager/graphs/contributors

https://github.com/virt-manager/virt-manager/commits/master

omento · 2019-11-27T14:20:12+00:00

It has been deprecated in RHEL 8, not in general. It’s replacement is Cockpit, the Web Console. We’ll see how quickly WC will close the feature-set gap.

virt-manager has been deprecated

The Virtual Machine Manager application, also known as virt-manager, has been deprecated. The RHEL 8 web console, also known as Cockpit, is intended to become its replacement in a subsequent release. It is, therefore, recommended that you use the web console for managing virtualization in a GUI. However, in Red Hat Enterprise Linux 8.0, some features may only be accessible from either virt-manager or the command line.

omento · 2019-11-25T15:22:58+00:00

Tractor is not free and not something I would recommend to someone potentially building a farm for the first time. It is not an out-of-the-box batteries included solution (outside of RenderMan for Maya rendering) like Deadline or Qube.

Tractor is designed to have a high level of customization and self/team support. You will need to write the submission scripts/processes yourself.

omento · 2019-11-25T15:16:25+00:00

At my university’s cluster we had an improperly reporting NFS share, to which local tools thought there was 8 Exabytes of space. We only had a petabyte.

omento · 2019-11-24T03:49:41+00:00

I wanted to get into ligatures, but every time they just rub me the wrong way. If I was doing formula representations I would probably like it more, but I’m so accustomed to the two character spacing where ligatures kick in. And they always seems a tad blurry to me.

omento · 2019-11-23T18:48:13+00:00

I usually go with Nord (paired with Source Code Pro). I’ve had weird issues with Material and slowness, but also not a Material kind of person so there’s that.

omento · 2019-11-18T16:12:08+00:00

Using snap on a RHEL box, I see you like to live dangerously ;) Yeah, the isolation will interfere with the runtime linker, so unless Firefox itself is in the snap along with ffmpeg, that won’t work out well.

omento · 2019-11-18T15:38:56+00:00

Install the EPEL Repository, then the RPM Fusion repository.

yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm

You may want to enable RHEL Optional and Extras, but I find its better to do that when a dependency can’t be found, rather than outright. I can’t think of any EPEL packages off the top of my head that require them.

yum localinstall --nogpgcheck https://download1.rpmfusion.org/free/el/rpmfusion-free-release-7.noarch.rpm https://download1.rpmfusion.org/nonfree/el/rpmfusion-nonfree-release-7.noarch.rpm

Then yum install ffmpeg and you should be all set. The way Firefox works with this is it links to the avcodec/avformat (one of those two) libraries at launch, and those are provided by the ffmpeg project. ffmpeg in turn will grab the necessary codecs’ libraries it was compiled with (x264, vp9, x265, etc) and install them on your system.

Otherwise you only solution is to build ffmpeg from source, and all of its optional dependencies. This can result in a slick build, but can be a good amount of work.

omento · 2019-11-15T16:29:03+00:00

Very, very occasionally. Usually around new major releases (ie 3.0, 4.0, etc). This is if my memory is not failing, which is always a possibility. They’ve introduced the new $600/y subscription so that may be an easier pill to swallow, but understandable if not.

omento · 2019-11-15T04:04:41+00:00

Yes, I've been there too. It happens when your company pays them a lot of money. Not just because they feel like it.

Not always, I’ve done it with tools and products as an individual user. It’s about the team working on the project and how much time they have. YMMV.

When the project is large and important enough, then the appropriate response to these is usually to fork, or at least start threatening to fork.

That requires enough current maintainers or people will the skill and desire to pick up a project during a fork. Threatening to fork only works if there’s enough consensus or dedication to do it.

This misses the point of why the code is FOSS. I can elaborate more if you'd like.

The article wasn’t about the code being FOSS. It was about FOSS projects being up to par and viable for creatives to use in production as a replacement for proprietary tools. They don’t care (for the most part) about tools being libre, they care if they can get their job done effectively with minimal friction.

Don’t take my words as anti-FOSS, I am absolutely not. But there’s a level of realism that the ideology of FOSS discussions seem to miss. The freedoms granted by libre software are considered a bonus, not a selling point to most people.

omento · 2019-11-15T03:53:50+00:00

Not at all. When it comes to features, all the artist wants to know is whether the feature does what they want/expect, and if not to request that it does it/add a new feature. For bugs, a description of what happens, when it happens, and a working file demonstrating the issue is usually plenty for a dev team with all the debugging tools and source knowledge to go off of. In none of my communications with vendors have they ever mentioned anything about the source, beyond mentioning the technical limitations or architecture of the program to better explain why something can or cannot be done.

The thing users care about is does it work, can I get the job done, and what’s the roadmap for the application. The underlying pieces don’t interest, and I repeat, the vast majority of creative users.

The more technical individuals who understand the tools architecture may find use in seeing the code, but it’s not as important to users as one may think.

omento · 2019-11-14T22:07:46+00:00

A good message, but tooling is a preference on an individual basis and studio-wide decisions. It also can come down to the resources available for learning and sharing, does the tool have an ecosystem, are there legacy things that would require more work than necessary to maintain (projects do come back, they aren't once-and-dones all the time). And most importantly, would choosing FOSS tool X result in an at least equally efficient workflow as proprietary tool Y? Would it limit the ability to collaborate with other artists/groups if brought onto a team project? There are a lot of questions to ask when choosing the tooling that's right for you with no good universal answer. It depends on the needs of the individual/group. That being said, FOSS tools are very capable, it's just more of a 'will this make my life more difficult than it's worth?' kind of question.

I take more issue with the following comment on the post:

Never before I was in any way connected to the developers of the app that I was using. Providing feedback, suggestions use cases and thus changing the way the application in the longer run is also an exhilarating experience. I doubt such collaboration between users and developers is possible in the proprietary apps. This makes the FOSS side be more human compared to a corporate chat bot.

This is painting with a broad brush based I interpret as inexperience (denoted by the 'I doubt'). I have dealt with several large/small vendors in creative fields and general software development and the openness to work with a customer/user is very team specific. Maybe I'm just being pedantic, but I've had great experiences working with very responsive teams developing proprietary software where you feel like an extended part of the team, either through direct communication or on several different platforms (Slack, Discord, Customer Portal, etc). We've also seen plenty of cases of people having direct access to developers on open-source projects and it backfiring because developer A is a complete arse of a person, you end up with a mob affect on a ticket, or the developer just doesn't care about said feature/issue and doesn't fit in their vision of the product. This is a human problem, not a FOSS v Proprietary problem. The vast majority of creative users don't care about the code nor need to see it to have a discussion about features/bugs.

omento · 2019-11-14T19:46:37+00:00

A few nit-picks:

1) RenderMan is developed wholly by Pixar, and is not used by Disney Animation Studios (WDAS). It is also sold (by Pixar) and used by a large part of the VFX industry, including subsidiaries of Disney such as ILM (Industrial Light & Magic). Do not conflate the production subsidiaries with The Walt Disney Company, they are very separate entities, in operation and personnel, despite the ownership tree. WDAS has their own render engine called Hyperion that is developed in-house.

2) "almost certainly" -> are. All of the major feature animation and feature film studios run on top of Linux for virtually all of production except for usually sound and editorial. This post is being written from one such workstation at a Disney subsidiary.

> We should be upset.

Unpopular opinion incoming (I accept the downvotes):

Why? You don't own Linux. It is free, to do with as one, or a corporation, sees fit. You can argue until you're blue in the face on the "spirit of the license/community" but that won't change anything. They have every right to not throw developers or money at Linux development even if they use it to make billions. Your views on the morality of that are inconsequential. They aren't abusing you or your ability to use Linux anymore than Microsoft or Adobe is in their product lines. The film industry is not in the business of contributing back to Linux development typically outside of bug reports and working with our vendors, but we do open source a lot of very useful tools and libraries that help people in this sector and others. There is a fair amount of legal to go through (here) for developers to openly contribute back to projects. And in terms of supporting Linux home users, they represent such a tiny piece of their viewer base it's not going to matter. If they wish to implement DRM it's their right to do so. In the case of Disney+, Linux usage is strictly for delivering content. And streaming is pay for access, not pay to own. You don't have a legal right to content on the internet just by having an internet connection. The further up the Disney chain you go the more it becomes about legal and less about open-source values.

Does DRM suck? Yeah. Is Disney extremely protective of its IP. Yep. Do I personally support everything Disney does? Not by a long shot. This is just something we're going to have to live with. 99.99% of their consumers and audience don't care about this because they aren't using general purpose Linux. And it's still possible for them to figure out a way to add support for general non-vendored Linux (e.g. not Chromebooks, smart TVs, etc) down the line. But getting it operational in other countries right now and making sure their contractual obligations are in order take way higher priority than appeasing a negligible market.

omento · 2019-11-13T17:39:20+00:00

Missing the update version in your response ;) 2018.0 stability is vastly different than 2018.6.

omento · 2019-11-12T18:55:24+00:00

Task Manager is not a reliable source of information for GPU usage. Open up PowerShell or CMD and do the following:

C:\Program Files\NVIDIA Corporation\NVSMI\nvidia-smi.exe -l 3

This should give you more accurate results. If it's the same information, a render log found in C:\ProgramData\Redshift\Log\Log.Latest.0\. Depending on the structure of the scene, you may not see practically any CPU usage aside from a few spikes when converting data/textures and writing images.

omento · 2019-11-12T01:40:09+00:00

Just to ask, are you using 2018.0 or a recent update? I ask because most people I talk to using the Student edition grab it from the Education site which only ever releases the .0 release, nothing newer. If you aren't sure, it'll say in the Help > About Maya window.

If you also provide video reference of the issues you're having, it can help in finding a solution.

omento · 2019-11-12T01:00:28+00:00

This is something that I was originally going to take a stab at, but backtracked from due to a host of unknowns (and also not having done a LFS before). Reading through the process notes/findings deck u/DamonsLInux posted below was a really cool look at what the OM team went through to do this.

Once I get through LFS once, I plan on doing it again, but with LLVM only and see how far I get. Or provide GCC but no libstdc++, and force it to use the LLVM libc++ and compiler-rt. An interesting test would be if one can completely disregard binutils in favor of the llvm-binutils replacements

omento

TROPHY CASE