Might “Theone” perhaps be a better one to use? Still stays somewhat true to the pronunciation of Devin, but with an emphasis on being The One that might actually work /s
I would think that there’s definitely VC money in making your customers happy. What makes them happy might be different, but I believe the sentiment still remains
Wouldn’t that incentivize more intricate methods for large corporations to pay larger income? I understand what he’s going for, but I personally think that such a tax law might cause unintended consequences and perverse incentives
Today I learned. I always thought it was some “electricity magic thing” like additional heat generated within the power strips causing issues between the connected devices, but this makes a lot more sense than whatever I was thinking of.
Although I do think I might have mixed some things up between regular power strips and those outdoors/industrial ones with a long (double/triple digit meter) rollable cable which my dad was a big user of back when he used to work in construction. Basically back when I was little he used to tell me never to plug power tools into a rolled-up “power wheel”, and I think that when I was later heard you shouldn’t daisy chain power strips I must have made that (wrong) connection.
Surge protectors do have one magical electrical thingy in them: metal oxide varistors (MOVs). They're what shunt current in an overvoltage transient and they do age with usage.
I've always known surge protectors age and eventually stop protecting from surges. But what I always wanted to know is how can you tell when it expires? I'm assumings it's based on how good/bad/stable the electricity is in your area. But still, is there any way to know when it's time to replace?
Typically surge protectors have a little light to let you know if the surge circuitry is still good. Others will fail safe, meaning the won't power on if the circuitry is bad. Cheap ones may do neither.
Either way, if your house has had a surge and other equipment has died that wasn't surge protected, probably a good time to replace all surge protectors in the house, they're not really meant to survive multiple large surges. They shunt the power destructively, just somewhere you don't care.
> they're not really meant to survive multiple large surges. They shunt the power destructively, just somewhere you don't care.
Is this a concern when buying used rackmount power conditioners (like used for live music setups?), to protect home IT gear? Can they be worn out without a sign that they are?
What I've read is that their main failure mode is that, as they age, their trigger voltage gets lower and lower, and at some point the normal line voltage is enough to trigger them all the time. And when they overheat, either due to being triggered all the time or due to diverting a large surge, they fail open and no longer have any protective effect on the circuit. High quality surge suppressors would have fuses physically touching the MOVs, so that when a MOV overheats and fails, the fuse opens and cuts power to the now unprotected output.
It's about heat. Cable has some resistance and emits heat. This heat has to dissipate somewhere. If cable is rolled out, it'll dissipate heat to the air. If "power wheel" is not rolled out, cable will heat cables around. Outer cables will dissipate heat to the air, but inner cables will not. So with enough current and enough time, this thing will melt.
You probably won't have issues charging iPhone from this thing or powering something for few seconds, so no need to go crazy about it, just something to keep in mind.
I would actually think that monorepos suck with Github and others like that. Looking at the Linux kernel for example, that seems to me like a well executed monorepo outside of Github. From what I’ve heard and read, they specifically use Git and mailing lists instead of Github or others because Github wouldn’t work for what Linux is (aside from as a mirror).
There might very well be some context I’m missing, but that’s what I understand from that side at least.
they (well, Linus) invented git for their purposes, and not the other way around. They use git and mailing lists because that's how they work, and that's how they worked before git existed. git was built for them.
I think you have a story eyed view of github... You might want to go read Linus own thoughts on the matter in the linux GitHub backup repo
Git is a tool built for a project of the kernels scope, scale and organization.
Github is a thin web interface over top of that, it cuts some corners here and there and gets opinionated about how you should manage code (pull requests).
Think of it this way: most git hub projects end up with a monotonic output... the kernel isnt that. Between the current version someone is using, the next version that is being developed and the older versions getting back ports there's a lot going on there. Much more than GitHub and a pull request would cover.
Likewise, I think you have a starry-eyed view on how much friction it creates which equals less contribution. People see a bit of code they want to improve, they improve it, and then instead of just opening a PR (and perhaps iterating on it), now they have to learn a weird ancient e-mail workflow and will probably get chewed out for messing it up.
No one is saying to take away mail-in patches but it is positively archaic.
>> Likewise, I think you have a starry-eyed view on how much friction it creates which equals less contribution.
Is it friction? Or is it a filter?
You might remember being a kid and there was the sign in front of the ride that said "you must be at least this high to ride".... The kernel dev process isnt for casuals. It's designed that way.
There's a lot of folks out there who have popular projects on GitHub who are over the endless stream of BS from AI generated pull requests.
You should really dig in deep to what goes on with the kernel, the work flow, why it is that way and why GitHub is outright incapable of supporting kernel dev (there are reasons).... Your going to look at git in a very different way and many of githubs features are gonna feel on par with linkedin adding twitch style videos and zoom adding mail features...
> There's a lot of folks out there who have popular projects on GitHub who are over the endless stream of BS from AI generated pull requests.
So be stringent. First below-par PR get some guidance, pointers and perhaps a reprimand. Second time, a warning, third time a ban.
> You should really dig in deep to what goes on with the kernel, the work flow, why it is that way and why GitHub is outright incapable of supporting kernel dev (there are reasons)....
Code is code. If someone has an improvement, they can offer their new code.
I’m sure the kernel has a unique workflow, but it ultimately boils down to that, no?
Sometimes friction is necessary for quality. More often than not, I’ve seen github repos where issue is treated as a project manager and there are lots of drive-by PRs.
Github and gitlab are both deeply, fundamentally, flawed because the unit of contribution is the branch rather than the commit.
Other than the UI not being very good, the code review experience is fundamentally hampered unless you enable squashing but that's a bit shit for different reasons.
On a purely UX level too the velocity of getting patches in is terrible. They're designed for ad-hoc open source contribution, not tight-loops of consistent work. People put up with the slowness because they know no difference but I promise its slow. You shouldn't need to go and get a coffee to wait for something to get merged and start coding again.
A unit of contribution is always a branch, implicitly or explicitly. What you have in your local repository is a branch of what is in the central repository, which is a branch of what you have in your filesystem, which is a branch of what you have open in your editor. In the same way a contribution is always a merge, saving a file is merging the content of your editor in your filesystem, committing is merging your file in your local repository, and pushing is merging your local repository with the central repository.
That's git main insight, branching is everywhere, so it is designed with branching and merging as fundamental, explicit, and regular operations. Seeing how successful git is, it looks like it was a good choice.
GitHub and GitLab are built on top of git, and follow its principles, so that making the branch the unit of contribution is simply natural.
Of course, you can make single commit branches, in fact, that's what squashing is for. There is, of course, no obligation to wait before you have your change merged before you start working again, you can start from an earlier version and rebase later, merge back some changes, or do whatever you want really. You can tight-loop as much as you want, especially on your local machine.
The way (say) the kernel uses branches is not very similar to the way GitHub does it where you actually push a branch and then let the machine do the merge
It's the same ingredients but it's very hamfisted.
Squashing is like training wheels.
What I was hinting at with the loop concept is that it should be closer to phabricator that gitlab, let me stack.
Is it just me that think that’s a huge catch-22? The project isn’t eligible for grants because it gets money on the free market, but is then limited by who it can come from or in what amount
reply