I was having this discussion the other day with a friend, I do believe as an adult you should be allowed to do anything you want providing you're not harming others.
That said, there is a HUGE need for more regulation around advertising, cut off limits and companies recognising users with a problem.
If you take a Bar for example, most barmen will notice you're already drunk as hell and cut you off, probably kick you out if not get you some water etc. It's actually a legal requirement to stop at some point in countries.
Casinos on the other hand, if you are down 99,000 out of your 100,000 with zero hands of games won, that casino is going to plow you with a good time until it has that last 1,000. It's disgusting.
I hate gambling , I've seen its effect on friends of mine and their families. But I would never stop an adult doing what they want, while knowing the risks.
So would an Unlicensed Speakeasy, but I can't include them in the post or else everything would be destructive. I'm not defending Gambling at all, just highlighting there is a difference in how they are allowed to behave, which I also don't agree with.
Asking a casino to behave better is never going to work, adding more regulations and stricter licensing might. The fact that betting companies are now allowed to advertise and sponsor sports is an incredible negative step.
Yes to that last part. It's made watching sports much less enjoyable to see/hear constant gambling ads. And it's not like they're charging any less for the product (mlb.tv, for example) - quite the opposite: they are making it harder to watch all the games by putting some of them on apple.tv, etc.
Yes I'd agree from the perspective of the model that one cohesive well established language would be more reliable. The nightmare scenario is an enterprise suite with a Hodge podge mix of every language known to man all mangled together because the frontier model at the time decided Haskel would be the most efficient when compiled for webassembly and some poor intern has to fix a bug that should cost 100x less than rerunning the LLM to patch.
Yeah I don't quite get his point here. He seems to be complaining that enterprise companies buy from other enterprise a d larger companies instead of him. It's a tale as old as time.
Enterprise buy from large companies because those large companies come with support teams, liability, expertise that you don't need to manage internally.
It rare I read an article that actively annoys me but there's something about how this is written that seems a little arrogant.
I don't know about the market manipulation part. But messing with a weather station in an airport, presumably one that is used by pilots and air traffic control for safety critical operations (METAR) is likely to be very illegal, maybe with prison sentences.
I am pretty sure that's the reason why they chose a weather station at an airport. In addition to being public information, it is not something normal people want to mess with.
This is entirely by design. From a shareholder's perspective, the only thing that matters is number go up, when you take over a struggling company, they will squeeze every last drop of life from it in order to get some profit.
The fact that they are being quite secretive about their outsourcing, or at least not publishing it as a restructuring plan that they lay out to customers, is a little scummy, but makes sense for private equity. Milk as many people as they can while they still trust the brand.
From a shareholder's perspective, it's working as expected. And that's the real issue. If brands took more care of not expanding too fast that they require private equity and give away their ownership of the company slowly, then with patience and customer respect, we see its a good mix. But it seems people just get greedy or something and want it all faster.
I imagine it comes down to if they want to buy hardware every generation, that gets very expensive and depreciates quickly. You've then got a whole load of assets on your books that are technically obsolete for the bleeding edge. This way, AWS buys and maintains the hardware and OpenAI doesn't need to claim it as depreciation ?
This is not the problem the title makes it out to be.. It's still in development.
> "Now, when we say it's a final version, it's ... still a demo version." He added the final product is not yet available for citizens and "the code will be constantly updated and improved … I cannot today exclude or prejudge if further updates will be required or not."
The whole idea of this age requirement is ridiculous in the first place, changing the focus to how good or bad the unnecessary tools are is nothing but a nice distraction.
I think I'm missing some major selling point of jj, to me it's just git with a different flow that might be more suitable for a rare few cases where heavy parallel work is happening, and even then git is fine if people know what they're doing, the idea of no staging areas doesn't appeal to me, mutable commits seems actively negative to me personally.
I understand if people are enjoying it great, but the amount of praise and 'this is revolutionary' comments I see makes me really feel I'm missing a beat.
You have to look at it from the workflow side not compare the tool on your current git workflow. Check out https://www.stacking.dev for a description of stacked commits, which is more the everyday workflow on jj than the octopus in this article.
> If using a tool doesn't speak to you, git is adding more support for stacking every day. The new --update-refs option lets you update a stack with fewer rebases; however, parts of the stacking process are still tedious (i.e. opening PRs on GitHub or any other provider).
Don't necessarily need heavy parallel work, or even anything parallel, to make use of jj; it's very nice for even just manipulating one local sequence of commits (splitting commits up, reordering them, moving files/hunks/lines between them or into/out of the working copy, without needing to checkout anything).
Won't get you much if you don't like to mutate commits in general, of course; at that point it's just a different committing workflow, which some may like and some dislike. (I for one am so extremely-happy with the history-rewriting capabilities that I've written some scripts for reinventing back a staging area as a commit, and am fine to struggle along with all the things I don't like about jj's auto-tracking)
As a fun note, git 2.54 released yesterday, adding `git history reword` and `git history split` in the style of jj (except less powerful because of git limitations) because a git dev discovered jj.
> Basically, in the megamerge workflow you are rarely working directly off the tips of your branches. Instead, you create an octopus merge commit (hereafter referred to as “the megamerge”) as the child of every working branch you care about. This means bugfixes, feature branches, branches you’re waiting on PRs for, other peoples’ branches you need your code to work with, local environment setup branches, even private commits that may not be or belong in any branch. Everything you care about goes in the megamerge. It’s important to remember that you don’t push the megamerge, only the branches it composes.
> You are always working on the combined sum of all of your work. This means that if your working copy compiles and runs without issue, you know that your work will all interact without issue.
You don't even push the megamerge to the origin. Or perhaps you don't even need to push it. You can just... work off it.
> You don't even push the megamerge to the origin.
But why would I do that with git anyway ? My local branch is what I'm working of, if I'm not ready to push, why would I ? I can as you say just work off it..
And when I'm ready to push, I prep my commit, because I'm expecting it to be immutable and pulled by others 'as-is'. Again, I must be missing something. I think the tool is just not for me, yet at least.
I've often found myself needing to work on two features at once, esp. where one has a dependency on the other. Maybe that branch is the real goal, and the other branch is an independent chunk of work that the feature needs.
Both get iterated on, because it's hard to know everything about a feature before it's done; maybe you find bugs that need fixing, or you realise you were missing something.
Rebasing the dependent branch onto the tip of the other branch gets you there, but as a workflow it's not pleasant, especially if you're not the only person working on the features... It's a recipe for conflicts, and worse that rebased branch conflicting with another person's view of it.
Another example is that there is this simple monorepo that holds both the latest _BlaJS_ frontend and the backend API.
You are working on stuff in the backend, but it sure would be nice to see it in the frontend so you jury rig something in the frontend to display your work as well as some console.log() commands. Then you forget to revert changes to the frontend before pushing the branch.
In jj you would start with these as separate branches. Then you work on a merge of these. Then you use the absorb command to auto-move the code you are working on to the correct branch or you squash the changed files to the branch. Then you can push the backend branch to server and PR it. Then you throw away the frontend branch or just leave it there so you can use it in a future feature.
A real case from my work. I had to work on an old Python project that used Poetry and some other stuff that was just not working correctly on my computer. I did not want to toucj the CD/CI pipeline by switching fully to uv. But I created a special uv branch that moved my local setup to uv. Then went back up the tree to main and created a feature branch from there. Merged them together and worked out from that branch moving all the real changes to the feature branch. Now whenever I enter that project I have this uv branch that I can merge in with all the feature branches to work on them.
Imagine you have 3 branches: local-dev-tuneup, bugfix-a, feature-b
Remember in JJ you're always "in a commit", so the equivalent of the git working tree (i.e. unstaged changes in git) is just a new commit, often with no description set yet. (Because in JJ a commit also doesn't need a description/commit message immediately).
So in a mega-merge you can have a working tree that pulls from local-dev-tuneup, bugfix-a, and feature-b, and you can then squash or split changes out of it onto any of those source branches. Like you can avoid serializing those branches before you're ready to.
I've definitely faced the scenario in Git where I have a unmerged changes that I want to use while continuing work on a feature branch. I end up creating a PR for the branch of the first smaller features (e.g. local-dev-tuneup->master), then a second PR pointing at the first (feature-a -> local-dev-tuneup). It works but it's all a bit cumbersome, even more so if feature-a ends up needing to land before local-dev-tuneup. JJ has better tools for handling this.
Or potentially a team member has critical changes with a PR open and you want to start building on top of their changes now. Manageable in Git but you're locked in on a branch of their branch. Now add a second set of critical changes. Can be done in git but you'll be jumping through hoops to make it happen.
Of course you might say that all indicates a workflow/process problem, but my experience is this situations are common enough but not frequent.
(I haven't actually used megamerges myself yet but the article has me ready to try them out!)
That said, there is a HUGE need for more regulation around advertising, cut off limits and companies recognising users with a problem.
If you take a Bar for example, most barmen will notice you're already drunk as hell and cut you off, probably kick you out if not get you some water etc. It's actually a legal requirement to stop at some point in countries.
Casinos on the other hand, if you are down 99,000 out of your 100,000 with zero hands of games won, that casino is going to plow you with a good time until it has that last 1,000. It's disgusting.
I hate gambling , I've seen its effect on friends of mine and their families. But I would never stop an adult doing what they want, while knowing the risks.
reply