I’ve not built anything beyond simple scripts in rust but I’m looking at some of the cosmic codebase to see what I can do.
I’ve not built anything beyond simple scripts in rust but I’m looking at some of the cosmic codebase to see what I can do.
Kind of surprised this is getting so much criticism. It’s a thought experiment, not a call for a fundamental change to all PC UX. My only real argument against the idea is that it’s framed as being “for efficiency”. If you want efficiency above all else you would just go full command line.
How’s the battery life? I was considering one recently but saw some claim that the battery would only last 4-6 hours and that put me off.
Literally just bought what I believe to be last generation’s X13 on ebay for half the price of the new one. It’s been great so far, especially with the power efficiency of Ryzen CPUs. My one complaint is the soldered RAM, which judging by the new lineup is getting phased out, thankfully.
I’ve been programming for too long, my brain just autocorrected the typo so initially didn’t get the joke…
Again, this existed before AI. Typo squatting, supply chain attacks, automated package uploads, CI pipeline infection, they’re all known attack vectors. That’s not to say this isn’t a concern, just that it’s a known risk and the addition of “AI” doesn’t, to my eyes, increase that risk. If your SSH keys don’t require a password, you have taken the decision to make those keys less secure but more convenient to use. That’s pretty much always the tradeoff in security.
The risk here is slightly overblown or misrepresented. Just because a fork exists doesn’t mean that anyone has even read it, let alone run it on their system. For this to be a real threat they would have to publish packages with identical or similar names (ie typo-squatting) to public package repositories which this article didn’t have any information on but which is a known problem long before AI. The level of obfuscation and number of repos affected is impressive but ultimately unlikely to have widespread impact to anyone besides GitHub.
My take (having neither but building a NAS in the background of other jobs) is that if you don’t need the rack, don’t buy the rack. If you already have a NAS and you really want to play with the power that a rack would give you, go for the rack. If you don’t need it don’t buy it, simple as.
Personally I rename them to something meaningful and they get merged if there are no other references. PayPal is especially bad for completely meaningless rubbish in the payee field and they tend to be ad-hoc purchases so I don’t fiddle with them much. The category is the most relevant bit for me.
I think for most people it’s whatever you got used to first. I agree the hatred the GUIs get is overblown. I would always recommend people learn the command line but if you want to use a GUI, go for it, doesn’t affect me unless your commits are bad, in which case the CLI wouldn’t have helped anyway.
My friend and I are looking to make a game and the general consensus has been that perforce is still better than git LFS, so we’re setting up a perforce server. What is it about SVN and perforce that you miss? I’ve only ever used git professionally for VCS so I’m finding perforce’s always-online and exclusive-checkouts model just very strange (though I understand the need for it when working with binary files).
Wait are you talking about macos or Linux?
I’ve heard the argument as a positive of learning vim and while it did finally force me to touch type I can’t say that it had any impact on my programming speed.
I agree with those saying mailing lists are intimidating. I don’t know if others are using dedicated tools or something but I find web based mailing list UIs just incomprehensibly bad and difficult to navigate.
Yeah this is definitely a downside to using spare gear over purposeful purchases. I think it makes sense to use what I have and optimise later. I’ve got an old intel i5 and mobo I’m planning on using for the NAS. Need to find another use for my old Ryzen 5 2600X.
Thanks, the flexibility and closed source (I assume) of turn key solutions puts me off them. I’ve already got a raspberry pi running a few containers and I work with docker and Linux in my day job so I know a decent amount. The form factor of the turnkey solutions is the big draw for me at the moment to them as I’ve just got a spare ATX mid size tower handy. Would ideally replace with smaller case but then I’d need a smaller motherboard and that’s just raising costs for starting out. Potential upgrade path anyway.
Thanks for the suggestion. That wasn’t a standard format I was just trying to write them out in a way that represented what I was seeing in my DNS controller and now realise it probably would have been clearer as a table. I honestly wasn’t sure if *.local
would work either but it’s working great now.
Yes I’ve got the domain I just replaced example.com for explanation purposes. Yes I know public certs are easily searchable which is why I’m trying to use a wildcard domain (*.local
) which is public. Caddy should be handling the domain record updates as required but I would assume that I’d see an error from the API request to update the record before seeing the cert failure. Maybe it’s silently failing. I’ll check if possible.
I believe it’s 1% for access to the “entire post-open ecosystem”, rather than 1% per project which would be unreasonable. So you could use one or thousands of projects under the Post-open banner, but still pay 1%.
It will take years to develop the post-open ecosystem to be something worth spending that much on.