A repo on GitHub I'm maintaining has grown with 200k downloads / month since I started working on it a year ago. My recipe? I added an npm badge in the readme showing downloads / month and I responded to every issue and reviewed every PR. Now there's so much issues and PRs coming in that we had to add an extra maintainer, feels great! Teamwork, fuck yeah!

Not every PR got merged of course, but every single one of them got reviewed. Just being a good and friendly developer, giving back to the community that has given me so much. Some tips for you maintainers out there. If you have a popular project and no time there's always someone else who's willing to spend time on it, ask around and you will surely find someone else.

Me: I have an input stream!
Library: I want a file.
Me: I can see your code, you will convert it to an input stream! Don't any of your constructors take an input stream?
Library: No. I want a file. Okay, you can also include an encoding.
Me: I don't care about encoding.
Library: Fine, just give me the file then.
Me: You mean I have to somehow convert my input stream into an actual file so I can give it to you?
Library: You're gradually catching on, yes.
Me: Can I add a new constructor myself that takes an input stream?
Library: Sure! Good luck in getting it approved by the maintainers and the new jar distributed everywhere, including Maven Central before your deadline.
Me: Fine, I'll just rearchitect everything so I can give you an actual file.
Library: And then everything will be fine.
Me:

Github Inc. (Feel good inc. parody)
=========================

Ha-ha-ha-ha-ha-ha-ha-ha-ha-ha-ha-ha-ha.
Github.
Fetch it, fetch it, fetch it, Github.
Fetch it, fetch it, fetch it, Github.
Fetch it, fetch it, fetch it, Github.
Fetch it, fetch it, fetch it, Github.

Fetch it, fetch it, fetch it, Github.
Fetch it, fetch it, fetch it, Github.

(change) Fetch it (change), Fetch it (change), Fetch it (change), Github
(change) fetch it (change), fetch it (change), fetch it (change), Github

Repos breaking down on pull request
Juniors have to go cause they don't know wack
So while you filling the commits and showing branch trees
You won't get paid cause it's all damn free

You set a new linter and a new phenomenal style
Hoping the new code will make you smile
But all you wanna have is a nice long sleep.
But your screams they'll keep you awake cause you don't get no sleep no.

git-blame, git-blame on this line
What the f*ck is wrong with that
Take it all and recompile
It is taking too lonnng

This code is better. This code is free
Let's clone this repo you and me.
git-blame, git-blame on this line
Is everybody in?

Laughing at the class past, fast CRUD
Testing them up for test cracks.
Star the repos at the start
It's my portfolio falling apart.

Shit, I'm forking in the code of this here.
Compile, breaking up this shit this y*er.
Watch me as I navigate.
Ha-ha-ha-ha-ha-ha.

Yo, this repo is Ghost Town
It's pulled down
With no clowns
You're in the sh*t
Gon' bite the dust
Can't nag with us
With no push
You kill the git

So don't stop, git it, git it, git it
Until you're the maintainers
And watch me criticize you now
Ha-ha-ha-ha-ha.

Break it, break it, break it, Github.
Break it, break it, break it, Github.
Break it, break it, break it, Github.
Break it, break it, break it, Github.

git-blame, git-blame on this line
What the f*ck is wrong with that
Take it all and recompile
It is taking too lonnng

This code is better. This code is free
Let's clone this repo you and me.
git-blame, git-blame on this line
Is everybody in?

Don't stop, shit it, git it.
See how your team updates it
Steady, watch me navigate
Aha-ha-ha-ha-ha.

Don't stop, shit it, git it.
Peep at updates and reconvert it
Steady, watch me git reset now
Aha-ha-ha-ha-ha.

Github.
Push it, push it, push it, Github.
Push it, push it, push it, Github.
Push it, push it, push it, Github.
Push it, push it, push it, Github.

[ Introduction ]
In Internet culture, the 1% rule is a rule of thumb pertaining to participation in an internet community, stating that only 1% of the users of a website add content, while the other 99% of the participants only lurk.

[ The story ]
A year ago I had a problem with X software.
I opened a ticket on its repository but a week goes by and no one responds. I need it to work! So I opened a pull request and it got merged in a day or two after a quick review.

Seeing that the tickets were many and the maintainers were few, I decided to stay and help.

Today, I am in the top #10 contributors.
I have made 20 commits and edited 4k lines of code. (Honestly, it's not that much, at work I do way more than that, anyway...)

This repository is an alternative to another popular closed-source software and it's massively used by well-known companies
(tech-giants).

[ Stats ]
User base: 20.000 (all of them are devs)
Total contributors: 200 (1%)
Contributors with more than 1 commit: 60 (0.3%)

[ Consideration ]
I would never have believed a year ago that participation could be so low despite the number of dev-users being so high.

The software does not require great technical expertise and if you are using it for work then you already have the skill-set you need to contribute.

Now listen, I know that not everyone wants to contribute. I know right and I respect it ... but really:

The 0.3% ?! Only 60 devs on 20k are active contributors?! Only 200 (1%) devs have ever made a single commit and then they left.

Holy sh**

I dont hate PHP, but I do hate when lazy admins do stupid things.
Why can't the PHP-maintainers do a proper website? Why the fuck can't I subscribe to mailing lists?

Well, it seems like when I do a request, the webserver sends a email with MY EMAIL. And guess what, the listserver REJECTS it because it fails DMARC.
They also refer to the manpage of ezman, but they have disable ALL the functions there too.

What kind of retards is doing that shit. I completely understand why people hate on PHP now.

This whole github thing is only yet again revealing, how many package maintainers are a bunch of instable psychopaths and should have somebody else manage the keys

be it one guy deleting all shit from npm and breaking worldwide babel installs or now raging toddlers deleting their repos with no actual readme notice or atleast placeholder repo and telling others to do the same

jesus fucking christ, how can the same person have developed such intricate package and then be an absolute manbaby throwing shit at strangers

Every time a distro defaults my editor to nano, I lose a brain cell. Why, why this crappy abomination of an editor? Distro maintainers, default to proper vim for an editor like real men! Fucking hell!

Got a CTO at my Unity job that's younger than me, which by itself is fine, but the only reason this guy was put into that position was because the previous CTO left the company at the time where I was relatively new and he is the person most familiar with the codebase of our primary project than I was at the time.

I understood the decision at the time, but still, having a position of power being handed to them just as a matter of inheritance doesn't command my respect. Nevertheless, I withheld my judgement at the time to see how his leadership goes.

Not even 1 year in and this young CTO started making jabs at me, calling my code hard to read and incomprehensible, to my face, in front of everybody else.

Motherfucker, I don't find his code easy to read either but I went out of my way to frequently ask him, the previous CTO and other teammates to clarify what they wrote here and there. He on the other, made no attempt to ask me for clarification and instead waited until company meetings to air these grievances.

Our boss started to ask me to follow SOLID principles (even though he can't recite what that acronym means) due to complaint from the CTO guy, even though the CTO guy doesn't even follow SOLID himself! But I took the higher road and didn't flip it right back on him.

What I did propose in return though, is that the dev team start using pull requests and have a code review process if the CTO wants to sign off on everything that gets in the codebase. Sounds reasonable enough, right? Not for this guy! He immediately starts complaining that reviewing pull requests would be more work for him. Motherfucker, you refused to go to my table to ask for clarifications about my code yet still want to understand what goes on, then do code review.

It was at this point that I realized that this guy doesn't actually want me to write good, clear code. He wants me to write code HIS way so that he can understand. Yeah okay, I can accept that idea in isolation. Some open-source projects require contributors to follow certain coding convention to make the maintainers' job easier too. One project that immediately came to mind is "In-game Debug Console for Unity 3D" (disclosure: I am a contributor to this project)

But guess what?

THIS COMPANY DOESN'T HAVE A FREAKING CODING CONVENTION. NOT WRITTEN DOWN ANYWHERE. NOT EVEN A VOCAL ONE.

What this CTO guy wants from me is a complete blackbox.

To all fellow devs out there, I hope you don't work with a CTO like this, or become one.

Sometimes I really fucking hate this company

The code is an absolute shitshow filled with static classes, untestable and duplicate code, on top of that my boss doesn’t like open source

Yeah so i’m not allowed to use a mapping library or something because “Uhhh like uhh we don’t have a contract with the company so who knows what’ll happen when the maintainers leave the project”
I understand his reasoning but it’s an absolutely retarded reasoning especially considering most of the .NET platform is open source nowadays

Writing a webapp from scratch now as well and I HAVE to use vanilla javascript and AngularJS 1.5 even though all the developers here told me they would like to upgrade to Typescript and Angular 2+ but it’s never gonna happen I suppose

Oh and he doesn’t like TDD and our only product is SAAS so imagine the amount of bugs being pushed simply because we don’t have time to write tests or even manually test, let alone refactor our horseshit codebase

AND i have to pay for gas myself which takes 200€ out of my bank account a month just for driving to work whilst I’m only getting a mediocre pay

Have a job interview tomorrow and another one on tuesday

Here's a real tip for people new to the industry.

It's one of those things that's been said over and over again but very few can really seem to employ. I suggest you learn it /well/.

You are not your code. Criticisms of your code, ideas, or your thought processes, is not a criticism of YOU. You absolutely cannot take criticisms of your work personally.

We are engineers. We strive to seek the best solution at all times.

If someone has found a problem with your code or with an idea or whatnot, it is coming from a place of "this is not the best solution", NOT "you're an idiot".

It's coming from a place of "I'm closing this PR because it is not a change I feel suits this project", NOT "I'm closing this PR because it's coming from a woman".

It's coming from a place of "This feature request is ridiculous/this bug is not actually a bug", NOT "you're a fucking idiot, fuck you".

It's coming from a place of "I've already had to address this in a number of issues before and it's eaten up a considerable amount of my time already", NOT "I don't even know you and this I don't have time for a nobody".

You do not get to be bitchy to maintainers because they denied your request. It's not a reflection of you at all. But if you're arguing with someone who has maintained a piece of code for almost a decade, and they're telling you something authoritative, believe them. They're probably smarter than you on this subject. They've probably thought about it more. They've probably seen their code used in many different places. They have more experience than you with that codebase in almost all cases.

Believe me, if we cared about who was behind all of the issues, pull requests, etc. we get, we'd get NOTHING done. Stop taking shit personally. It's a skill, not a defense mechanism. Nobody has the time to sugar coat every little thing.

Let's normalize directness and stop wasting time during technical discussions into opportunities for ego-stroking and circle-jerking and back-patting.

Why is it that pretty much zero package & framework maintainers understand semantic versioning?

1. If you do a complete rewrite of your package, but the resulting API is identical, you don't need to bump to the next major version. As a user, I'm thankful for your increased performance or cleaner internal code, but it doesn't really affect my update process.

2. If your package required some-framework 6.0.0, and now ALSO supports some-framework 7.0.0 but is still compatible with 6.0.0, you don't need to bump to the next major version. As a user, I can now upgrade the framework, and know that the package will keep working, but otherwise it doesn't really affect me.

3. Following your versioning along with the framework/language version is super annoying, especially if your library really doesn't need to differentiate between framework versions because it's not actually utilizing new framework functionality.

4. On the other hand, if you stop supporting a certain language, framework or shared library version, or change the public methods, exceptions, fields, etc, you MUST bump to a new major version.

Yet everyone gets this wrong.

For example, many of Laravel's underlying subpackages (for collections, filesystem, database, config, http, mail, etc) do not change their code in a breaking way, or do not even change at all between major framework versions.

Yet they follow along with the major framework version.

Now if someone makes a library "laravel-elasticsearch" which uses the support libraries and collections from laravel, they need to update their package to move along with the versions as well, and often they choose to number their library along with the framework in turn.

This means that to update the framework, you also need to update over 9000 dependencies.

FOR NO FUCKING REASON. THE ONLY CHANGE IN THOSE FUCKING DEPENDENCIES IS TO UPDATE COMPOSER.JSON TO BE COMPATIBLE WITH THE FUCKING FRAMEWORK.

Meanwhile, Laravel itself breaks repeatedly on minor/patch version updates, because breaking changes slip through their review process.

Ugh.

I need to invent time travel so I can go back to Friday morning and slap my past self for thinking that Linux From Scratch might be a fun weekend project. I should've gone to bed four hours ago and instead I've been shouting at LLVM.

It really makes me appreciate the hard work that Linux distro maintainers put in to keep all the pieces up-to-date and compatible with each other. I already want to put my fist through my monitor and I'm only trying to maintain a single virtual machine.

** PSA to all programming language and tool maintainers **

Please for the love of god have a dedicated examples section on your website where people can quickly evaluate what the thing even looks like

So often the next best thing is going to the docs where they tell you that the turboblub option should be set to 12 in these specific usecases whEN I DON'T eVEN KNoW WHETHER THIS IS A PROGRAMMING LANGUAGE OR A LAWN MOWER

Start-up I'm working for as a front-end dev is pretty nice. I have good hardware, free coffee and my coworkers are all decent people. My boss is chill, and I have flexible work hours.

There is this one policy for writing code, however. And I simply cannot understand it, nor can I ignore it because of code reviews: no comments in production code.

I mean, what? Why? Comments are nice, and they make life easier for the future maintainers. At least let me put a small two-liner explaining why I did stuff this or that way. But no, I only get to explain it verbally (once) to the person reviewing my PR. Why, man?

Github 101 (many of these things pertain to other places, but Github is what I'll focus on)

- Even the best still get their shit closed - PRs, issues, whatever. It's a part of the process; learn from it and move on.

- Not every maintainer is nice. Not every maintainer wants X feature. Not every maintainer will give you the time of day. You will never change this, so don't take it personally.

- Asking questions is okay. The trackers aren't just for bug reports/feature requests/PRs. Some maintainers will point you toward StackOverflow but that's usually code for "I don't have time to help you", not "you did something wrong".

- If you open an issue (or ask a question) and it receives a response and then it's closed, don't be upset - that's just how that works. An open issue means something actionable can still happen. If your question has been answered or issue has been resolved, the issue being closed helps maintainers keep things un-cluttered. It's not a middle finger to the face.

- Further, on especially noisy or popular repositories, locking the issue might happen when it's closed. Again, while it might feel like it, it's not a middle finger. It just prevents certain types of wrongdoing from the less... courteous or common-sense-having users.

- Never assume anything about who you're talking to, ever. Even recently, I made this mistake when correcting someone about calling what I thought was "powerpc" just "power". I told them "hey, it's called powerpc by the way" and they (kindly) let me know it's "power" and why, and also that they're on the Power team. Needless to say, they had the authority in that situation. Some people aren't as nice, but the best way to avoid heated discussion is....

- ... don't assume malice. Often I've come across what I perceived to be a rude or pushy comment. Sometimes, it feels as though the person is demanding something. As a native English speaker, I naturally tried to read between the lines as English speakers love to tuck away hidden meanings and emotions into finely crafted sentences. However, in many cases, it turns out that the other person didn't speak English well enough at all and that the easiest and most accurate way for them to convey something was bluntly and directly in English (since, of course, that's the easiest way). Cultures differ, priorities differ, patience tolerances differ. We're all people after all - so don't assume someone is being mean or is trying to start a fight. Insinuating such might actually make things worse.

- Please, PLEASE, search issues first before you open a new one. Explaining why one of my packages will not be re-written as an ESM module is almost muscle memory at this point.

- If you put in the effort, so will I (as a maintainer). Oftentimes, when you're opening an issue on a repository, the owner hasn't looked at the code in a while. If you give them a lot of hints as to how to solve a problem or answer your question, you're going to make them super, duper happy. Provide stack traces, reproduction cases, links to the source code - even open a PR if you can. I can respond to issues and approve PRs from anywhere, but can't always investigate an issue on a computer as readily. This is especially true when filing bugs - if you don't help me solve it, it simply won't be solved.

- [warning: controversial] Emojis dillute your content. It's not often I see it, but sometimes I see someone use emojis every few words to "accent" the word before it. It's annoying, counterproductive, and makes you look like an idiot. It also makes me want to help you way less.

- Github's code search is awful. If you're really looking for something, clone (--depth=1) the repository into /tmp or something and [rip]grep it yourself. Believe me, it will save you time looking for things that clearly exist but don't show up in the search results (or is buried behind an ocean of test files).

- Thanking a maintainer goes a very long way in making connections, especially when you're interacting somewhat heavily with a repository. It almost never happens and having talked with several very famous OSSers about this in the past it really makes our week when it happens. If you ever feel as though you're being noisy or anxious about interacting with a repository, remember that ending your comment with a quick "btw thanks for a cool repo, it's really helpful" always sets things off on a Good Note.

- If you open an issue or a PR, don't close it if it doesn't receive attention. It's really annoying, causes ambiguity in licensing, and doesn't solve anything. It also makes you look overdramatic. OSS is by and large supported by peoples' free time. Life gets in the way a LOT, especially right now, so it's not unusual for an issue (or even a PR) to go untouched for a few weeks, months, or (in some cases) a year or so. If it's urgent, fork :)

I'll leave it at that. I hear about a lot of people too anxious to contribute or interact on Github, but it really isn't so bad!

Don't you just love it when an official Docker image suddenly switches from one base image to another, and they automatically update all existing tags? Oh you've had it locked to v1.2.3, guess what, v1.2.3 now behaves slightly differently because it's been compiled with OpenSSL 3. Yeah, we updated a legacy version of the software just to recompile it with the latest version of OpenSSL, even though the previous version of OpenSSL is still receiving security fixes.

I don't think it's the image maintainers or Docker's fault though. Docker images are expected to be self-contained, and updating the base image is necessary to get the latest security fixes. They had two options: to keep the old base image which has many outdated and vulnerable libraries, or to update the base image and recompile it with OpenSSL 3.

What really bothers me about the whole thing is that this is the exact fucking problem containers were supposed to solve. But even with all the work that goes into developing and maintaining container images, it still isn't possible to do anything about the fact that the entire Linux ecosystem gives exactly zero fucks about backwards compatibility or the ability to run legacy software.

Worst:
Going through bankruptcy

Best:
Getting out of it, joining a team that is so on the edge of everything, that asking questions on SO is useless, and they can only be answered by us debugging the platform itself, as suggested by its maintainers.

... To boldly go where no man has gone before

This might not resonate with many ranters here... but FUCK Taylor Otwell & Graham Campbell.

Like, not on a personal level. Maybe they're great to drink a beer with. But as framework devs... fuck everything about them.

Laravel seems so nice, it takes away many annoyances of developing in PHP. Collections are the array object you've always needed. The route bindings, middlewares, request validation objects, it's all sweet.

But eventually your company serves a few million customers, you run into specific performance problems or missing features on a deeper level. You open the issue tracker... and see a few hundred issues about the problems you are encountering, they already exist.

Some just have a short paragraph with a request for a feature, some complete PRs with tests in the style of the framework. All of them closed.

Reasons?

"We don't think anyone will ever need this"
"This seems complicated, you can just do <super non-DRY hacky code>"

FUCK YOU WITH YOUR TODO APP SNIPPETS AND USER-POST-ARTICLE EXAMPLES. I'M NOT BUILDING THE NEXT WORDPRESS. I'M DEALING WITH THE REALITY OF GRAPH DATABASE CLUSTERS, COMPLEX AUDITING LOGS AND A GAZILLION QUERIES PER SECOND.

Sigh... the problem with all these "simple" and "elegant" languages & frameworks is that they don't fucking scale.

Not because the language, server or framework intrinsically can't do it, but because the maintainers are stuck thinking in terms of their retarded non-realistic example apps.

I think I'll go back to my cave and write some Haskell or Rust to calm down.

tldr: maintainers can be assholes

So there's this python package+cli tool that I found interesting while browsing github and thought of contributing to it. Now this repo has around 2000 issues and multiple open PRs so seemed like a good start.

So i submit 2 PRs implementing similar features on different sites (it is a scraping repo). This douche of a maintainer marks comments various errors in the code convention not being followed without specifying what they actually were. Now I had specified that i was new to this repo so and would need his help (I guess this is one of the jobs of the reviewer). This piece of shit comments changes in the pr with one or two word sentences like "again", "wtf" and occasionally psycopathic replies. That son of a bitch can't tell what's wrong like wtf dude, instead of having a long discussion over the comments section of the fucking pr why can't you just point out what exactly is wrong and I'll happily fix that shit, but no, you have to be a douche about out it and employ sarcasm. Well FUCK YOU TOO.

Repository maintainers that close the issues without much explanation or a good solution just to lower the number of open issues...(┛ಸ_ಸ)┛彡┻━┻

Dear Arch Linux Maintainers. Why the fuck are you sending me my password in plaintext?! Not enough: You are sending me my fucking password every fucking month, so i do not forget it, because its important!??!?!?! WHAT THE FUCK! Fucking idiots...

I found out that a major open source project pulled in some of my code for an enhancement I wrote in my own repo. The code was modified some to match the current conventions of the project, but it contains some of my original comments so I know it was based directly off my code. I'm not entirely sure how to feel. On one hand I'm super stoked to know that the maintainers of the project actually looked at my code and included it. On the other, I'm a little bummed they didn't credit me or at least give me a little shout out...

In today's episode of kidding on SystemD, we have a surprise guest star appearance - Apache Foundation HTTPD server, or as we in the Debian ecosystem call it, the Apache webserver!

So, imagine a situation like this - Its friday afternoon, you have just migrated a bunch of web domains under a new, up to date, system. Everything works just fine, until... You try to generate SSL certificates from Lets Encrypt.

Such a mundane task, done more than a thousand times already... Yet... No matter what you do, nothing works. Apache just returns a HTTP status code 403 - Forbidden.

Of course, what many folk would think of first when it came to a 403 error is - Ooooh, a permission issue somewhere in the directory structure!

So you check it... And re-check it to make sure... And even switch over to the user the webserver runs under, yet... You can access the challenge just fine, what the hell!

So you go deeper... And enable the most verbose level of logging apache is capable of - Trace8. That tells you... Not a whole lot more... Apparently, the webserver was unable to find file specified? But... Its right there, you can see it!

So you go another step deeper and start tracing the process' system calls to see exactly where it calls stat/lstat on the file, and you see that it... Calls lstat and... It... Returns -1? What the hell#2!

So, you compile a custom binary that calls lstat on the first argument given and prints out everything it returns... And... It works fine!

Until now, I chose to omit one important detail that might have given away the issue to the more knowledgeable right away. Our webservers have the URL /.well-known/acme-challenge/, used for ACME challenges, aliased somewhere else on the filesystem - To /tmp/challenges.

See the issue already?

Some *bleep* over at the Debian Package Maintainer group decided that Apache could save very sensitive data into /tmp, so, it would be for the best if they changed something that worked for decades, and enabled a SystemD service unit option "PrivateTmp" for the webserver, by default.

What it does is that, anytime a process started with this option enabled writes to /tmp/*, the call gets hijacked or something, and actually makes the write to a private /tmp/something/tmp/ directory, where something... Appeared as a completely random name, with the "apache2.service" glued at the end.

That was also the only reason why I managed fix this issue - On the umpteenth time of checking the directory structure, I noticed a "systemd-private-foobarbas-apache2.service-cookie42" directory there... That contained nothing but a "tmp" directory with 777 as its permission, owned by the process' user and group.

Overriding that unit file option finally fixed the issue completely.

I have just one question - Why? Why change something that worked for decades? I understand that, in case you save something into /tmp, it may be read by 3rd parties or programs, but I am of the opinion that, if you did that, its only and only your fault if you wrote sensitive data into the temporary directory.

And as far as I am aware, by default, Apache does not actually write anything even remotely sensitive into /tmp, so...

Why. WHY!
I wasted 4 hours of my life debugging this! Only to find out its just another SystemD-enabled "feature" now!

And as much as I love kidding on SystemD, this time, I see it more as a fault of the package maintainers, because... I found no default apache2/httpd service file in the apache repo mirror... So...

"This is ridiculous, why don't the docs explain this? This is absurd, it seems like thousands of people should be having this issue. Why do maintainers fucking not get it? Why write software if you don't intend for anyone else to use it?"

versus

"Hey, could you explain X to me? I'm having trouble understanding it."
"Sure, here: ..."
"Thanks - maybe we could add it to the docs, that's the first place I looked."
"Absolutely, good idea."
<closed in a8b7cb8d>

Which one was easier, folks? It's not this difficult. 100% going to help you if you ask - to me, at least, there's no such thing as a stupid question (seriously, I'll answer the most inane questions 100 times over if I need to). However, there's definitely a stupid comment, and unfortunately they seem to be the majority I receive on Github.

Other team lead: Hi DevOps Team, We need you to deploy this app to production. It's maintainers gave up on it in 2019, but we looked at it and it feels right.

Me: Uhm. That's not going to work. It'll fail the security scan before you can even finish the build in CI.

Other team lead: Yeah, this app is the right thing to do, and we needed it last week, but since that won't work, we'll just use this other very very infant technology that was just born yesterday. It's not stable in production, or on MySQL, or in AWS at all, but it's the other direction we can to go.

Me: What problem are you trying to solve in the first place?

Other team lead: Oh, we need access to the read from the production database.

If Java versions can coexist on a system
If all java versions have their own packages on the AUR
If you can change envvars in a launch script and be sure that all processes of the application will persist your settings
Then why THE FUCK do package maintainers keep announcing to change the default java version to install their package, rather than explicitly doing that by themselves? Fuck off, do you really think yours is the only package that needs a specific Java version? Do you think each and every user will write their own init script, or edit the PKGBUILD to include the new version as an envvar in the desktop file? This is why Arch has a bad name, and they're fucking right. If you don't have the time to put a single motherfucking diff in the motherfucking pkgbuild to specify the java version in the desktop file, then don't fucking maintain the package. I know there are too few maintainers, but pretending to maintain a package while doing fuckall is much worse than leaving it unmaintained on the AUR so the first person who has time can pick it up.

One of two ways.
1. Alot of opensource companies will startup hiring developers based on what contributions they provide
2. The current companies will fire most of the devs to exploit free work from opensource devs offering pennies as bug bounties while only keeping very few maintainers.

Thanks GitLab.

After I get notifications about the final replies to my 6 month quest of updating someones GitLab README, I didn't expect MY fork to have been modified ( and thanks to that, made ugly / they removed all spacing, vertical & horizontal )

Where the fuck even was the option that GitHub offers where it prevents people from just doing whatever to your shit in a PR?

Why the fuck isn't this a permanent setting for either ( lab & hub ) so I don't have to manually turn it off every single time.

I didn't even think about that option up until now, since the maintainers didn't touch anything and everything seemed fine, but now that it was about to be merged, they suddendly got the bright idea of squashing everything into one commit and that on my fork itself, .. really helpful.

Arch has a great default package manager, and it's the basis for why I love Arch as much as I do.

A completed install is pretty minimal, and as a user who knows what apps I want, that's perfect for me. When I've used any other major distro of late, my post-install activity mostly consisted of removing software, changing defaults, and otherwise swimming upstream against the intent of the distro's maintainers.

With Arch, I start with a more or less blank slate, and then add the components I want to it. It's so intensely satisfying to have a system that is composed almost entirely of software I explicitly wanted to have.

The result is a system that behaves pretty much exactly the way I want.

Any other Arch users want to weigh in on what they like about it?

Dear debian package maintainers...
If you want me to add you PPA to my list please MAKE SURE IT FUCKING WORKS!

so after 1000 emails from Google baiting me to try Google cloud tools I did. 24 hours later apt-get is dead and I'm trying to remove the shit storm of gpg keys etc it added to my machine.

Literally slept off during this zoom call. I just woke up I don't wth everyone is talking about. Turns out my PR was up for discussion. Now I have to review a bunch of shit I thought I was done with. OS maintainers can be a pain sometimes 😭

Lesson learned: Always use node LTS in production, library maintainers are lazy af.

Any individual project that made me learn cool stuff...

Maybe the kernelcheck project? It's a shell script that I wrote 2 years ago (it's still on my GitHub but the code looks kinda horrible tbh), and it really made me respect the stability of package managers, and the effort that package maintainers must put into it. Even a single package (the kernel) that you have to maintain the integrity of the .config for (the configuration file that tells you what options to compile in, as a module, or not at all) while on every new minor release, the config changes ever so slightly.. at some point I figured that I'd really need to do those compilations manually, to be able to supervise (and if necessary adjust) it in real-time. The ability for distribution maintainers to do this for thousands of packages.. it boggles my mind. Respect!

Context: New to typescript. Writing a thing, doing it for work, good opportunity to stretch my dev legs. Using a propriety lib, alternatives not an option.

Rant begin:
SOOOO, who the fuck thought THIS was a good idea:
1. Lib has minified react in dev (because closed source) meaning no downstream errors AND the entire premise of the lib is that a widget is a react component, so I'm writing typescript react the entire time without downstream errors
2. SHIT docs. By that, I mean there's an API reference page that's so sparse there's literally a set of CRUCIAL interfaces that only say the word 'Interface' on them. That's it. that's what i get. It's an interface. NO FUCKING SHIT SHERLOCK, what the fuck is it though? What's its purpose? Is it an interface for a dog? A dog that has a 'shit' property? or a cat? or a cat eating dog shit? Nobody fucking knows - the docs sure as fuck don't care.
3. No syntax highlighting - editors, IDEs (i've tried a few) can't even find the lib inside this environment, so Code and everything else thinks I'm importing shit that doesn't even exist - so no error prediction, code completion based on syntax of the library, none of that.
4. There are some EXTREMELY basic samples - these samples exclusively use React classes - no function components, no hooks, nada - just classes and even perfect replicas of the sample code display erratic behavior like errors about missing props, so that's mostly FUCKING USELESS
5. And this... this is where the straw breaks the fucking camel's back... there's no... there's no hot reloading... Do you know what that (in conjunction with the previous 4 fuckups) means?

When I write anything or I fuck up (which of course I'm doing every time I write half a line because how the fuck?) I have to restart the client and server EVERY FUCKING TIME and manually test to see if the error (THAT ONLY GETS REPORTED IN THE LOCAL UI) is gone or different.
Then, once I see the error, it isn't an error: it's the minified React error-decoder link and guess what? It isn't really clickable a link OR copyable, meaning that every FUCKING time I get a new error, I have to MANUALLY TYPE A FUCKING 50 CHAR URL TO FIND OUT A GENERIC REACT ERROR MESSAGE WITHOUT A LINE NUMBER OR ANY FUCKING CONTEXT. I HAVE TO DO THIS CONSTANTLY TO SEE IF ANYTHING I'M DOING EVEN WORKS.

6. There's no github to complain to the maintainers or search for issues because it's NOT FUCKING OPEN SOURCE so there is literally nothing to be fucking done about it.

This is due in a week and a half, found out about it last Friday. How's your day going?

PS: good to be back after a long respite from dev ranting.

I need some opinions on Rx and MVVM. Its being done in iOS, but I think its fairly general programming question.

The small team I joined is using Rx (I've never used it before) and I'm trying to learn and catch up to them. Looking at the code, I think there are thousands of lines of over-engineered code that could be done so much simpler. From a non Rx point of view, I think we are following some bad practises, from an Rx point of view the guys are saying this is what Rx needs to be. I'm trying to discuss this with them, but they are shooting me down saying I just don't know enough about Rx. Maybe thats true, maybe I just don't get it, but they aren't exactly explaining it, just telling me i'm wrong and they are right. I need another set of eyes on this to see if it is just me.

One of the main points is that there are many places where network errors shouldn't complete the observable (i.e. can't call onError), I understand this concept. I read a response from the RxSwift maintainers that said the way to handle this was to wrap your response type in a class with a generic type (e.g. Result<T>) that contained a property to denote a success or error and maybe an error message. This way errors (such as incorrect password) won't cause it to complete, everything goes through onNext and users can retry / go again, makes sense.

The guys are saying that this breaks Rx principals and MVVM. Instead we need separate observables for every type of response. So we have viewModels that contain:

- isSuccessObservable
- isErrorObservable
- isLoadingObservable
- isRefreshingObservable
- etc. (some have close to 10 different observables)

To me this is overkill to have so many streams all frequently only ever delivering 1 or none messages. I would have aimed for 1 observable, that returns an object holding properties for each of these things, and sending several messages. Is that not what streams are suppose to do? Then the local code can use filters as part of the subscriptions. The major benefit of having 1 is that it becomes easier to make it generic and abstract away, which brings us to point 2.

Currently, due to each viewModel having different numbers of observables and methods of different names (but effectively doing the same thing) the guys create a new custom protocol (equivalent of a java interface) for each viewModel with its N observables. The viewModel creates local variables of PublishSubject, BehavorSubject, Driver etc. Then it implements the procotol / interface and casts all the local's back as observables. e.g.

protocol CarViewModelType {
isSuccessObservable: Observable<Car>
isErrorObservable: Observable<String>
isLoadingObservable: Observable<Void>
}

class CarViewModel {
isSuccessSubject: PublishSubject<Car>
isErrorSubject: PublishSubject<String>
isLoadingSubject: PublishSubject<Void>

// other stuff
}

extension CarViewModel: CarViewModelType {
isSuccessObservable {
return isSuccessSubject.asObservable()
}
isErrorObservable {
return isSuccessSubject.asObservable()
}
isLoadingObservable {
return isSuccessSubject.asObservable()
}
}

This has to be created by hand, for every viewModel, of which there is one for every screen and there is 40+ screens. This same structure is copy / pasted into every viewModel. As mentioned above I would like to make this all generic. Have a generic protocol for all viewModels to define 1 Observable, 1 local variable of generic type and handle the cast back automatically. The method to trigger all the business logic could also have its name standardised ("load", "fetch", "processData" etc.). Maybe we could also figure out a few other bits too. This would remove a lot of code, as well as making the code more readable (less messy), and make unit testing much easier. While it could never do everything automatically we could test the basic responses of each viewModel and have at least some testing done by default and not have everything be very boilerplate-y and copy / paste nature.

The guys think that subscribing to isSuccess and / or isError is perfect Rx + MVVM. But for some reason subscribing to status.filter(success) or status.filter(!success) is a sin of unimaginable proportions. Also the idea of multiple buttons and events all "reacting" to the same method named e.g. "load", is bad Rx (why if they all need to do the same thing?)

My thoughts on this are:

- To me its indentical in meaning and architecture, one way is just significantly less code.
- Lets say I agree its not textbook, is it not worth bending the rules to reduce code.
- We are already breaking the rules of MVVM to introduce coordinators (which I hate, as they are adding even more unnecessary code), so why is breaking it to reduce code such a no no.

Any thoughts on the above? Am I way off the mark or is this classic Rx?

NEVER maintain multiple release branches as a maintainer, period.

Given enough PRs, nobody, not even god-tier maintainers, is able to keep track of all commits and the whole context/story behind it.

Remember that people ALWAYS PR against your master and nobody even cares about your whatever-named-next-branch buried deep inside your feature branches.

Please make it easy for others if you want actual contributions.

Why are OSS maintainers so fucking incompetent and cocky? A documentation clearly says to use "use_parent_assets: true" when creating a child theme. Yet not a single fucking line of code actually checks that value. The fix is literary a single if(value) assets = deepMerge(parentAssets, assets). But because some contributor somewhere didn't write that line to the maintainer's liking, it's been hanging in the air for months.

Take your head of of your ass, there's thousands of people paying for support & addons for your product, and you can't add one fucking line to fix a rather critical bug.

Calling any Python programmer here (especially package maintainers)

I run Gentoo, so am responsible for maintaining the dependency tree (to a degree). When it comes to Python I have 2.7, 3.4, 3.5, 3.6 available. I'm always running into some package needing one version or another, and I can't just set a single version and forget it (which is fine. I'm running Gentoo).

I know that this is because python changes rapidly and so different libraries need different versions. Fine.

Why does this happen with Python and not C++, JavaScript, php, ruby, or any other languages on my system? I don't have 3 different versions installed to cover any other languages, and I don't spend time adding installation rules to cover them.

Why does Python need to be a pain in the ass about it?

I love open source. Really.

BUT I hate maintainers/owners who do not respond to any kind of message/issue/PR for months.

Also of course they dont tell you how you can setup the dev environment yourself :)

!rant - it's a THANK YOU!

Had the problem so far that I could not start some apps in docker containers with GPU support (e. g. Chromium).

After a long search and a lot of help from the community, today's update of xf86-video-ati (1:7.8.0-2 -> 1:7.10.0-1) has finally fixed the bug. Yay!

Thank you very much Arch Linux and all the great maintainers. You're doing an awesome job.

Why do package maintainers stop answering and go silent?!

I've waited for more than two weeks on acceptance on my PR, the maintainers hasn't been active and I've even notified them of my worries.. But so far no activity.

Why the fuck does a package like date-fns have maintainers that doesn't answer? Furthermore, I can see one of them making private contributions on Github..

I need this package to help on another package to finish my project 😭

I don't like when maintainers ask me how their module works in review. >:c

It always works me up a little bit.

And when people spawn process for something that can be done with unistd. >>:(

I think it's not professional.

I must say the worst thing is the whole "branding" of closed and open source software. Giving systems/platforms/repositories/projects/libraries names that makes no sense, just for the sake of standing out. Just god damn call a shoe for a shoe...the difference lies in the creator/maintainers and not in the fucking name...sry

Sometimes I need to talk about what I create. Which requires fucking Powerpoint 'cause you have to distribute your shit to dorks who only can live with this crap.

And then every single fucking time I touch that stinking abscess I have visions of shoving some white glowing rod of spiky steel up the arseholes of the inventors and maintainers of Powerpoint, enjoying their screams and regretting that I will be able to enjoy this exquisite pleasure only once per asshole.

Microsoft owed a lot of its product development to the VB language. VB6 made an acute impact in the dev world. With a RAD environment, a proper language that executes to the machine level. A good IDE etc etc.

VB.NET broke a lot of balls due to the fact that the .NET framework came to the world and C# became a special name in the .NET arsenal. for years, both languages were hand on hand. With a bunch of neckbeards hating on VB.NET and another group of neckbeards advocating for VB.NET to step in to their roots concerning the VB6 standard.

Fast forward and Microsoft is complete hating on VB.NET regarding the .net core environment.

This is for me the biggest hurdle with Microsoft technologies, while I love C#, I am very hesitant to trust in their technology stacks since they have a thing about ignoring things they developed. Remember Visual Fox Pro? ded, remember classic ASP with VBScript and JScript? dead

Shit like that makes me not trust Microsoft, F# is a fascinating language, but nothing stops me from believing they will discard it at one point or another.

Honestly, there is nothing wrong with VB.NET, I feel that the language is fucking easy to get, a glimpse of a VB.NET project and I know what is happening, the syntax, as verbose as it is, really makes it easy for anyone to follow along with it.

The problem? Because it is so easy to work with, most devs in that realm never bothered to move forward, which is why there are no big projects build with this language, as such, people coming forward as maintainers are rare, and few in between.

I just want to go back to the good ol days of RAD and for Embarcadero to get their heads out their ass and release Delphi for everyone. Object pascal is dummy easy.

usually the worst drunk coding problem i have is leaving nasty comments in the code about the previous maintainers. Or ranting more vehemently on here than is really warranted... ;)

In other words it doesnt affect my coding, it just affects my social skills.... lol...

Imagine you decide to spend a few hours to contribute to an open-source project wiki/documentation that hasn't been updated in years, to actually make it useful for new users, and then the maintainers start expecting further modification and corrections from you before pulling the PR, like you work for them, instead of just fucking pulling it in and then editing what they want themselves. It's just another example of how stupid and nonsense the open-source community can be.

>> Herborist fails
>> Fixes QT errors
>> Still fails. Relink issues of libudev ; for weird reasons, it's asking to be linked to librt ??? And it's for a clock-gettime.
>> stack overflow: all about cuda and opencv, which can't be my issue.
>> Some asshat on GitHub comment section: mind your language when you're talking to maintainers.

>> Me: You mothertucking trucker! 😐😐😐

🖕🖕🖕

If you're running Manjaro and use mesa...
...yeah, you should definitely run your pacman (or wrapper thereof) with -Syyuu. Otherwise their fake-upgrade mess that they've done yesterday will likely break something on your system, too.

I wonder how many github issues have been closed by asking the author to implement the feature they've requested for. In the past, I was confident my issue will be resolved by opening a new one when there's no answer in earlier questions. I can't tell whether the nature of my questions advanced or whether it's a new trend. But I've opened maybe 4/5 issues in recent memory, and each time, the collaborators suggest the feature is one I should contribute to their project by implementing. Isn't this their job as maintainers? I'm already working on something that barely gives me breathing space. I encountered a challenge using your library, and your idea of helping is that I dissent from my own trajectory, acquaint with your project /how to implement what I want, wait for it to get merged etc, before continue what I originally intended. Do they think that's worth it?

Is it just me or is this a common occurrence, lately?

Fuck Oracle, fuck you oracle! The stupidest shittiest worst nightmare company with the most user-unfriendly, productivity-killing, illogical, stupid pile of software garbage products ever! And unfortunately I want to extends my worm-fucks to all Oracle employees and maintainers and to the whole fucking community of shit that made up oracle-community and to every conscious being who ever liked, enjoyed or have found the slightest genuine interest of any product tagged "oracle".

I installed the pile of shit a.k.a Oracle 18c and imported a dumb file locally, everything was working in the slightest amount of the word (fine) before it turns to nightmare. I created a C# client to call a stored procedure in that shit of a database engine. I kept getting error related to the parameter types, specifically one which is custom type of Table of numbers. It turns out that the only of doing this is through that shit they called (unmanaged driver), the "managed" doesn't support custom types. So I had to install another package of shit they call (odbc universal install) "universal my a$$ by the way", at that moment, where everything just crashed and stopped working. I spent 3 hours trying to connect to the fucking database to no avail. I shockingly found a folder in my desktop folder called (OracleInstallation) and all windows services related to oracle installation "suddenly" got somehow (re-routed) to that folder.
In conclusion, fuck oracle.

"In the presence of good rationale, maintainers should be willing to change their mind often." - Havoc Pennington

Is it fair that oss auhtors/maintainers are not being contributed to by for-profit companies that rely on their products even though the licence allows?

That feeling when you go back to a project you haven’t touched in months, upgrade one of the dependencies to a new major version (come on how many breaking changes will actually affect this tiny project), and find nothing is compiling because the library maintainers renamed everything and introduced a lot of breaking changes that are actually relevant

#Suphle Rant 11: Laravel board launch

The launch took almost 2 weeks more than originally slated, because I sought to install it manually, just as an outsider would. Installation steps had been documented, automated tests for the installation tests were passing. When time came to actually execute the binary from the terminal, we went from one obstacle to the other. First, were the relatively minor Composer/Roadrunner issues, eventually resolved by the helpful RR maintainers who sat with me through a Discord server for about 2 hours until their command ran the way I needed it to.

Next was the Psalm scare: One of my value propositions was the guarantee of eliminating all type related bugs in Suphle apps. I intended to use Psalm for that. Wrote tests as usual. Turns out the library behaves differently under conditions differing from raw CLI usage. I resurrected threads I'd opened since December that were left unattended, and with some help from the maintainer, we eventually got it to do what I need it to do.

I was all the more frightened by the fact that Transphporm had caused me to renege on one of my earlier promises. I can only miss so many targets. After this, the docs had to be updated with all the changes effected to accurately integrate those two. Project installation and initialization commands were ran rigorously to ensure all progresses smoothly.

Tagged one final release and suddenly became impatient to launch on our local Laravel group chat where I've been a member for the last 4+ years, where we've had a rollercoaster of emotions. In that time, I've refined my launch speech to suit that audience -- obviously, countless times. Not just a tame "It's my pleasure to announce what I've been working on", but near 40 messages going into details about the inner workings, why it was built, how it compares. An expose that dove deeper than I would anywhere else.

I scheduled a time for them to tune in and got some encouraging anticipation. Ended up deflated after posting the whole thing. Only about 5 persons interacted. 1 (who I've chatted with outside the board) was quite enthusiastic. Feverishly checked the docs but commented it was overwhelming and he'd need more time. Already starred the repository.

For some context, there are give or take 250 members on that board. Not all are active but activity there easily reaches a crescendo when the topic discussed is about inanities like what 3rd party services to use for SMS, how to receive salaries from abroad, or job openings. I was optimistic when the acquaintance mentioned above published a payment library and met a riotuous welcome as one of their own. Maybe, they are simply not fond of me and the speech should have been passed off to someone else.

I checked Packagist installs -- not more 10. For 3 years, I'd been hyped up for that night; but for some reason, the audience I considered myself closest to flopped, woefully. Thankfully, this isn't the main launch. I'm still holding out hope for that. If it fails, I would have sunk an immeasurable amount of effort and time, that nobody will compensate me for. That is the one place I go to see those more advanced than me in PHP. I constantly learn there and find stimulating conversations there.

Now, I can no longer predict reception from other presentations. All I can do now is hope

"In the presence of good rationale, maintainers should be willing to change their mind often." - Havoc Pennington

finally!
I've been waiting all week for the Manjaro maintainers to release the next update wave.

Ahh... finally something to do in the terminal :)

Why are big software documentations versioned by url rather than adding the most current update to relevant sections and signifying it as such?

1) only select parts of the software is updated in between major version updates. Why duplicate the entire docs for only sparingly updating those parts?

2) references hold versioned urls that could go out of date. I imagine it takes some effort to have a banner on each page indicating whether this is the most up-to-date version of the software

3) deprecated documentation is redundant since it's no longer maintained. Why does it continue to exist? Not everyone has upgraded, you say. That, and I guess, it costs the maintainers nothing to have an idle folder 6 major versions behind the most recent

I already have a folder for my v1 but I'm considering pulling them into a permalink. What challenges or disadvantages are there to doing so?

When learning a new language I look up public repos on github, specifically those who are just collections of algos in different languages, and take a look + try to implement it in a different way. The good ones also have maintainers that actually take a look at your code when you open a PR and give you some hints if they are proficient in that language.

Microsoft is acquiring Node package manager npm Inc., officials announced on March 16. (Neither company is sharing the purchase price.) Microsoft plans to integrate GitHub with npm with the intent of making the combined community even more appealing to JavaScript developers.

GitHub CEO Nat Friedman said " npm is a critical part of the JavaScript world. The work of the npm team over the last 10 years, and the contributions of hundreds of thousands of open source developers and maintainers, have made npm home to over 1.3 million packages with 75 billion downloads a month. Together, they've helped JavaScript become the largest developer ecosystem in the world. We at GitHub are honored to be part of the next chapter of npm's story and to help npm continue to scale to meet the needs of the fast-growing JavaScript community."

Source : Github Blog

I dont get it. Please give me one good reason to use mongoose with a mongoDB.
Once upon a time it might have made sense to use a schema for the db. Today the native driver supports schemas and can check them on inserting. Nevermind one should validate the data before its hitting the db. I listened to an 1hr podcast last week where one of the maintainers tried to give reasons why its might be a good idea to use mogoose, and he failed miserably.
It introduces dependencies that are useless, it doesnt really abstract anything useful from the native driver, its TS support is shit and I dont like the API.
Every time I see someone use it he either fails or doesnt explain at all why to use it. Its so redundant it makes me angry. We have enough abstraction already. We really dont need more code that doesnt provide value. Please just use mongo the way the people of mongoDB intended it to be used.

People are like programming environments, in basics all people are the same like all programming environments are the same, every programming language have a loop and conditions, numbers, strings and dates. The problem starts with syntax to write code or can you call it communicate with person. There are syntax errors, someone use functions and classes and that’s ok but someone is writing everything in one file and then it’s hard to communicate or change something. But the real problem are libraries or you can call it believes. Everyone is believing something but when you start using it and want some advanced functions there’s always something missing. When you want to contribute to fix that stuff you often can’t cause it’s closed source or maintainers are pricks. You end up writing wrappers and decorators, ignore malfunctions to somehow live with that problem. That’s called social skills.

We’re just programming environments. That’s all.

"In the presence of good rationale, maintainers should be willing to change their mind often." - Havoc Pennington