So I cannot emphasize this often enough but guys, spare yourself a lot of stress and troube by not becoming a Gentoo developer or try to mess with them (even with valid bug reports).
One recent example can be seen in Gentoo bug #891179 where a simple request of making a questionable information about dependency calculation time in portage optional revealed once again what kind of people can be found in Gentoo nowadays.
Arrogance at its best.
Well done fellas!
Keep in mind: These two guys are just among the worst examples.
There is a simple feedback like "Hey I don't like it, can we make it different". There's even a provided solution. HOW it could be improved. And all which comes back is: "How dare you to waste our time!!" - What a wonderful work environment you have here... I bet there are dozends of potential devs waiting in line to help out with Gentoo development... not.
For those which are still interested why people leaving, here you can get a short glimpse on the hostile work environment a few people create for everyone.
By the way: Don't be surprised when the bug "unexpectedly" disappears now that it's subject of this blog. Altering facts is common practise in Gentoo nowadays just like spying on emails (am I right, Sam? --> pts/27 
).
Let's see how many people are getting triggered this time.
It's one thing being accused for slandering. It's another thing being publically called an asshole. So here's another great stunt from Gentoo. First read this PR:
Reinstate poly-c overlay #532
And now have a look for what I was banned in their GitHub organization:
And IMHO there's nothing more to add here.
Like I've blogged recently, Gentoo has
removed my overlay from their list based on completely false assertions. That's not so much of a problem for me as I know how to get my overlay into Gentoo systems but other users of that overlay might have more difficulties to keep the overlay. As a result I've uploaded a
config file for those users so they can simply drop that file into
/etc/portage/repos.conf/ directory and run
CODE:
emaint sync -r poly-c
in order to re-gain access to my overlay. I hope that helps those users that got "punished" by this extremely strange move Gentoo did there.
This morning my E-Mail account at Gentoo was suspended.
Now it seems to be back and mails are being forwarded to my private E-Mail account. Please don't send any more E-Mails to my @gentoo.org address but instead replace the host part of my address with @gmx.de. I do not really want having Gentoo jerks reading private mails.
If you nevertheless want to send an E-Mail to my @gentoo.org address, please encrypt the mail with my public GPG key.
Mikrotik is known for its cheap 10GBit/s switches. That's the reason I bought one of these back in 2021. Although buying 10GBase-T transceivers is not that cheap, in the end I replaced my good ol'
Netgear S3300-28X with the
Mikrotik CRS236-24S+2Q+RM running SwOS-2.13. I know the switch can also run RouterOS but to be honest, I do not like the complexity of RouterOS, nor do I need an OS on my switch that provides lots of functionality I definitely will never use (on a switch).
Unfortunately, SwOS comes with a couple of drawbacks:
- SwOS has a limited password length: It accepts twelve chars but not 20. I didn't check if twelve really is the limit but SwOS refuses to save passwords with 20 chars.
- No ssh connections possible: All SwOS provides is a very basic http web interface.
- No https connections possible: The web-interface can only be accessed via http.
Now all these drawbacks are not present in RouterOS but still, that one is totally overloaded with functionalities one never needs in a L2 switch. Furthermore, one small misconfiguration in RouterOS and 10GBit/s transfer speeds are gone because everything gets routed over the switch CPU which is only connected to the switch chip with a 1GBit/s line.
There's one really annoying bug in SwOS-2.13 though, that only recently got confirmed by Mikrotik: The two QSFP+ ports
refuse to re-establish a link connection once the remote side gets rebooted. In order to re-establish the link, I found three possible solutions:
- Reboot the switch. (most effortful solution as the entire network connected to the switch is down while the switch performs the reboot)
- Un-/replug the QSFP+-cable at the switch. (similarly effortful)
- Toggle auto negotiation from "auto" to "40G" or vice versa.
And these are the actions that do
not work and will
not solve the link issue:
- Reboot the remote device again.
- Un-/replug the QSFP+-cable at the remote side.
- Replace the remote NIC (if possible).
- Use a different QSFP+ cable.
Mikrotik promised a fix for a future SwOS release but I doubt this release will come anytime soon as their priority clearly is with RouterOS (where - again - this issue is not present).
Besides these issues the switch performs really great and - when using a proper transfer protocol - provides reliable 10GBit/s on all of its ports. In summary I do not regret my decision and once Mikrotik finally puts some love into SwOS again, this will become a very nice and satisfying switch for my home network.