I would consider
threefour approaches.1. Commit and push manually and deliberately
I commit changes early and often anyway. I also push regularly, seeing the remote as a safe and remote (as in backup) baseline and reference state.
The question would be: Do I switch when I'm still exploring things in the workspace, without committing when switching or moving away from it, and I would want those on the other PC? Then this would not be enough.
2. Auto-push all local git references into a separate space on the git remote
Git branches are refs, commit pointers, just like other refs are. And they can be put under arbitrary paths.
refs/heads/holds branches. I can replicate and regularly update all my branches underrefs/pcreplica/laptop/*. And then on the other PC, list or fetch those, individually, or all of them, regularly automatically, or manually.sh
git push origin refs/heads/*:refs/pcreplica/laptop/* git ls-remote git fetch origin refs/pcreplica/laptop/*:refs/laptop/*3. Auto-push the/a local branch like you suggested
my concern here would be; is only one branch enough? is only the current branch enough?
4. Remoting into the other system
Are the systems both online? Can I remote into / connect into it when need be?
Has features ✅
we should just write the code how it should be
Notably, that's not what he says. He didn't say in general. He said "for once, [after this already long discussion], let's push back here". (Literally "this time we push back")
who need a secure OS (all of them) will opt to not use Linux if it doesn’t plug these holes
I'm not so sure about that. He's making a fair assessment. These are very intricate attack vectors. Security assessment is risk assessment either way. Whether you're weighing a significant performance loss against low risk potentially high impact attack vectors or assess the risk directly doesn't make that much of a difference.
These are so intricate and unlikely to occur, with other firmware patches in line, or alternative hardware, that there's alternative options and acceptable risk.
Code before:
js
async function createUser(user) { if (!validateUserInput(user)) { throw new Error('u105'); } const rules = [/[a-z]{1,}/, /[A-Z]{1,}/, /[0-9]{1,}/, /\W{1,}/]; if (user.password.length >= 8 && rules.every((rule) => rule.test(user.password))) { if (await userService.getUserByEmail(user.email)) { throw new Error('u212'); } } else { throw new Error('u201'); } user.password = await hashPassword(user.password); return userService.create(user); }Here's how I would refac it for my personal readability. I would certainly introduce class types for some concern structuring and not dangling functions, but that'd be the next step and I'm also not too familiar with TypeScript differences to JavaScript.
js
const passwordRules = [/[a-z]{1,}/, /[A-Z]{1,}/, /[0-9]{1,}/, /\W{1,}/] function validatePassword(plainPassword) => plainPassword.length >= 8 && passwordRules.every((rule) => rule.test(plainPassword)) async function userExists(email) => await userService.getUserByEmail(user.email) async function createUser(user) { // What is validateUserInput? Why does it not validate the password? if (!validateUserInput(user)) throw new Error('u105') // Why do we check for password before email? I would expect the other way around. if (!validatePassword(user.password)) throw new Error('u201') if (!userExists(user.email)) throw new Error('u212') const hashedPassword = await hashPassword(user.password) return userService.create({ email: user.email, hashedPassword: hashedPassword }); }Noteworthy:
- Contrary to most JS code, [for independent/new code] I use the non-semicolon-ending style following JavaScript Standard Style - see their no semicolons rule with reasoning; I don't actually know whether that's even valid TypeScript, I just fell back into JS
- I use oneliners for simple check-error-early-returns
- I commented what was confusing to me
- I do things like this to fully understand code even if in the end I revert it and whether I implement a fix or not. Committing refacs is also a big part of what I do, but it's not always feasible.
- I made the different interface to userService.create (a different kind of user object) explicit
- I named the parameter in validatePassword plainPasswort to make the expectation clear, and in the createUser function more clearly and obviously differentiate between "the passwords"/what
passwordis. (In C# I would use a param label on callvalidatePassword(plainPassword: user.password)which would make the interface expectation and label transformation from interface to logic clear.
Structurally, it's not that different from the post suggestion. But it doesn't truth-able value interpretation, and it goes a bit further.
Being able to build the app as you are trying to do here is an issue we plan to resolve and is merely a bug.
So it really is that simple: a small bash script, building locally, rsync'ing the changes, and restarting the service. It's just the bare essentials of a deployment. That's how I deploy in 10 seconds.
I'm strongly opposed to local builds on any semi-important or semi-complex production product or system.
Tagged CI release builds give you a lot of important guarantees involved in release concerns.
I'll take the fresh checkout and release build time cost for those consistency and versioned source state guarantees.
learned from 10 years/millions of users in production
10 years per millions of users is an interesting metric :P
I wasn't aware the GitHub terms of service explicitly grant / require you to grant permission to fork [within GitHub].
GitHub ToS section License Grant to Other Users
By setting your repositories to be viewed publicly, you agree to allow others to view and "fork" your repositories (this means that others may make their own copies of Content from your repositories in repositories they control).
If you set your pages and repositories to be viewed publicly, you grant each User of GitHub a nonexclusive, worldwide license to use, display, and perform Your Content through the GitHub Service and to reproduce Your Content solely on GitHub as permitted through GitHub's functionality (for example, through forking). […] If you are uploading Content you did not create or own, you are responsible for ensuring that the Content you upload is licensed under terms that grant these permissions to other GitHub Users.
It's been over 10 years since we released Rogue Legacy 1, and in the pursuit of sharing knowledge, we are officially releasing the source code to the public.
https://github.com/flibitijibibo/RogueLegacy1/
License head
Rogue Legacy 1's source code is made available under a custom license. Basically, you can compile yourself a copy, for free, for personal use. But if you want to distribute a compiled version of the game, you might need permission first. See the EXCEPTIONS.md page for more information.
Yeah, I thought the same. Pretty bad name.
Maybe all bunnies are actually snails with a fur coat on.
I would like to see TS as the first class citizen however, with JS being deprecated essentially.
What do you mean by that.
From what I read, Deno does primarily use and target TS. They label all that JS stuff as backwards-compatibility and ability for a migration path.
By Fresh you mean Fresh, the deno web framework? (So it's deno too.)
I'm not in (or into) the JS ecosystem. I'm glad I didn't have to dive into that at work yet. But I've used deno and bun in the past to evade installing NodeJS.
Just now I used deno v2 to build a static website I contributed a fix to, and it worked. I'm very glad to see I don't have to juggle different npm alternatives or be stuck without when I want to contribute but definitely do not want to install NodeJS.
The deno install was hilariously slow downloading and installing the JS libs into the node_modules folder. 150 MB of JS source code. For a simple static website generator.
Comparing it to the hugo.exe binary (go, single binary static website generator): That one is 80 MB. Not having to juggle many files makes it a lot faster and compact of course.
The deno.exe is 107 MB. Which is a chunky size; but man it provides a lot. When you contrast that to the node_modules folder… lol
The announcement also mentions and links to JSR for TypeScript module publishing platform, also with backwards compatibility and automatic stuff generating. Which also seems like a good effort.
Sharing for anyone else not familiar with AT Protocol:
The AT Protocol is an open, decentralized network for building social applications.
Account portability and Scalability through activity aggregation
Bluesky uses AT Protocol. The connected network/platform is called the Atmosphere.
Bluesky Social has pledged to transfer the protocol's development to a standards body. - Wikipedia
I didn't see any mention of other software/platforms using AT protocol on the protocol website or Wikipedia.
A strength of the GPL is that the community can fork projects, and "take them over" that way.
At the same time, and this instance is such a case, on a centralized platform, projects can be taken over instead of be forked.
They developed and published a plugin. Now it's been taken over by someone else, on the primary distribution and discovery platform, and they have no control over it. Worse than that, the takeover now offers their sold functionalities for free.
This makes the "open source but not free, but after two years true FOSS licensed" licenses look very useful if not necessary for businesses and developers that want to monetize. At the very least when they [have to] use centralized platforms.
- Jump
The ongoing feud between Wordpress and WP Engine is threatening open-source principles and good name
They have taken over the ACF plugin in the plugin store. In an intransparent manner. It is GPL licensed, but had a pro license and features sold. And still does have them on their publishers side.
A strength of the GPL is that the community can fork and take over projects.
At the same time, and this instance is such a case, on a centralized platform, projects can be taken over instead of be forked.
They developed and published a plugin. Now it's been taken over by someone else, on the primary distribution and discovery platform, and they have no control over it. Worse than that, the takeover now offers their sold functionalities for free now.
This makes the "open source but not free, but after two years true FOSS licensed" licenses look very useful if not necessary for businesses and developers that want to monetize. At the very least when they [have to] use centralized platforms.
What a mess.
URL is still advanced-custom-fields, but then named Secure Custom Fields. Translations and source repo still map to the old name. It definitely is a takeover, not a "fork" in the classic, established sense.
The problem with the takeover is, of course, that the original publisher still develops, publishes, and sells their original plugin. Their official website now serves their own version with their own update source.
So you kinda don't but also have to rename it to avoid confusion.
I think a rename to something different is wrong and confusing though. It should add a disclosing addition, like "(Taken Over)" or "Adjusted" or "WPorg edition".
A supposed, partial rename is confusing. No information in the README is confusing, intransparent, and disingenuous. No clarity in the release notes is confusing.
Simply freeing previously and still sold pro features, without disclosing that fact, is very questionable. Not fair to the developers and certainly not transparent to the community.
Clearing the changelog and release log documentation, removing previously available information, is questionable as well.
I see in the readme.txt file that the plugin is licensed under GPL.
So the changes are permissible. And being able to do so is certainly a strength of the FOSS license.
My biggest issue is that they remove information, and rename without indication. It should be transparent and, within context and concerns, fair. Not like this.
Looking at the commit log:
6 days ago, 6.3.6.1 was tagged with
Security - ACF defined Post Type and Taxonomy metabox callbacks no longer have access to $_POST data. (Thanks to the Automattic Security Team for the disclosure)
14 hours ago, 6.3.6.2 and rename
- Security - Harden fix in 6.3.6.1 to cover $_REQUEST as well.
- Fork - Change name of plugin to Secure Custom Fields.
It also removes is-pro and pro-license-active checks, but fails to disclose so in the release notes.
Effectively, it frees pro functionalities.
It also removes all previous change log and release information.
The follow-up quotes