TomahawkChopped

Enough

Just start taking classes and find out.

Don't let some Reddit comments dissuade you from pursuing something you may have interest in. Take some free online courses to see if you like the material

Is the programming scene changing all the time

Yes, change is the single constant in the tech industry.

with the new best thing?

Debatable. Best is a relative tem, and the marginal improvement of each new "thing" is dramatically overshadowed by the opportunity cost of switching to it.

Think of it like cars, or TVs, or computers. You don't buy a new car every year because this year's model is "better". You buy a new car when you're current one is unsuitable for your purpose

Political change lags behind changes in the governed people's thoughts and actions.

Wait a second...

1. they are not violating the GPL. They are making the source code accessible to their users that purchase the binaries

From GPLv2 FAQ https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.en.html#GPLRequireSourcePostedPublic

But if you release the modified version to the public in some way, the GPL requires you to make the modified source code available **to the program's users**, under the GPL.

\2. CentOS stream is still available

\3. Fedora is their bleeding edge development branch. Changing the fedora model to any kind of closed source approach would be product suicide.

This is all much ado about nothing. But happy to hear a counter argument.

Edit:

Here's the opinions that are most in the know:

• Fedora mailing list thread on this topic: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/PPM7P7IZYJZRVHS6LCFHVVIJ6FGWUPD4/#replies

(tldr; it's a mixed bag of replies pontificating & questioning RedHat future intentions, and a balanced set of replies affirming the commitment RedHat has toward Fedora remaining in the critical path of RHEL. There are many developer replies in this thread, and IMO is the best place for gathering opinions)

Particularly interesting is this comment from a member of the Fedora council and a Centos stream engineer, basically saying equivalent sources will still be available through CentOS stream repos

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/XM6BNUHKI3EKTDEXAAVE3JBPCG3BPUJC/

3) So what happened?

• CentOS Engineers will not be producing that git repo of exploded SRPMs anymore because there is no need for them in CentOS project.

• Red Hat recommends to take RHEL sources from CentOS Stream repositories because that is the actual source from which RHEL packages are built by RHEL Engineers.

Can you still get access to SRPMs and create exploded sources repo - Yes. But there is no practical reason for Red Hat or for CentOS Project to maintain such a service.

There is no change in Fedora or with anything related to Fedora.

• Rocky Linux forum thread and official replies on how it affects Rocky

https://forums.rockylinux.org/t/has-red-hat-just-killed-rocky-linux/10378/24

https://rockylinux.org/news/2023-06-22-press-release/

tldr; in the short term there's a plan to continue to provide patches, in the long term there is optimism of a plan to remain bug for bug compatible

• AlmaLinux official statement on the matter

https://almalinux.org/blog/impact-of-rhel-changes/

Tldr; similar to Rocky Linux thoughts

• Lwn.net announcement of the issue

https://lwn.net/Articles/935592/

Tldr; very light on Linux foundation comments and very heavy on a long comment thread of similar quality to this Reddit thread.

Because "slight uproar from vocal minority" is less attention grabbing

Libraries > frameworks

So for each person you pass that isn't blonde-blue eyed (if they dont return to the original population) then the population shrinks and the probability increases of the next person being blonde+blue.

Its the same math, but just gets more annoying and I cant do it in my head but its effectively

p_nextnotblondeblue = 1
for i in 0 to 99
    p_blondeblue = 180 / (1000 - i)
    p_nextnotblondeblue *= 1 - p_blondeblue

let’s say blonde people have a 60% chance of having blue eyes and brunettes have a 20% chance of having blue eyes. The population is 1,000 total with 300 blonde people and 700 brunette people.

There are:

• 180 Blonde+blue-eyed individuals per 1000

• 140 Brunette+blue eyed individuals per 1000

18% chance of any individual being a Blonde+blue vs 14% chance of passer-by being Brunette+blue.

Probability of 1 passer by NOT being Blonde/Blue is 82%. Probability of 2 passer bys NOT being Blonde/Blue is 0.82 * 0.82=0.6724

Probability of all 100 NOT being blonde/blue is 0.82¹⁰⁰ =0.0000000024

You just have to start wrapping every single step of the startup process with timers/use profilers and see what takes long and go from there.

This isnt so trivial with frameworks and dependency injection.

e.g. imagine a spring app with dozens or hundreds of XML declared dependencies.

https://www.baeldung.com/spring-xml-injection

The initialization will be at the framework level, and triggered by the Tomcat container.... before any hook may be accessible to run. Profiling this app is most likely going to need to happen at a very low level, digging into the guts of Tomcat and spring.

It's almost certain there have been many "clever" engineers doing "clever" things over the years.

It takes at least 5 minutes to restart every time I make a code change.

Why does this matter?

Please don't take my question as dismissive. But if you're going to embark on a 3+ month upgrade cycle your management team is going to want to know "$$$why$$$"

Does it all slow development?

• mgmt: "So?"

Quantify this as a cost. By how much does it slow you? Per day, *365 * your dev team * average salary. There's a figure to start with.

Does it affect production? Does it affect it outside restarts?

If not, maybe the right answer is to live with it. Sometimes the effort to fix something just doesn't pay dividends.

Just playing devil's advocate here. Having rebuilt several legacy enterprise applications... the juice needs to be worth the squeeze.

Edit: also if you're working with any runtime dependency injection (a'la Guice), the startup reflection chicanery there are slow as hell.

Edit2: fuxk being fancy with stuff. Get scrappy. Use strace. Use dtrace. Log directly to stdout via System.out or System.err. Drop some log lines in the very first hook of your Spring app (I've never worked with spring, so excuse my ignorance). Turn up all the log levels the full verbosity and READ THE LOGS. I mean the JVM garbage collection logs too... is your app just doing like 30 seconds of GC in the first 5 minutes? Get down and dirty with it. If you can scope the latency to the Tomcat container vs the Spring framework vs the JVM vs your own app startup then you'll almost have the plan laid out in front of you.

To do this you'll have to become an expert on tomcat startup. READ THE DOCS. Then you'll have to become an expert on Spring stsrtup. READ THE DOCS.

Learn about profiling tools (like flame graphs). Try new JVMs (like Graal) or a newer JDK. Try different GC strategies(this can be a rabbit hole and should be an optimization last resort once you're an expert).

Have fun. Happy hunting. Learn a lot!

As much as this answer may get burried or never read, I love these kinds of questions.

I began programming in the 90s because I loved video games. Please don't take that to mean I began by coding video games... honestly to this day 25 years later I still don't do that. But I began coding in high school because the teacher of the CS class let students play Sim City when they finished their assignments early. So I just always finished first (or second, the guy next to me was good). This gave me lots of time to play Sim City.

In college I didn't consider CS or programming as a major, but I was always interested in helping my roommate with his homework. Only in my 2nd year did I realize I was "good" at this stuff and wanted to study, but still couldn't possibly describe what I wanted to do with it.

I only began studying Java because that's what my school taught the 101 course in. Later I learned PHP, Ruby, Erlang, and JavaScript because that's what the job needed. Later still I learned lisp...ish because Emacs. Eventually I learned Python, cuz frankly once you know 1 imperative OOP interpreted language, others aren't much different.

This all goes to say... don't worry about what you learn to start. Just understand why you want to learn and follow that.

I wanted to play video games. Turns out I still do. And along the way I stumbled upon a mathematical universe of computational complexity that I never could have imagined.

Have fun

Edit: to get practical. If you want to learn to build web sites, learn JavaScript and NodeJS. Don't get distracted in the complexity of typescript or npm yet.

Want to learn datascience or simple desktop automations? Learn python.

Want to learn "real" computer science. Learn Haskell or Lisp or Erlang.

Want to learn "real"system engineering? Learn Rust and C.

Want to learn the meaning of pain? Learn C++ and Perl.

Want to learn a language that will work now and in 20 years? Learn Java.

Want to learn to ignore the opinions of others? Learn PHP

Want to build mobile apps? Learn Swift or Kotlin

Want to have some simple fun with a computer? Get a Raspberry Pi, a strip of Neopixels, a 9Volt battery, and some resistors.

Want to learn to do anything else, in one of 1,000,000 other ways? There's a language for that too.

The point is, pick your purpose. Then pick a language to learn. At the end of the day they're all Turing complete

Gave my daughter her first lessons in kernel panic today... "Don't panic"

Little known fact, S&P 500 is short for "Somalian and Palestinian 500 Shillings or Less" index

Oh is it, do you get 7 whole BGP routes broadcast from those ASNs?

OP tried complaining on the communist internet but then realized it didn't exist

Giant ass-hammer. FTFY?

What if my anxiety is what depresses me.

Platitudes like this offer no solice nor guidance to those actually suffering through serious circumstances