Yeah, I expect that it might. Nope, I’m an engineer working on the engine side of things. I joined Unity because I believe in the work we’re doing, like my colleagues. The last couple of weeks have been a distraction, but my team is still pushing ahead and building the engine of tomorrow. Believe me, I’m personally just as frustrated with how things were communicated. I have a lot of faith in my team and the positive impact of the work we are doing. All I can say is that we’re continuing to build functionality and features which will enable developers to accomplish more and drive success. Decisions about how this technology is licensed isn’t something I have direct control over, but I hope that through our efforts we can help restore the trust which has been eroded. I’m still bullish on the future road map.

Context, I work for Unity, but this is my own understanding of things and doesn’t necessarily reflect the views of my employer nor should it be considered “official” positions of the company. We have folks where communication is their job. Mine is helping build a better engine. There’s been a lot of misinformation since the changes were announced and hopefully I can help straighten some of this out, but again if there are other questions, there are others who are better qualified to address that.

The limit for using Personal was 100k. That has been raised to 200k. For the original terms, and these new terms, it is the same; no per-seat price until you reach the threshold. Once you reach the threshold, then you have to upgrade to Professional or Enterprise, and then there is a per-seat charge for the editor. When you hit the revenue or instance thresholds, then there is an additional charge… But you will be doing very well at that point and the amount is insignificant for most developers at that scale. Compared with Unreal, it is still significantly less, even with the announced terms last week. Unity continues to try and make it possible to create highly portable games for multiple platforms, and devices, and to do so with terms that encourage anyone to become a creator and build your dream game. The last thing Unity wants to do is stifle innovation and creativity.

If you watch the Q&A, the reason for the change, so that it was “retroactive” was to apply these term changes to companies pulling in high revenue, think millions of dollars, and who were releasing what amounted to DLCs and Season types of updates but without doing anything except maybe changing assets. Some of these games are even repackaged and re-released as “new” games. In other cases they may sometimes radically change the game so that it might be more accurately described as a new game, but they continue to release using an unsupported version of the engine. If a developer did this every time they approached the threshold, they could technically have millions of users, all while skirting around the TOS. Do this on Personal, delist at 90k, and release a “new” game to perpetually circumvent the licensing fees. The change wasn’t intended to harm the good developers or studios who are trying to make high quality games, it was intended to go after the businesses releasing “Banana Slots 2022.1 (updated).” If that’s the content you release, I’m sorry, but I think your games are kind of scummy. Please stop. The app stores don’t need more of this sort of cash grab content.

If you are making great content and the terms would severally impact you, then Unity was intending to work with you to reach agreeable terms.

Under the new terms, the same applies. If you or your studio are greatly impacted by the new trerms, Unity doesn’t want to sink your business, they are trying to find a way to keep investing in the development of tools and services which will allow you to reach the greatest number of users and want to work with you to make that happen, as that works best for the creator and for Unity.

For those making games for charity which were told they were going to be impacted, that was bad communication and you inadvertently spoke to the wrong person who didn’t fully understand your request. Content made for charity was always intended to be treated with favorable terms. The specifics of those terms I’m not deeply familiar with, so I don’t know how that applies to per-seat licensing or the details of such a contract, but I know that Unity works hard to support humanitarian efforts and I’m sure if you were making content for charities, nothing has changed.

The bottom line is this. If you feel like the terms are going to make you insolvent, work with Unity to resolve that. Unity is a partner, not an overbearing entity. Unity wants you to be successful.

Moulin Rouge. Captures a lot of the cinematography you see in Snatch, and it’s a musical. Great story, great writing, and great performances curtain to curtain.

I like my Smart EV. From the outside, it is as long as most cars are wide, can U-turn as right as a Tesla Cyber truck, if not tighter, and can get me from A-B daily, charging overnight off a regular household outlet.

Seems like that should be a problem already. I have family that was in the music industry and collected royalties. They won a few Grammys, so the royalties were substantial. Their estate should not continue to receive royalties indefinitely. Hell, as much as I loved them, they shouldn’t be collecting indefinitely. They worked hard their entire life and because of that hard work, they deserved to live comfortably in retirement until they passed, but they weren’t owed anything they didn’t deserve. And as much as I love their kids, they’re family too, it isn’t as though they deserved any income for something their parent did decades earlier, before they had families of their own.

I think something like BTRFS might be a better solution as overlayfs seems to freeze the system image state. Something which is copy on write (COW) seems like it would be more resilient and still provide an RW file system. To do it right would probably be a combination of the two with the data partition BTRFS and the system image partition overlayfs.

This has happened several times to my Pi-Hole. Even with backups, trying to get my network back online still takes too long. I haven’t found a good solution for resilience yet.

I tried it on my Nexus 5 as well. It didn’t work well for my needs at that time, so I went back to putting Android on it.

What are a set of tools I can recommend to my employer, which increase productivity of office workers, and which provide greater value than a hybrid office policy?

The video cable does a similar trick with how it supports color. This is why S-Video was superior to composite video until component came along. S-Video split the intensity and color into two signals and then component split the color further into a blue difference and a red difference. If you only wanted black and white, you didn’t need to use the color signals and the image would degrade to a monochrome representation.

The composite video, with only one video signal wire, was similar to what was received over the antenna, with the broadcast signal separated from the carrier signal and the audio sub bands removed. It was the video signal with the color signal still combined. The progression from Antenna -> Composite -> S-Video -> Component -> DVI-I -> DVI-D -> HDMI -> Display Port has been an interesting one. The changes in the digital realm have been less about the image quality, the digital signal can either be read or not, and more about the bandwidth and how much data can be sent, aka resolution and framerate. Those first four transitions in particular had significant impact on the image quality.

They are different as you and I have both described, but when the sink device can support different streams, it has a significant advantage, because it automatically can support sinking frames from the broadcasting device and it removes the overhead of decompressing and then recompressing with practically assured data loss. It is yet another example of how patents, especially software patents, work against the original intent of the patent process.

I read what you said and completely missed it. It’s there, but pretty hidden. Might not even be known. I’m not sure that makes it bold.

This is why it works so well. It’s also one of the reasons I prefer vi over other text editors. It isn’t always the most logical which commands and keys do what, but I like the consistency.

I selected “was” simply because I don’t have enough understanding of the current situation to argue it from that standpoint.

In many ways, Chromecast is superior. Removing the rendering task from the tablet or phone, and letting the receiver manage that, it’s significantly better than making the mobile device decompress the source stream and then decompress it for a Miracast receiver. The only real advantage Miracast has in this is that it doesn’t need to receive firmware updates to keep it up to date with newer protocols. With Miracast being built in to TVs, and possibly implemented in an ASIC, it should be a universal fallback. With Android 4.2 it was a built in protocol to AOSP. What I didn’t know was that it was actually stripped back out with Android 6. I thought dropping support was specific to Google devices only.

What really needs to be implemented is a non-proprietary extension to Miracast which goes back to the early Chromecast days when it was based on the DIAL protocol. It’s incredible that we have to deal with so many proprietary standards from Airplay and Chromecast, and then also support the wifi alliance standard for Miracast.

Those glares from the others should resolve your confusion.

I think it’s closer to 75% (75.25% precisely). 55% because of the attack and 55% trying to figure out what the picture is. Stacking those stats, of those who weren’t confused at first, those 45% remaining were subjected to the effect of the attack. Only 25% remained unaffected.

But that wire has to end at a WiFi transmitter at some point, it won’t work purely over ethernet wire, for example.

Yeah, not sure about that since those devices in question, where I’ve used it, have some Wi-Fi somewhere. I just remembered that there has been something done to provide it over a wired connection, but the device would have been wired to an access point. My specific use case was an Xbox wired to an AP and casting wirelessly from my laptop. So there is a wireless hop in the mix.

Very few vendors have bothered to include it, mostly the Chinese low and mid-tier device manufacturers. But it is not widely supported since, I want to say, circa 2017.

It was standard in Android. The only time I had ran into a situation where I haven’t had it was Google Nexus 6+. I haven’t tried a lot of different OEMs, but OnePlus and Microsoft have (had) it for sure. Samsung I have used their Smart View service, but I thought it was Miracast with Samsung specific extensions. Meta Quest 2, I was surprised seems to only work with Chromecast. However that suggests that you may be right. Most of my devices have support, but not all do.

Miracast is plagued by latency problems, but it is still alive. Android itself still has support, it is the Nexus 6 that Google dropped support, to only support their Chromecast. Microsoft Xbox can be used as a Miracast receiver and there is support for Miracast built into Windows 10+, both as a receiver and transmitter. While Miracast was built upon Wi-Fi Direct, (Wi-Di, I believe), it has been extended to work over a wired network too. The biggest difference is that Miracast is transmitting the frames over the network, so that the device transmitting needs to render the content, whereas DIAL and Chromecast are sending steam URLs, authentication, and transport messages to the Chromecast, which then is the device actually rendering. Chromecast is better for mobile device batteries, but I loath the proprietary nature of it.

Might be thinking about DLMA? That wasn’t just a Samsung thing but predates this.

The limit was 260. The OS and the filesystem support more. You have to enable a registry key and apps need to have a manifest which says they understand file paths longer than 260 characters. So while it hasn’t been a limitation for awhile, as long as apps were coded to support lesser path lengths it will continue to be a problem. There needs to be an conversion mechanism like Windows 95 had so that apps could continue to use short file names. Internally the app could use short path names while the rest of the OS was no longer held back.