It doesn’t get piano keyboards right, but it’s the first image generator I’ve tried that sometimes get “someone playing accordion” mostly right.
When I ask for a man playing accordion, it’s usually a somewhat flawed piano accordion, but If I ask for a woman playing accordion, it’s usually a button accordion. I’ve also seen a few that are half-button, half-piano monstrosities.
Also, if I ask for “someone playing accordion”, it’s always a woman.
Periodic data is always hard for generative image systems - particularly if that "cycle" window is relatively large (as would be the case for octaves of a piano).
I can see this being useful for the same reason that it's useful that non-async functions in JavaScript can't be interrupted - it's as if you held a lock for the entire function call.
Between any two event handlers, anything could change. Similarly for await calls in JavaScript. And to get true parallelism, you need to start a separate worker. Concurrency issues can still happen, but not in low-level operations that don't do I/O.
I don't see anything wrong with mutating a local variable in cases when it's purely a local effect. It's sometimes cleaner, since you can't accidentally refer to an obsolete version of a variable after mutating it.
the _role_ of radiologists isn’t going away, but as with software engineers, better tools means there are fewer needed to serve the same patient population. So it’s highly likely that there is going to be displacement within that industry as well.
Put YouTube's website in a slightly-modified web view.
There currently is no YouTube app for visionOS. If you want to watch YouTube you have to open a web browser with all the restrictions and incompatibilities Apple does to the web. Juno makes that mildly more convenient.
You can imagine all sorts of things, and then something else might happen. You can’t rely on “proof by imagination” or “proof by lack of imagination.”
We shouldn’t be highly confident in any claims about where AI will be in three years, because it depends on how successful the research is. Figuring out how to apply the technology to create successful products takes time, too.
No moral qualms here. There are large pieces of it that are useful without VS Code (for example, the Monaco editor and the language server protocol). Not to mention al the use people get out of it for free. It seems like the good well outweighs the bad.
Oh, I definitely agree. While I don't use the editor (mainly because I prefer full IDEs and not glorified text editors personally) I agree that holistically, the existence of VSC is a net positive to the programming community. My argument comes from a moral perspective - even though the good outweighs the bad, the bad parts are really scummy and need more awareness.
Like, my perspective is not utilitarian, it comes from a deontological point of view. I see people and companies get regularly flamed (or even harassed/intimidated) for much smaller things such as the crime of creating their non-OSI-compliant licenses and various related things. In contrast to that, the VS Code ecosystem is much more proprietary, grants much less practical freedoms and operates from a way less clean moral background than any of these projects. Yet, many people are willing to excuse this because Microsoft has figured out a way to implement vendor lock-in without breaching any of the four freedoms in techicality. To me, this is way worse than someone saying "no we won't let you use our software for anything"...
> crime of creating their non-OSI-compliant licenses
Just don't call it "Open Source" and you won't get nearly as many complaints.
The big problem arises when somebody tries to leech off of the goodwill built up by Open Source communities and give their Source Available proprietary offering some FOSS-juice. (Most often VC-backed companies who have failed to understand that "Open Source is not a business model").
Well, this thread is getting off-topic real fast but okay, I'll reply :)
This argument would make sense from a strictly logical perspective if these were all the facts but the problem is that the expression "open source" wayyyy predates the OSI. It's been used in the 80s and the 90s on Usenet and in various places, and it simply meant software which was distributed in source code form. (as opposed to binary form) These pieces of software didn't even have a license file attached to them which was implicitly understood as public domain, or "do whatever the fuck you want to do with it".
The OSI simply appropriated the term to a narrower, stricter meaning which grants certain freedoms to the user and takes certain freedoms away from the creator. (Such as the freedom to change your mind in licensing! You can't practically change your mind since these are all non-revocable grants)
Furthermore, I don't really agree with the "leeching off the goodwill of OSS" framing. From a practical perspective as a user, having the source code available is way closer to OSI-licensed software than proprietary, closed-source software. You can view the code of the program, you can usually share your modifications with others (which is technically disallowed but the developers are very unlikely to care as long as you don't resell it), you can fix bugs in it, you can change functionality you don't like.
A less-commonly talked about side effect is that if the source is available, the developers are less incentivised to provide user-hostile features, simply because they know that the users can patch it out relatively easily. There's many cases of rugpulls and forced functionality changes in software nowadays and almost all of it is possible because the user can't simply change the code to change the unwanted behaviour but must put up with it instead.
Naturally, this is a huge advantage compared to closed-source software. And if a company is willing to share its source code with its users, this should be lauded and encouraged! Obviously, the developers want some benefit from sharing the code, and one of the huge benefits is goodwill by customers. If the developers are not incentivised - but more commonly, harassed and mocked - to share their source but disallow competitors to steal it, in most cases, they will simply not share the code at all, leaving you, as a user, with way less freedom in practical terms.
Both you and the company can't really do anything with paper freedoms - you can't really use paper freedoms and the company can't survive if their licensing permits others to profit off their work while discouraging them of doing so. In this view, having more practical freedoms should be encouraged because it helps both the user in having more usable and more modifiable software, and helps the developers not to go bankrupt when Amazon decides to commoditise their offering or something.
EDIT: I conflated "developer" with "company" when writing this post. My apologies. Of course, everything above also applies to natural people who develop software too, not just corporations. I made this mistake because of the subject matter (Microsoft), sorry.
I don't believe the term "open source" was used much before a certain meeting in 1998 [1] when it was suggested as an alternative to "free software." Some people say it predates that meeting, but I haven't seen clear evidence. Do you have examples where it was used?
On the other hand, people were using licenses that are now called "open source" licenses well before that, so the practice certainly precedes the term. Also, the OSI definitions were derived from the Debian Free Software guidelines.
This applies to the situation where the users are programmers. And I am a programmer. But I have never and probably never will modify any open-source applications I may be using. Too much work. Some library-code perhaps but not a full application (like VSCode).
Too easy to cause more errors rather than fixing them, creating a dependency to my own modifications. When it becomes time to upgrade to the next version of such OS software I will need to merge my modifications to the official app or library, and there is no guarantee that my modification would be compatible with the latest version of the said software. If it is not compatible that means either more work for me, or that I can't upgrade.
You specific having the time/resources is not the point. The point is that for users with the resources, they have the freedom to do this (either themselves or by hiring someone).
"I don't have the resources to exercise my freedoms" might be a problem for you, but it's not a problem caused by the freedom or the mechanic granting it.
Right, freedoms are great. But my point is such a freedom is not very valuable to anybody else than programmers, or rich people and companies who can afford to hire them.
And even for programmers like me it is not very valuable, especially if we're talking about sw-applications like VSC as opposed to library code.
The nice thing about society is that it allows people to come together and pool their resources, in order to achieve an expensive thing that no individual might be able to reasonably afford.
I get that nice things that you want are sometimes expensive, but that's just life, isn't it? The world doesn't owe you a cheap-and-easy-to-hack-on piece of software.
Yes, there were layoffs. But "core maintainers" is not a term they use, and kind of fuzzy since people come and go; some early team members left well before then. People didn't all leave (or get laid off) at the same time, and they never laid off the entire team as far as I know.
It would be cool if you could apply even the most basic reading comprehension here where it says there was zero change in team size and stop spreading nonsense.
Here’s the top comment from the Reddit post that was linked
> Hey folks! Kevin, product manager on Flutter and Dart here.
> The layoffs were decided AT LEAST a couple of layers above our team and affected a LOT of teams. (I think I can say that). Lots of good folks got bad news and lots of great projects lost people. Flutter and Dart were not affected any more or less that others. It was a tough day...tough week.
Web.dart is basically designed to give you the equivalent of any of the browser based APIs you would find on MDN essentially unchanged so things like document.querySelectorAll and things like that would just work as though you were using JavaScript (and you technically are in the background) but without otherwise needing to ever leave Dart.
That’s not actually correct I don’t know where you got that from. This is from this year and was built on top of a wider rewrite of their JS interop using new language features to make it essentially a zero cost abstraction.
Dart has had browser support and DOM APIs before but never had the same APIs you have in the web platform before.
When I ask for a man playing accordion, it’s usually a somewhat flawed piano accordion, but If I ask for a woman playing accordion, it’s usually a button accordion. I’ve also seen a few that are half-button, half-piano monstrosities.
Also, if I ask for “someone playing accordion”, it’s always a woman.
reply