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

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.

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.

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.

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.

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.

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.

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

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…

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.

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:

container_command_defaults = podman docker
container_command_default_paths := $(shell command -v $(container_command_defaults))

ifndef container_command
  container_command = $(firstword $(container_command_default_paths))
  ifeq ($(container_command),)
    $(error You must have docker or podman installed)
  endif
endif

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:

build_directory ?= build
build_make = $(MAKE) ...
targets = ...

all: FORCE | $(build_directory)
	$(build_make) $(targets)

$(build_directory):
	mkdir -p -- '$@'

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.

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

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

And the WARN Act.

Like IT gives you any time to get anything off a corporate-owned device.

When I got laid off, IT sent a bullet to my laptop immediately kicking me off and completely locking me out of it.

I was supposed to have another 4 days to transition my work. I contacted IT and was told once the bullet goes out, that’s it. Any and all access to everything has been terminated. Might as well just go home and enjoy the extra 4 days because no one’s going to undo a bullet going off early unless it comes from the C-suite. So I did.

For GitLab, you can decline to provide a CC/DC. If you do decline, you just won’t be able to use their build pipeline services.

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.

Unless their board approves an earlier date.

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.

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.