What's special about Nebraska?

It’s a joke about an old Bell rule: https://www.networkworld.com/article/945570/replaying-ballme...

As an AI language model, I don't have opinions, but I can provide some information.

Weekly 1:1 meetings can be very beneficial for both the manager and the employee. It provides a regular forum for open communication, feedback, and goal setting. It also helps to build trust and maintain a strong working relationship between the two parties.

During these meetings, both the manager and employee can discuss progress on goals, address any concerns or roadblocks, provide feedback, and address any personal or professional development needs. This can help to ensure that everyone is working towards the same goals and can lead to increased performance and job satisfaction.

Overall, the effectiveness of these meetings may depend on the individuals involved and the nature of their work. Some may benefit more from more frequent or less frequent check-ins. It's important to find what works best for each situation and adjust accordingly.

11x developer.

Dang. I thought I found that 8 hours later.

JDK9+? Not just 9.

Yes

There are dozens of us... DOZENS

Until Red Hat starts to add backports or fixes for customers that don't get push back upstream. Then when X+1 gets to RHEL it's missing all the previous RHEL only updates (some not backport related).

I always wondered who does all this backporting and patching work for these ancient enterprise Linuxes. It seems like brutally monotonous work.

Maybe they're reading this comment right now, hi!

Is there a world in which the vast majority of dev work isn't brutally monotonous? Most work's writing unremarkable code for unremarkable products containing unremarkable features that have already been implemented 1,000 times before, and likely even more than once before for the person doing the work. A ton of dev time, at least for people who aren't the much-derided solo-language-experts (e.g. The C# + Windows programmer, the Java programmer, who only do those kinds of jobs and don't even dabble in much else) is just wrangling the unfamiliar-brokenness of a tool & library ecosystem (it would be familiar-brokenness 5 years in and take up little of your time, for most non-trendy platforms, but you're either using a trendy one that changes way too much, or will be on a different language + ecosystem entirely before you hit 5 years on this one).

Very little dev effort is working on anything cool, and very little of the code for cool projects isn't kinda boring and normal.

For a lot of developers, "brutally monotonous work" is just ... work.

Maybe I'm missing what's ancient about Fedora or RHEL, care to share?

RHEL 7 came out 6 years ago with Linux 3.10 and is still getting patched. Somebody has to manage and integrate all those security fixes in all those packages without breaking the old codebases.

...it's not just getting patched.

Kernelcare has given me 48 hotfixes on a 3.10 kernel that I booted last year.

    kcarectl --patch-info | awk '/^kpatch-name/{print ++n};{print}'
    ....
    48
    kpatch-name: 3.10.0/proc-restrict-pagemap-access-1062.patch
    kpatch-description: Restrict access to pagemap/kpageflags/kpagecount
    kpatch-kernel: 
    kpatch-cve: 
    kpatch-cvss: 
    kpatch-cve-url: http://googleprojectzero.blogspot.ru/2015/03/exploiting-dram-rowhammer-bug-to-gain.html
    kpatch-patch-url: 

    uname: 3.10.0-1160.25.1.el7

Is "kpatch" there actually the same thing as RHEL's kpatch? I thought Kernelcare used something proprietary.

The Kernelcare front end tool is kcarectl.

Ksplice (Oracle) was first, followed by kgraft (Suse), and kpatch (RedHat).

According to the article below, kpatch is x86/64 only, uses ftrace, provides runtime patches only until the next minor kernel release on a standard license, does not address all CVEs, and cannot be used with "SystemTop or kprobe."

"KernelCare has no such limitations."

https://blog.kernelcare.com/competitors/kpatch-overview-of-e...

I asked because the listing said "kpatch" in the output of the command. I've never used Kernelcare, only suggested investigating it, despite it being proprietary.

Ksplice was done by MIT students, not Oracle. I used it long before Oracle bought it, initially with my own patches (and actually after that as a "legacy" customer). kpatch isn't just x86_64; it's in at least ppc64le RHEL 7, although not for the "alt kernel" on the POWER9 systems I use.

I don't know whether it's the case, but their comparison rather suggests Kernelcare is based on Ksplice.

+1 for KernelCare.

Actually, POWER9 RHEL7 has Linux 4.x, where x depends on the minor release -- unfortunately not the latest on the system I use. I think aarch64 is similar, but I'd have to look for rpm to check. They need similar attention, of course.

Anyway, RHEL kernels have various features backported to the vanilla version on which it was originally based, not just security patches, which probably makes the job harder. It is a major effort.

How often does this happen? do they not keep track of what they need to upstream? how do they merge that all back in when X+1 begins? yikes..

Presumably everything relevant in RHEL gets backported before the next RHEL cut, and everything is in a branch?

~"Now we have two problems."

The person who originally said 'Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems.' is Jamie Zawinski. And it's an amusing quote, but, that doesn't mean it's generally correct. In the original context, this was more about Zawinski's utter hatred for Perl. http://regex.info/blog/2006-09-15/247

There's always ncdu

And tkdu, which is abandoned, but still works great. You can pipe the output of du into it, which is useful if you want to visualize a remote server.

https://github.com/daniel-beck/tkdu

And the great thing about ncdu is that you won't have to traverse the filesystem again and again as you narrow down where the disk is going, if you don't already have a good guess.

xdu as well

https://karl-voit.at/2014/03/25/xdu/