At the time, he was making $100,000+ and taking time off whenever he wanted. I think he made a lot more during the fixes that prevented #Y2K from becoming the expected meltdown, but he then ran into headwinds because foreign programmers were being imported to do the work for a lot less than what he was accustomed to earning, so he retired.
I thought about this back when the lockdowns geared up and state governors were crying about lacking the COBOL programmers to fix their unemployment insurance systems.
after a nuclear war, the remaining people will probably not be able to spin up a modern operating system on their improvised chips. How do you build a simple, reliable, legacy-free OS from scratch? What ideas 💡 and techniques should be passed down to those people?
If we think hard enough about this, I think we’ll agree that closed-source systems are basically designed to be almost impossible for people outside the sponsoring organization to reproduce (for an example, consider [ReactOS](https://reactos.org/), which launched as [a project to produce a system compatible with Windows 95](https://reactos.org/wiki/FreeWin95) and [then changed to focus on Windows NT](https://reactos.org/wiki/ReactOS/History), and after more than 25 years, is still not capable of being a daily use system.
But we may also determine that most open-source systems are likewise not designed in such a way that reconstruction is viable. The Linux kernel is *huge* these days.
Additionally, in my opinion, they’d probably want to use programming languages designed for readability, ease of learning, and error-reduction first (that is, more like #COBOL than #C, more like #Java than #CPlusPlus, more like !Smalltalk and #Lisp / #Scheme than #Perl / #Raku and #JavaScript) and then performance and low-level access.
I think it is a mistake to assume that one could start with a modern version of #gcc or #llvm or #msvc … because it is not a given that the software itself and someone who knew how to use it (and update, modify, and adapt it) would still exist.
@geniusmusing At one point, I was running these sites on a VPS running CentOS. In order to get a currently supported version of PHP (v.5.6 at the time), I had to find a 3rd party repo. The repo, for some reason, did not have a version of php-intl that worked, so every time there was an update, I had to use PEAR to download and compile it.
(By the way, I don’t know if PHP has integrated that extension into the main executable yet, but if they haven’t, they should.)
Distros and projects should be moving to v.8.0.x, which is supported for another 18 months (with another year of security patches after that). I’m assuming that there are some breaking changes between the 7.x.y versions and the 8.x.y versions, so I can understand some grumbling from developers.
However, the truth is that #PHP, like its ancestor #Perl, just evolved organically without any planning and now needs to clean up 🧽 🧹 inconsistencies and continue to tighten security. Hopefully, the pace of change will slow once those two things are accomplished.
* #M / #MUMPS unified database & language
* Forked from #GT.M by long-time members of the GT.M dev team
* Compatibility / interop with #C, #Go, #Rust, #Perl, ...
I was just thinking (thanks to an #IRC discussion this morning) about breaking changes in programming languages and how often they split the community (or get rolled back, sometimes before an official release). Examples: #Perl 6 (now called #Raku) was originally a replacement for Perl 5, but became its own separate language (and I’m hearing that Perl 7 is facing rough sailing with the language’s community, too); #PHP 6, with radical changes that were scaled way down (PHP 6 was skipped, but later parts of the 5.x series and the 7.x series implemented some of the proposed changes). Then I come across this.
Position Summary:
Perforce is seeking a CentOS Support Engineer to join our OpenLogic team (that's my new team, but this is not my specific position), responsible for providing 24x7 break fix support and services on Open Source technologies to our OpenLogic customers. This position will work closely with members from Support, Sales and Professional Services to assist in resolving a wide variety of customer issues. OpenLogic provides enterprise services for hundreds of open source projects — including OpenJDK, Kubernetes, CentOS, and MariaDB — so you can boost efficiency and savings with free software, while cutting risk.
Responsibilities:
Interact with end users on technical problems.
Tier 1, 2 and 3 support for CentOS and related open source products.
Drive resolution of those problems, which include:
Open source software issues.
Questions around #opensource software usage.
Questions around use and best practices.
Review of the architecture and design where software is implemented.
Conduct professional services and training engagements.
Research, understand, and advocate open source software.
Interact with various open source communities.
Drive early resolution of issues.
Make strategic contributions to the CentOS core and surrounding ecosystem, provide bug fixes ahead of the community where needed
Be a part of the on-call rotation.
Present knowledge via articles, blogs, and conference presentations.
Requirements:
Technical knowledge, skills and expertise in complex infrastructure, web-based software and enterprise software
Strong knowledge of the Linux kernel and system architecture.
Understanding of software best practices; SDLC, #SCM and Agile development principles.
Ability to develop with C/C++ in a #UNIX environment.
Utilization of common Linux C/C++ build tools such as gcc.
Solid understanding of CentOS 6.x and 7.x and included frameworks like firewalld, systemd, etc.
Strong #RHEL/CentOS background required
#Debian/ #Ubuntu, #SUSE/ #openSUSE/ #SLES, other distro background a bonus
C, shell scripting, #perl, etc
Virtual Machine experience with qemu/kvm, #Azure, #AWS, VirtualBox, #Vagrant
General experience such as: radius/ #Kerberos, lda, ipa/idm, monitoring, vpn, containers, centralized systems management, automation (ansible, chef, puppet, etc), version control (git, etc) or security hardening (CIS, STIGS, PCI-DSS, etc)
Excellent written, verbal, and presentation skills
Knowledge of open source packages
Database administration; #postgresql/ #mysql/ #mariadb experience very desirable
Experience with Linux distro package building (#rpm, #deb, ipkg, etc) preferred
Existing contributions to the CentOS community a major plus
Interact with end users on technical problems.
Tier 1, 2 and 3 support for #CentOS and related open source products.
Drive resolution of those problems, which include:
Open source software issues.
Questions around open source software usage.
Questions around use and best practices.
Review of the architecture and design where software is implemented.
Conduct professional services and training engagements.
Research, understand, and advocate open source software.
Interact with various open source communities.
Drive early resolution of issues.
Make strategic contributions to the CentOS core and surrounding ecosystem, provide bug fixes ahead of the community where needed
Be a part of the on-call rotation.
Present knowledge via articles, blogs, and conference presentations.
Requirements:
Technical knowledge, skills and expertise in complex infrastructure, web-based software and enterprise software
Strong knowledge of the Linux #kernel and system architecture.
Understanding of software best practices; #SDLC, #SCM and #Agile development principles.
Ability to develop with #C / #C++ in a UNIX environment.
Utilization of common #Linux C/C++ build tools such as #gcc.
Solid understanding of CentOS 6.x and 7.x and included frameworks like #firewalld, #systemd, etc.
Strong #RHEL/CentOS background required
#Debian / #Ubuntu, #SUSE / #openSUSE / #SLES, other distro background a bonus
C, shell scripting, #perl, etc
Virtual Machine experience with #qemu / #kvm, #Azure, #AWS, #VirtualBox, #Vagrant
General experience such as: radius/Kerberos, lda, ipa/idm, monitoring, vpn, containers, centralized systems management, automation (ansible, chef, puppet, etc), version control (git, etc) or security hardening (CIS, STIGS, PCI-DSS, etc)
Excellent written, verbal, and presentation skills
Knowledge of open source packages
Database administration; #postgresql / #mysql / #mariadb experience very desirable
Experience with Linux distro package building (#rpm, #deb, #ipkg, etc) preferred
Existing contributions to the CentOS community a major plus
@musicman I don't really have any #Java language thoughts. In the late #1990s and early #2000s, I enjoyed the courses I took which used Java (and also the courses which used C++, #Perl, #PHP; but I disliked #JavaScript, and really disliked #VBScript and #VB 5 / 6). But especially since taking this job 15 years ago, I've barely touched it.
We support products on Windows, Mac, and #Linux. Occasionally, you might see some old Solaris or BSD servers (or some other random stuff), but that really doesn't happen much.
We support #git and #Jenkins integrations, as well as #maven and a bunch of other stuff I don't ever touch, but people on my team do.
Apache knowledge would be useful, but not required. My colleague who started the same day I did doesn't really do any scripting. He's pretty much a pure server performance guy. That said, we support APIs for #ruby, #python, #js, #groovy, #perl, #java, #c++ and #php. Also, #C knowledge would be useful
Basically, if you have any cross-platform experience at all, and are technical, you'd be a good fit.
We support products on Windows, Mac, and #Linux. Occasionally, you might see some old Solaris or BSD servers (or some other random stuff), but that really doesn't happen much.
We support #git and #Jenkins integrations, as well as #maven and a bunch of other stuff I don't ever touch, but people on my team do.
Apache knowledge would be useful, but not required. My colleague who started the same day I did doesn't really do any scripting. He's pretty much a pure server performance guy. That said, we support APIs for #ruby, #python, #js, #groovy, #perl, #java, #c++ and #php. Also, #C knowledge would be useful
Basically, if you have any cross-platform experience at all, and are technical, you'd be a good fit.
We support products on Windows, Mac, and #Linux. Occasionally, you might see some old Solaris or BSD servers (or some other random stuff), but that really doesn't happen much.
We support #git and #Jenkins integrations, as well as #maven and a bunch of other stuff I don't ever touch, but people on my team do.
Apache knowledge would be useful, but not required. My colleague who started the same day I did doesn't really do any scripting. He's pretty much a pure server performance guy. That said, we support APIs for #ruby, #python, #js, #groovy, #perl, #java, #c++ and #php. Also, #C knowledge would be useful
Basically, if you have any cross-platform experience at all, and are technical, you'd be a good fit.
We support products on Windows, Mac, and #Linux. Occasionally, you might see some old Solaris or BSD servers (or some other random stuff), but that really doesn't happen much.
We support #git and #Jenkins integrations, as well as #maven and a bunch of other stuff I don't ever touch, but people on my team do.
Apache knowledge would be useful, but not required. My colleague who started the same day I did doesn't really do any scripting. He's pretty much a pure server performance guy. That said, we support APIs for #ruby, #python, #js, #groovy, #perl, #java, #c++ and #php. Also, #C knowledge would be useful
Basically, if you have any cross-platform experience at all, and are technical, you'd be a good fit.
I have been told that once-a-day announcements are not annoying, so...
My team in Minneapolis !minnesota is hiring. There is nothing public yet, but if you're looking, hit me up.
We support products on Windows, Mac, and #Linux. Occasionally, you might see some old Solaris or BSD servers (or some other random stuff), but that really doesn't happen much.
We support #git and #Jenkins integrations, as well as #maven and a bunch of other stuff I don't ever touch, but people on my team do.
Apache knowledge would be useful, but not required. My colleague who started the same day I did doesn't really do any scripting. He's pretty much a pure server performance guy. That said, we support APIs for #ruby, #python, #js, #groovy, #perl, #java, #c++ and #php. Also, #C knowledge would be useful
Basically, if you have any cross-platform experience at all, and are technical, you'd be a good fit.
Being in our Minneapolis office is 100% a requirement. I don't make the rules, because that's a stupid one.
@sim I found #PHP to be fairly easy, but with strange inconsistencies (particularly function names). Unlike #Perl or #Ruby, I could come back to something six months later and quickly figure out what it did and how it did it. That was about 15 years ago, but it could still be true today.
I’m thinking about all the different programming and scripting languages I studied years ago. Years later, I can’t even tell you how to put the sections of a #COBOL program in the right order or how to tell what you were trying to do in a #Perl script or what to change in this decaying pile of #PHP in order to retrieve all posts in each conversation.