I'm with a company that was acquired by IBM ~2.5 years ago. The internal systems are definitely rough, but for the most part it's business as usual.
I've heard chatter from our engineering leadership that IBM is trying to push some silly initiatives, but we've been able to prioritize the right work so far.
I also get more equity (one time award + employee stock purchase plan) than I did previously, and with how IBM stock has been performing lately this has been a net positive for me.
FWIW I have heard that IBM used to force their management style on acquisitions in years past, so perhaps this is a fairly recent shift towards a less hands-on approach.
> FWIW I have heard that IBM used to force their management style on acquisitions in years past
Definitely wasn't like that for Red Hat. We had a CFO with an IBM past which was a really nice guy and never ever felt like he was parachutes from IBM.
Now after 6 years legal, HR and finance will move to IBM starting next January; but my perspective from engineering is that after the acquisition it's been and remains business as usual.
Haven't heard a damn thing about "RedHat" in years, though. It's dead as far as Linux distros go. I'm sure it's used in the IBM-o-sphere, but I'm just not around that at all.
Can't stand pre-commit hooks. I want zero delay on commits. Checks can be run against pull requests in a GitHub action runner; no reason to force me to run them on my machine.
The solution could be a pre-push hook. I am also not a fan of pre-commit hooks because I just want to commit my wip changes. Not stash. Commit.
It's fine if the auto formatting tool hasn't been run. If the pre-commit hook changes my files silently, that is a big no-no for me.
I have had tools break things before and it makes it very hard to work out what happened.
Having it fail to push means I get to choose how to fix up my commits - whether I want a new one for formatting changes etc or to go back and edit a commit for a cleaner public history.
I used to think pre-push was better than pre-commit but at some point I realized I was actually just kicking the can down the road and leaving bigger problems for myself. It's not downsides-free, but it's the better compromise for me.
As long as "don't get merged" includes squashing so that whatever your (non)hooks didn't catch locally don't end up causing failures for rebases/merge conflict resolutions for others (assuming there are repo-level hooks people are expected to be using).
Thank you. If we prosecuted scientists for a drug as well tolerated as finasteride we would cease to develop new medication and all of humanity would be worse for it.
If there was some indication that the pharmaceutical company knew of and concealed evidence that finasteride caused depression/suicidality, then there could be grounds for criminal prosecution. But a non-consensus view in hindsight that a drug might increase depression looks more like a losing civil liability claim.
Additionally, the kind of person who would reach for prescription medication vs accepting hair loss may be predisposed to depression. I.e. this may be selecting for people who struggle with self-acceptance generally.
I also wonder whether there's some degree of placebo going on. Patients know finasteride is anti-androgenic; perhaps when they inevitably experience some symptoms associated with hypogonadism they assume the worst and lament the choice between having hair and feeling youthful. This would also explain why many who get off finasteride don't notice their symptoms improve.
Personal bias: I've taken finasteride for years with no side effects.
Microsoft is not an abusive employer. Most people today or at any point in human history would envy the typical Microsoft job. Pretty much all large tech companies are similar in this respect. If your employer is actually abusing you in some way you should contact a lawyer. If you simply have a distaste for your employer you should seek alternative employment.
The defeatist "all corps are evil" mentality will not do you any good.
I didn't say it's an abusive employer but an abusive company.
It always fought against open source. Embrace, extend, extinguish. It always stifled innovation. Internet Explorer 6. And now, it bought GitHub and then plagiarized all public and private projects hosted on it. GPL cannot exist in a world where you can build a statistical model of the code and mechanically reproduce its functionality while somehow losing the GPL licensing in the process.
Also, calling it "defeatist" has no base in what I wrote. I didn't even write anything about corporations. Abuse has a much simpler description - using a power differential to benefit yourself at other people's expense.
Don't anthropomorphize organizations. It was no longer beneficial for them to openly fight open source so instead the people in charge decided they needed to get developer mindshare by changing their public signaling. The sad thing is many people fell for it. They can just as easily switch back at any time when it becomes beneficial.
BTW, the phrasing "Microsoft has embraced open source" is very ironic and given my previous paragraph, it is a nice foreshadowing or what can come next at any time.
> Are you claiming Microsoft/GitHub used or sold private source code for training LLMs?
I have not seen it denied in any official communication. After skimming this question[0], nobody else could either and the phrasing in their FAQ is oddly specific about Business and Enterprise. So yes, given their patterns of behavior, it's very likely and I will consider it true until proven otherwise.
But that's not the biggest issue. That is that every LLM or LLM-adjacent company (Microsoft included) seems to suddenly argue that a mechanical transformation of input data is enough to erase licensing and attribution.[1] Free software licenses like GPL simple cannot exist in this environment. In fact, any licenses would have exactly 0 meaning.
See a program you want with a license you don't want? Just run it through a sufficiently complex black box and out the other side you have an identically behaving program which according to big-tech has no relation to the input. You can even do this with closed source software if you run it through a decompiler first.
I recall a MS CEO shouting something about developers when developers were the thing they needed most. Now they can train NNs on the devs' own work to imitate and replace the devs so devs are no longer valuable and get thrown under the bus.
Oh and MS employees are apparently forced to use LLMs by management...
It's hard to build non-trivial web UI with any technology—React is just what's familiar. If Angular had won (god forbid) we'd be seeing all the same articles written about how bad Angular is.
Not sure I understand the conditional beef, perhaps you can give example? I would assume if you want `if condition, useEffect(...)` you could simply replace with `useEffect(() => if condition...)`, no?
Fair. My bitching would've been better expressed as "I groan every single time I attempt to violate a hook rule." Which is a lot, because I'm new to React. It's almost certainly a "skill issue", but hooks are NOT just "JavaScript functions", contrary to React marketing PR.
My conditional beef: in my app, users can choose between using the built-in mic for speech recognition or a 3rd party service (LiveKit). If the user chooses the built-in mic, I still must allocate memory for LiveKit's services because it's exposed as a hook, even if the user will never use it. This problem compounds - every option that I expose that uses a hook requires that I allocate memory for an option that may never be used. Also TTS - users can choose to use the phone's TTS, or a remote service, etc. Every option I offer, if the library exposes it as a hook (and they virtually always do), if I naively implement the feature, allocates memory for a hook that might never be used.
Fuck. React. Hooks.
My workaround is to conditionally render empty fragments. These fragments wrap hooks, which I then inject into the context. This makes it so I can conditionally run hooks. This is why I complained that React can handle conditional components, but not hooks. Concretely: https://pastebin.com/sjc3vXTd I'm using Zustand because god I need a lifecycle outside of React.
Y'know how people complain about how Async "colors" functions? Hooks are also a type of function coloring. And they don't compose with Async.
Yeah, this is a really annoying thing about how hooks work. For whatever reason (I'm sure they have a great reason) React can't do hook state book-keeping correctly without tying it to a function component lifecycle.
I think you actually can conditionally render a hook but that choice has to last for the entire rendered lifetime of the component. But that doesn't really help you when your user can switch between them.
Hooks can call other hooks, and all the built-in hooks rely on setState at the bottom. setState is state for the individual component. It keeps track of state across multiple calls with an indexed array - the first call is index 0, second call is index 1, and so on - that's why no key is needed to identify which setState call is which.
All the oddness about hooks fall out of that implementation. They can only be used inside components because they rely on component state management, and having to be called at the top level is a simplification of "hooks must always be called in the same order the same number of times" (no conditionals or loops) because otherwise the setState index gets messed up and you're getting the wrong state back when it's called.
You don't have to use their hooks! Looking at your pastebin link, I would probably opt for something like a factory pattern instead: https://pastebin.com/PbnBqX4a
Just because you're in React land doesn't mean you can't still write regular old js/ts and hook in only when you need it. I imagine you'd do something quite similar in any other framework.
It only takes 1 hook to pollute your entire factory pattern; the comparison to colored async functions wasn't spurious. Hook-only options seem especially prevalent in the React Native ecosystem (ironic, given the memory constraints of phones).
Of course, I could fork/go down to the native layer, but this just proves my point that React DX is hot garbage.
No, sadly. I use some features that require the usage of native code, e.g. native echo cancellation, foreground service to keep the audio running when the screen is off, etc. The sdk-js is meant for browsers.
The "winner" just had its 3000th release on GitHub, already a few patch versions past the version referenced in this article (which was published today): https://github.com/wppconnect-team/wa-version
I made a fairly significant (dumb) mistake in the logic for extracting valid semver versions. I was doing a falsy check, so if any of major/minor/patch in the version was a 0, the whole package was ignored.
Brief reminder/clarification that these tools are used to circumvent WhatsApp ToS, and that they are used to:
1- Spam
2- Scam
3- Avoid paying for Whatsapp API (which is the only form of monetization)
And that the reason this thing gets so many updates is probably because of a mouse and cat game where Meta updates their software continuously to avoid these types of hacks and the maintainers do so as well, whether in automated or manual fashion.
Considering the 18 billions price tag and the current mixing of user data between meta and WhatsApp I believe that meta has now revenue streams in mind than just the API pricing
The less people pay for software, the more companies are forced to look into other forms of monetization (and of paying engineers).
The idea of users paying (even 1$ per year) for whatsapp has already died, now we are normalizing companies not paying for it? Fuck that, software engineers should be paid. Stop normalizing stealing.
Hmm yeah, I decided that one counts because the new packages have (slightly) different content, although it might be the case that the changes are junk/pointless anyway.
I've heard chatter from our engineering leadership that IBM is trying to push some silly initiatives, but we've been able to prioritize the right work so far.
I also get more equity (one time award + employee stock purchase plan) than I did previously, and with how IBM stock has been performing lately this has been a net positive for me.
FWIW I have heard that IBM used to force their management style on acquisitions in years past, so perhaps this is a fairly recent shift towards a less hands-on approach.
reply