Over a few days I wrote a bunch of #C++, #Rust, #Haskell, and #Python. Something I don’t get is that while I might say that Python has the most extensive ecosystem, it seems to have the worst tooling in terms of package management and LSP features (clangd, rust-analyzer, hls, and pylsp). How does that happen? Why don’t the economics that plow programmer hours into Python libraries raise the level of its tooling?
@tek I start most of my new projects in #C. Unless there's a logistical reason (like when a company has a group project in a chosen language), developers should be allowed to program in whatever languages they feel most comfortable with and/or most prolific with. I feel that's especially true if it's a personal FLOSS project. Just because one developer may not like or may not be efficient with a language, does not mean all developers will have those same issues.
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.
Perforce is seeking an Open Source Software Support Engineer to join our OpenLogic team, responsible for providing 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. This critical position demands a systems engineer with strong networking skills and some programming capabilities. You would be responsible for ensuring the success of our customers by effectively providing dependable and timely resolutions related to open source software. The ideal candidate is expected to be self-motivated, proactive, results-oriented and able to provide a high level of customer satisfaction through the delivery of world-class technical support services.
Responsibilities:
Interact with end users on technical problems; Tier 1, 2 and 3 support for 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 Be a part of the on-call rotation Present knowledge via articles, blogs, and conference presentations.
Requirements:
Minimum of 2 years of software development and design or systems administration or level 3-4 technical support experience; At least 2 years in a senior position ( senior/lead developer, engineer, or DBA); Minimum 3 years implementation and troubleshooting experience on 3 or more of the following: #ActiveMQ, #CentOS, Apache Tomcat, #PostgreSQL, Apache HTTP Server (#httpd), Java Development Kit (#JDK), #Wildfly Application Server, #Jenkins CI, #ApacheKafka, or #ApacheCassandra; Preference given to candidates with implementation and troubleshooting experience on one or more of the following: #ApacheCassandra, #ApacheKafka, #ApacheSolr, #Couchbase, #DockerCE, #ElasticSearch, #Kubernetes, #MongoDB, #Redis, #WSO2, #ApacheNifi, #Kubespray, #Minio, #Foreman, #Kiali, #Terragrunt, #OpenLiberty, or #Kong Strong #RHEL/CentOS background required #Debian/ #Ubuntu, #SUSE/ #openSUSE/ #SLES, other distro background a bonus #C, shell scripting, #Python, etc; #Linux distro package building a plus (#rpm, #deb, #ipkg, etc); Virtual Machine experience with #qemu/ #kvm, #Azure, #AWS, #VirtualBox, #Vagrant; database administration (not just db "power user") experience very desirable; #postgresql/ #mysql/ #mariadb experience preferred; Experience working in production environments, especially enterprise/carrier environments; General experience a plus such as: radius/Kerberos, ldap, ipa/idm, monitoring, vpn, containers, centralized systems management, automation (#ansible, #chef, #puppet, etc), version control (#git, etc), security hardening (CIS, STIGS, PCI-DSS, etc); Technical knowledge, skills and expertise in complex infrastructure, web-based software and enterprise software; Excellent written, verbal, and presentation skills; Knowledge of open source packages; Experience speaking at conferences/comfortable speaking in front of large crowds; Fast and creative thinker, quick on their feet to respond quickly to complex and difficult problems Proven track record of acquiring strong proficiency in new technologies quickly.
* #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, ...
Finding the #Nim language interesting because it reminds me of !Python.
It has some similarities to #Python, at least on the surface level that the 2nd video explores, along with compiling to #C (so interfacing with C via FFI is said to be “easy”).
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
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.
Freenode's programming language communities in particular are very bad.
##C: "go fuck yourself, here's an uninformative manpage" ##C++: "go fuck yourself, no, really just go fuck yourself, also here's a link to the isocpp documents" #python: "just use twisted" #<any functional language>: "I am better than you and I will make this known immediately"
I'm a long time (10+yrs) KDE #developer, mainly Plasma and a few libraries below it.
Often poisoning the C++ world with monads, ... - at conferences, on my blog, and through the book I'm currently writing - Functional Programming in C++ (with Manning) https://cukic.co/to/fp-in-cpp
Proud maintainer of the only KDE project written in Haskell.