EmbeddedEntropy

@EmbeddedEntropy@lemmy.ml

This profile is from a federated server and may be incomplete. Browse more on the original instance.

EmbeddedEntropy,

If you notice, malnourished Jewish guy is fighting dirty though.

EmbeddedEntropy,

Unless their board approves an earlier date.

EmbeddedEntropy,

I used to use that approach, but found in the last several years more than half the web sites I use reject email addresses with “+” characters.

I even use several sites that used to take those addresses just fine now reject them. That made me wonder if some common JS package for parsing email addresses got changed.

EmbeddedEntropy,

I must be ancient then. I recognized, and I think used, all of those cards/chips.

Some personally. Some at work. At work I used to maintain and MS-DOS / early Windows graphics program. I had to test the program’s compatibility with a stack of graphics cards.

EmbeddedEntropy,

Not what they did on the surface (limiting source to only customers). That’s allowed by the GPL. But they went beyond that which imo makes them non-compliant.

  1. RH will cancel your access/agreement if you share the GPL’d source with others. That’s directly forbidden by section 6 of the GPLv2. RH is free to cancel your agreement when they want, but not because you exercised your rights under the GPL.
  2. Once your agreement is canceled, you also lose access to the matching source for other GPL’d packages installed on your system. RH could offer other methods to be in compliance, but as far as I know, they have not.
EmbeddedEntropy,

I would say that cancelling your subscription is a direct violation of the GPL for two reasons.

For example, say I’m someone who installed RHEL under a subscription. I downloaded the source to the kernel then distributed the SRPM to others leading Red Hat to cancel my subscription/account.

  1. With a cancelled subscription/account, how do I now access the buildable source for say the GCC package I have installed on my system as guaranteed under the GPL?

    If Red Hat didn’t cancel my subscription/account, but restricted it to only accessing the matching source downloads for the packages on my system, that would be compliant. But they didn’t. They killed all my access for matching source which is non-compliant.

    If Red Hat provided a service where I could request buildable copies of the source for the packages I have installed , this would be compliant. But as far as I know, they have not.

  2. Cancelling my subscription/account is a violation of Section 6 of the GPLv2 which states, " You may not impose any further restrictions on the recipients’ exercise of the rights granted herein."

    This clause is to ensure you can freely exercise your rights granted by the GPLv2. Cancelling your subscription/account for no reason other than exercising your rights is a direct violation.

    For example, I have the right to vote. If a government body imposes a hefty fine or tax if I attempted to vote, this would be considered further restrictions on my right to vote. This is what Red Hat has done.

    Red Hat is certainly free to cancel your subscription/account under the terms of their license, but not when it conflicts with the exercise of rights granted under the GPL.

EmbeddedEntropy,

As far as I understand, this discussion is still theoretical because Red Hat has not terminated anyone’s subscription or account yet due to distributing GPL’d source to a Red Hat product, so everything’s an assumption until it happens. Do you know if they have that has been publicly disclosed?

And guess what, they will give it to you.

Have they explained how they will do that after terminating my subscription?

I offered some alternative methods to how Red Hat could be GPL compliant. As far as I know, they have not disclosed such a process that meets the terms of the GPL.

They do not restrict your rights in any way with regards to the software they have already given you.

By terminating access to the source for GPL’d software I’ve already installed, yes, they have, unless they/you can clarify how they will still allow me to access the matching, buildable source for the binary packages I’ve already installed on my system.

Normally, I would download the matching source for a package via the dnf or other related tools, but they won’t work if my RHEL subscription or account is terminated. I would like to hear this new method. I offered a couple under my earlier post as possible examples.

Anyway, that’s inconsequential. By applying any additional restrictions when exercising the GPL granted rights, this violates the GPL. Those restrictions don’t have to be on the rights themselves, they just have to come into effect when the rights granted by the GPL are exercised, which in this case, they do.

As quoted earlier, GPLv2 section 6 states, “You may not impose any further restrictions on the recipients’ exercise of the rights granted herein.” It does not say, “You may not impose any further restrictions on the rights granted herein.” It’s not the rights themselves, but the mere exercise of those rights. As I mentioned before, what good is a right to vote if additional restrictions can be included such as paying a fine or tax? This is what section 6 is meant to prevent others from doing.

A cancelled subscription does not cause me to lose access to the software that has been distributed to me or to any of the rights and freedoms as stated in the licenses ( GPL and otherwise ) for the software that Red Hat has distributed to me.

You keep saying that, but not mentioning how. Would you please clarify for me how I access the buildable source for the exact version and release of a package I have already installed on my system post-termination of my subscription? Maybe I have missed this in Red Hat’s publications on this matter?

The subscription is not a software license, it is a contract.

It is a contract that includes licenses that are part of it, so I’m not sure of your point here?

Contract law comes into effect here. And fulfilling or breaking the terms of the licenses included as part of the contract are also in play.

As mentioned, there are certainly ways for Red Hat to terminate aspects of the RHEL support agreement that would comply with the GPL. I certainly accept Red Hat has the rights to terminate future access to newer versions of binaries or sources covered by the GPL. There are ways for them to do that without violating the GPL, and I would like to see them do that, but so far I’ve not seen how they will comply.

RHEL itself is not licensed under the GPL and so the whole premise is wrong on its face. The subscription agreement is for RHEL itself.

But components of RHEL are licensed under the GPL. The subscription agreement in part is how Red Hat fulfills the terms of the GPL for those components, so could you clarify the point of your statement?

If the RHEL software under the GPL did not rely on a working subscription for fulfilling GPL terms, then that would decouple the RHEL subscription from the GPL and covered components, but I have not seen a description yet of how Red Hat will do that.

Thank you for replying. I’ve had these points and questions for some time, but I have not seen a good rebuttal from someone GPL knowledgeable with Red Hat’s position. If you can clarify and answer the points above, that would help.

EmbeddedEntropy,

Again, less than half of RHEL is even software released under the GPL.

I would be completely shocked if this were true. I’m calling BS here.

I used to be my company’s primary contact for our Red Hat TAM for almost 13 years. Our TAMs were very proud to claim that all of RHEL was FOSS software, licensed under the GPL or sometimes other FOSS licenses.

I spun up a RHEL 9.2 instance and ran:


<span style="color:#323232;">$ sudo dnf list --all | wc -l
</span><span style="color:#323232;">6671
</span><span style="color:#323232;">$ dnf info --all | grep "^License .*:.*GPL.*" | wc -l
</span><span style="color:#323232;">4344
</span><span style="color:#323232;">$ python -c "print(4344/6673 * 100)"
</span><span style="color:#323232;">65.11767351221705
</span>

So 65% of RHEL 9’s packages are under a GPL license.

Much of the software that is GPL was authored by Red Hat themselves. According to the text of the GPL itself, Red Hat is not required to distribute the code to the totality of the RHEL distribution or even to more than half the code.

Half?!? Again, where are these mysterious numbers coming from?

It doesn’t matter if Red Hat authored those packages or not. What matters is if they were distributed under a GPL license. If you’re claiming that Red Hat multi-licensed those GPL’d packages that they exclusively wrote so they don’t have to comply with the GPL, please point those out to me (or at least a few), so I can check them out.

EmbeddedEntropy,

I’d rather have an M.2 connector without requiring a HAT.

I’ll stick with my Orange Pi 5 for now which comes with one, tyvm.

EmbeddedEntropy,

M.2 is a serious win. That’s why I couldn’t believe the RPi5 didn’t include one natively.

I have a mix of Orange and Raspberry Pis. It all depends on their features, specs, and price point for the job. But if I don’t need a HAT, Orange usually wins out.

EmbeddedEntropy,

I’ve written hundreds (thousands?) of GNU Makefiles over the past 30 years and never had a need to unconditionally run particular targets before all others. GNU Make utility is a rule-based language. I’d suggest what you’re attempting to do is enforce an imperative programming language model onto a rule-based programming language model, which you’re going to run into trouble trying to code in a different language model than the tool’s native model.

Can you provide what you mean by check the environment, and why you’d need to do that before anything else?

For example, in the past I’ve want to determine if and which particular command was installed, so I have near the top of my Makefile:


<span style="color:#323232;">container_command_defaults = podman docker
</span><span style="color:#323232;">container_command_default_paths := $(shell command -v $(container_command_defaults))
</span><span style="color:#323232;">
</span><span style="color:#323232;">ifndef container_command
</span><span style="color:#323232;">  container_command = $(firstword $(container_command_default_paths))
</span><span style="color:#323232;">  ifeq ($(container_command),)
</span><span style="color:#323232;">    $(error You must have docker or podman installed)
</span><span style="color:#323232;">  endif
</span><span style="color:#323232;">endif
</span>

Using the := operator with $(shell …) is a way to run a command while GNU Make is initially parsing your Makefile. Normally, using := assignment operator is antithetical to a rule-based language, so you want to limit its use as much as possible, but unusual exceptions can exist.

I’m also unclear what you mean by “ensure variables are set”. What kind of variables?

The above snippet shows how you can check if a makefile variable is set when the Makefile is first parsed, if not, declare an error and exit. (The same approach works for environment variables too.)

Preparing a particular layout ahead of time is not the best approach. I’d suggest a given layout is nothing more than dependencies that should be declared as such.

Also, running specific targets or rules unconditionally can lead to trouble later as your Makefile grows up. You may eventually have additional targets that say provide information about the build’s state or run checks or tests. You wouldn’t want those targets necessarily to go off and build an entire tree of directories for you or take other unnecessary actions.

If you want to ensure certain directories are present, add those as dependencies for those targets with the | character. For example:


<span style="color:#323232;">build_directory ?= build
</span><span style="color:#323232;">build_make = $(MAKE) ...
</span><span style="color:#323232;">targets = ...
</span><span style="color:#323232;">
</span><span style="color:#323232;">all: FORCE | $(build_directory)
</span><span style="color:#323232;">	$(build_make) $(targets)
</span><span style="color:#323232;">
</span><span style="color:#323232;">$(build_directory):
</span><span style="color:#323232;">	mkdir -p -- '$@'
</span>

Even though I’ve been writing GNU Makefiles for decades, I still am learning new stuff constantly, so if someone has better, different ways, I’m certainly up for studying them.

EmbeddedEntropy,

You may like an approach I came up with some time ago.

In my included file that’s common among my Makefiles:


<span style="color:#323232;"># Ensure the macro named is set to a non-empty value.
</span><span style="color:#323232;">varchk_call = $(if $($(1)),,$(error $(1) is not set from calling environment))
</span><span style="color:#323232;">
</span><span style="color:#323232;"># Ensure all the macros named in the list are set to a non-empty value.
</span><span style="color:#323232;">varchklist_call = $(foreach v,$(1),$(call varchk_call,$v))
</span>

At the top of a Makefile that I want to ensure certain variables are set before it runs:


<span style="color:#323232;">$(call varchklist_call,
</span><span style="color:#323232;">        INSTDIR 
</span><span style="color:#323232;">        PACKAGE 
</span><span style="color:#323232;">        RELEASE 
</span><span style="color:#323232;">        VERSION)
</span>

I usually do these checks in sub-Makefiles to ensure someone didn’t break the top level Makefile by not passing down a required macro.

EmbeddedEntropy,

To solve your DRY problem, you may not realize that you can generate target rules from built-in functions eval and foreach and a user-defined new-line macro. Think of it like a preprocessor step.

For example:


<span style="color:#323232;"># This defines a new-line macro.  It must have two blank lines.
</span><span style="color:#323232;">define nl
</span><span style="color:#323232;">
</span><span style="color:#323232;">
</span><span style="color:#323232;">endef
</span><span style="color:#323232;">
</span><span style="color:#323232;"># Generate two rules for ansible playbooks:
</span><span style="color:#323232;">$(eval $(foreach v,1 2,
</span><span style="color:#323232;">.PHONY : ansible.run-playbook$v $(nl)
</span><span style="color:#323232;">
</span><span style="color:#323232;">ansible.run-playbook$v : ensure-variables cleanup-residue | $$(ansible.venv)$(nl)
</span><span style="color:#323232;">ansible.run-playbook$v :;
</span><span style="color:#323232;">	... $(nl)
</span><span style="color:#323232;">))
</span>

I winged it a bit for you, but hopefully I got it right, or at least right enough you get what I’m doing with this technique.

EmbeddedEntropy,

I think the joke would have been better and more understandable if it had used different corporate names rather than states. But, of course, that might have been legally problematic.

EmbeddedEntropy,

Part of the confusion I find is he’s trying to make a tech joke using something inherently non-technical, states’ names.

EmbeddedEntropy,

And the WARN Act.

EmbeddedEntropy,

Unless Gitlab changed things very recently, you only needed to provide a CC/DC if you wanted the free CI/CD pipeline enabled for your projects. Decline, and everything except the free pipeline works just fine.

EmbeddedEntropy,

A 1979 TV show about a guy who put together a junk spaceship to salvage junk from the moon: Salvage 1.

My teenage self found it entertaining at the time. Hmmm, now where did I leave my parrot? I wonder if he could help me find a copy…

EmbeddedEntropy,

At my company, we have around 400,000 servers in production. When we last surveyed them, we found several thousand over 12 years old, with the oldest at 17 years. And that wasn’t counting our lab and admin servers which could run even older because they’re often repurposed from prod decomms.

We had a huge internal effort to virtualize their loads, but in the end, only about 15% were transferred just due to the sheer number of hidden edge cases that kept turning up.

EmbeddedEntropy,

I think they’re trying to simplify the exposed interfaces simplifying everyone else’s job at the expense of making a more complex implementation.

EmbeddedEntropy,

All of them. Corp directive (now) is that hosts must be updated or reimaged every 90 days.

EmbeddedEntropy,

If they can have someone program a fee in their accounting systems, that means they know exactly what that the fee is and under what conditions it’s applicable. It’s trivial from there to sort, filter, and list them.

EmbeddedEntropy,

Since being forced to use this terrible communication method in my teams and groups, I’ve been copy-and-pasting good Q&A threads into text files that I push to an enterprise GitHub repo for perma-store. At least that way other engineers and myself can either use GitHub’s search or clone the repo locally, grep it, and even contribute back with PRs. Sometimes from there, turn into a wiki, but that’s pretty rare. My approach is horribly inefficient and so much stuff is still lost, but it’s better than Discord’s search or dealing with Confluence.

EmbeddedEntropy,

Unfortunately, there’s nothing in the U.S. constitution preventing a president from also being an incarcerated criminal.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • megavids
  • thenastyranch
  • rosin
  • GTA5RPClips
  • osvaldo12
  • love
  • Youngstown
  • slotface
  • khanakhh
  • everett
  • kavyap
  • mdbf
  • DreamBathrooms
  • ngwrru68w68
  • provamag3
  • magazineikmin
  • InstantRegret
  • normalnudes
  • tacticalgear
  • cubers
  • ethstaker
  • modclub
  • cisconetworking
  • Durango
  • anitta
  • Leos
  • tester
  • JUstTest
  • All magazines
    •