HN user
what you describe reminds me pretty much of a binary blob that is loaded into a machine or software.
additionally modifying data in binary form was a longtime practice last time I looked, but I might not remember correctly.
Free Software is not the same as expropriation. It's perhaps more the social-democratic smoke mirror kind of thing than lifting the dependency.
Regardless of free software, capitalists control the means of production and obtain profits by exploiting the surplus labor time of workers.
Free software may make it more obvious though, at least for some.
A better way to differentiate might be to say how many watts have been used for an answer.
Humans reason
Are you sure? They reason in a way to match others predictions, right? The problem of humans transporting information from one individual to another remains. All reason can effectively only be prediction, as it requires two persons at minimum. And there is a lot of noise to filter.
LLM predict.
Well, there is a human that needs to reason with what the LLM has predicted. So from that perspective, it should suffice already for the moment.
Messaging is very simple, but made hard so that the benefit is not on your side. Business opportunities, yay!
Isn't using GPU and hardware acceleration considered experimental in browsers and the safe default to disable such features for day-to-day use?
Not saying to make this achievement smaller than it is, quite the opposite, it's important there is more such research.
We are the collective voice of the game development industry—developers, game designers, artists, and business minds. Passionate about our craft, we've invested years in shaping an industry that touches the lives of millions worldwide.
Clearly the "our craft" is "business minds" and the problem with increased Unity fees is that their add business is at risk despite all these "business minds" invested years to shape their model.
What an excellent shit-show.
While I'm able to understand your argument, IMHO the MIT license is not displaying that well. Community is plural, and fork with MIT could be like Windows: Closed source. End of the (fork) line.
Given the project itself is still strong, this might not be a problem, but then I see no reason why it has chosen it in the first place if not for that specific option.
see exec builtin in the bash shell. otherwise man execvp etc.
Everything was reverted with 48 hours, your arguments might all apply theoretically but given scope, size, practice and handling, I wonder - apart from the theory - what your opinion is how they practically apply for this case.
Isn't community plural? Perhaps they meant their own community but didn't say specifically which one?
Are you commenting about April of 2021 and do you mean the University of Minnesota?
- https://news.ycombinator.com/item?id=26887670
The only question that remains then perhaps is, whether this statement was from the inside or the outside.
No wonder, the tab bar is open only. Managing multiple tabs is a no-go with it, or lets say, a wonderful journey into Firefox UI.
Thanks, that better helped me to understand your comment. Additionally I was not aware if that was with pull-requests or more with regular code-reviews as part of the development process. That was an additional insight, thanks for sharing.
Nevertheless, things can be different, e.g. if CI passes, it merges already, no need to have a request for merge, which are often a blocker to keep a steady development flow. Naturally, this benefits from tests that are already run during development, if not driving the development.
And I didn't read you're against testing nor aligning white space and comments at all, more the localization. Actually the points you raise are looking important to me, because if alignment comes in late, this can cause a lot of erosion, which can hinder any review if not even provoke merge conflicts which are stopping the process quite early and require re-iteration.
Your approach should also work towards non-release blocking code reviews, a property I personally like, as I've seen teams struggle with code reviews, becoming more and more of a burden, even after practicing it has found its way. But that is only a subjective comment of mine, every project is different, which makes it an interesting topic for me.
Your relatively short comment caught my interest and I'd like to learn more about your thoughts.
As, IMHO it depends (as so often). Code review is commonly the place that puts the current style under test (hence automated otherwise you don't have the results during review) and under review.
E.g. Code review finds out if a code-style is missing, incomplete or even outright wrong.
If that approach is taken, passing tests and code-style must be in there, otherwise it is not useful to argue about violations. From my understanding I would therefore see those results be available during review.
It may also be that there is code-style for automated test-code, and that code part of the review. Without taken this into context of the code-review, I miss a bit the boundary of your comment.
Could you elaborate a bit where you draw the line and why? E.g. I can imagine there is a benefit to keep a distinct context for code-reviews so that they are still practically feasible and those parts that need further adoption are put into a different phase, like steps before (preparation of the current increment) or after (preparation of next increments) the code-review itself.
- It does not ask for consent
- It does not allow a reasonable decision as it does not show the data before it sends it
Yeah, why not? But often GNU Make is fine for incremental builds.
local like in tree.
But they are clever, you can have the runner local.
(They start to ruin that, but lets say, the idea is still visible.)
IMHO this is also a good remark in context of those container images that most of all have /bin/sh. Technically not all, but many distro based containers.
so if someone plans to extend the script so that it injects it iself into the container or what not.
Those of the workforce, that is a pretty typical situation. Timestamps of activity etc. .
oh snap, too late to edit ... you are absolutely right.
This is a great baseline, but it is often easier said than done.
For example, those repositories contain a lot of privately identifiable information, it is not that easy to get such a baseline ready for that _"should be treated as if they could be exposed to the world at any time any way."_
Depending on jurisdiction this can affect sensitive information that requires much stronger controls in place when you (rightfully!) expect the repository to become public despite it is a private one.
A cooperation is never reputable. It is easier to reason with a dog than with a cooperation.
However, me thinks this relates to the times before Github became an offering by Microsoft. But the deal was just too hard to miss, getting this massive army of minion coders who all pray to the octocat and now do the Balmers dance.
Oh so much fun, now it turns out, that all feed the new AI overlords.
What for? I've seen this happening and if there would not have been a review, it would have stayed there unnoticed.
/edit:
Also what someone considers a secret and then not, is often not well defined. If management has no clue what this is about, it is often better to only commit and push on direct and simple work order, because these need to be well understood and you have the paper trail (as that author also suggests blameful retrospectives - IMHO hilarious).
Or do we have forgotten about the basic rules sending data over the interwebs to other people computers?
it depends on the invocation, and by default it checks for tty or not. the aliasing often does not touch this.
example alias:
$ alias ls
ls='ls --color=tty'
("tty" and "if-tty" are the same as "auto")
Personally I didn't wanted to invite to more guesses, however if this was because of any of those reasons, it does not look to me there was anyone in a hurry:
txti @txties 15. Juni 2020: "I realize txti is broken at the moment, and I'm going to try to fix it. Truth is, I haven't really been doing web development for a few years and projects like txti have unfortunately taken a back seat to life."
In concrete not, for the past:
txti @txties 28. März 2020: "Txti is currently down because some folks can’t follow rules and have created phishing or other malicious pages."
<https://twitter.com/txties/status/1243879222206246912>
The "rules" may relate to txti Terms of Service found <http://txti.es/terms>
IMHO much speculation for the little explanation provided. Do you have more information? Was it offered to the community to take over for those who may want or similar?
Following this since some days, still think its not a classic injection, it's just prompting. You either open the "prompting" interface or you don't.
If it's by design, then so be it. You can't prevent SQL injection if it's by design.
The "prompting" interface is perhaps too new that it allows parametrization?
And what triggers some AI engineer is likely to handle that with AI again, right?! Go, Inspector Gadget, Go!
Anyway, what this also reminds me then is, what is if an injection has already manifested within a model? We can't say, right?
So how do you detect a prompt injection that is exploiting a model manifested injection? Is that even possible with this Dual LLM? As in the slightest chance, not only the limited chance Mr. Willson gives it for the non-reflective prompt injection.