I think a different way to spin this whole conversation is “you get what you pay for.” Prior to investing in a Secret Lab, I’d gone through several of the “top of the line executive office chairs” at some big box stores. They were shit. They fell apart, didn’t support me, and were made poorly. Most mass market gaming chairs are in that price range too so I expect their quality to be the same. Coincidentally, this is the point they make almost as soon as the video starts. I’m not able to pull up prices on the chairs they link (too lazy to Wayback those links) so I don’t know if I’m talking out of my ass or not.
For me, the $400 I spent on a Secret Lab was way better than the $1800 I could spend on an Aeron because I don’t feel comfortable in Aerons.
Edit: forgot to mention I am a totally different body type from you and my partner, who loves her Secret Lab, is very small. I think they’re great for all sorts of people.
This is how I use it. I’ve found a couple of jobs on LinkedIn. I’m currently happy at my job and not interested in dealing with passive searching so I check in maybe once a week to see visitors. Otherwise I don’t touch it at all.
What exactly is it? The only thing this landing page says is “7 problems and 2 other problems.” What does that mean? Do I have to do them right at 10a tomorrow during a work day? What does joining entail?
All of this is behind an account and I’m not sure I want to manage yet another account for something I can’t learn anything about.
If a repo is very popular, it should have a lot of forks. The higher the upstream popularity, the higher the downstream popularity. When a dev makes a claim that there are a ton of malicious forks stealing IP, we can vet that claim by looking at the forks that respect the upstream. Big projects have a big community with big forks with many stars. The popular downstreams drive traffic to the upstream.
In this case, we have a couple hundred direct forks. That’s not a ton. Out of those, only three have stars. All of them only have one star. At face value, that could imply a few things: the repo is not very popular, the community is centralized around the upstream, or something else along those lines. Comparing this to other open source projects, our initial conclusion is that this is not a hugely popular repo and does not get a lot of development outside of its incredibly niche community.
Occam’s razor is a tool, not objective truth. Based on the facts as we can see them, this focus on forking from the dev is much more indicative of a burnout spiral, incredibly common in the FOSS community, than nefarious actors. If we see receipts, eg a collection of takedown requests on malicious forks attempting to claim ownership of the code, our analysis falls apart. That’s still a possibility, however remote.
There were forks that wanted to hide the fact that they were Floorp forks, forks that did not want to contribute to Floorp at all, forks that used the code for life and just changed the name of Floorp, and many other forks were born.
There are three visible forks that have any stars. All of them have one star. You’re telling me that a project that is so widely and maliciously repackaged has no normal forks with more than one star? Is this tech that only bad actors want to use and has no following in the open source community?
Where are these evil forks, how do we actually know they’re forks, and why are they still up if they’re breaking license?
Edit: Here is a fork with 200+ stars that isn’t a direct GH fork. Given its premise is an opinionated and branded Floorp, is it morally wrong for its maintainers to not contribute to Floorp (assuming they don’t only for the sake of argument)? Does your answer apply to fediverse server owners (eg Mastodon, Lemmy) whose premise is hosting an opinionated and branded instance often explicitly without the technical skill to suggest patches?
You really shouldn’t apply a CC license to code. Someone who does that after saying what the dev said about not forking their open source code has no fucking clue what they’re talking about and is either about to spiral out or build something really dumb (or both).
I used to work in a municipal city water department. Part of its job was to deal with some chemical blooms from bad waste disposal. While I am not a water science person, I trusted the water science people who told me it was safe and got to tour some of the cool filtration things.
I didn’t drink the water because water in that area has a “green” taste that’s hard to describe unless you’ve had it. Totally fine to drink, just personal preference. Most people I know gave me a lot of shit for it.
This headline was incredibly confusing to me because, as an American, I’d never heard of “mobes” as slang for mobile phones. The article does open with “phone motherboards” so I thought it was either a typo’d “mobos” or someone had changed the slang for motherboard when I wasn’t looking.
What about a death from a drunk driver is an “unfortunate accident?” It’s not an accident, first of all, because you have to intentionally choose to break the law and operate heavy machinery while blitzed. Second of all it’s not unfortunate it’s fucking preventable because you have to intentionally choose to the break the law and operate heavy machinery while sloshed. I’d even go so far as to say it was fortunate because the drunk driver killed themself instead of someone else which a huge consequence that has led to it being against the law to operate heavy machinery while fucking hammered.
“Gee we’re sorry this person did the thing we tell you not to do from before you start driving it’s so unfortunate they made an intentional choice to endanger the life of anyone around them including themself this very bad decision we tell you not to make was clearly an accident”
Monoliths are the answer to bad microservices. Microservices are the answer to bad monoliths. It’s all cyclic and four different architects are going to have fifteen different opinions on how your system should be built. Do the thing that makes sense for your team and try to stay flexible.
Absolutes in programming tend to lead to bad designs. This is more a “I’m gonna stir up some shit on Twitter” post than real wisdom.
No microservices usually leads to bloated, tightly coupled logic that ignores business domains
No monoliths usually leads to sprawling microservice deployments with tightly coupled dependencies and flavor-of-the-week new ones
No Kubernetes usually leads to VPS pets or crazy obstacle courses trying to get SSL termination without a million fucking dependencies in a cloud container orchestration system that isn’t as good as Kubernetes
All Kubernetes usually leads to huge SRE costs for a tiny app
The same shit happened last summer when AWS came out with their “we dropped microservices for a monolith and look at our speed increase” article which ignored good design principles. Sometimes you should split things over business domains so you can deploy and code independently. Sometimes Kubernetes is the best way to handle your scale needs. The stories we normally read are about people doing it wrong (eg AWS making a bunch of microservices inside a domain sending fucking gigs of data between what should have been functions in a single service). Inexperienced folks don’t always know when to move from their minimum viable solution to something that can scale. That doesn’t mean you remove these things, it means you train on when you need them.
Should we abandon design patterns because singletons or flywheels aren’t the correct solution all of the time?
The simplest explanation is that my computer doesn’t know where to go for everything but does know where to go to get answers. It sends its traffic to the place that will know where to send things. Rinse and repeat until you finally hit the place you wanted to go.
The ostensible point is to prevent resellers from platforming your code. SSPL is an answer to, say, AWS offering your product much cheaper than you can. RSAL seems to be Redis spinning their own SSPL, BSL, whatever bullshit license because they’re not happy with the existing faux open source cloud licenses that prevent platforming.
There really isn’t a good way to handle this from an open source perspective. Cloud majors can and will undercut the fuck out of anyone to establish dominance. Ideally you’re providing a better support experience or working with them (until they decide to kneecap you) to maintain your business. Previously Redis had an paid tier that had functionality not available at the OSS level. I think that’s also legit.
I personally loathe the compliance issues these random shitty fucking licenses throw and don’t think trying to claw back business from majors is the right approach. The little guy is going to follow the path of least resistance which means you’ve made your software enterprise only.
MIT and BSD 2 are basically the same thing. BSD 3 extends BSD 2 with a limitation on using contributors to promote without permission. The BSD family is not copyleft.
wat