I too have run into this problem on a number of devices. The client's supported codec/media format detection logic appears to be extremely pessimistic. To the point that the mere existence of certain audio track formats and subtitles can trigger transcoding, even when said tracks/subtitles aren't actively used. The same files played via MPV on a file share, i.e. no transcoding possible, play without issue.
I've tried tweaking both the clients and server to be less pessimistic, i.e. see if the active media elements are supported, but even then it really fights it. I think the best approach would be rewrite the clients to adopt a (try || transcode) strategy rather than (guess || transcode), but that looked to be a major piece of work.
Likely referring to Android's Play Integrity/hardware attestation API (good explainer from GrapheneOS [1]) that is practically used to restrict what devices/brands/Android builds an app will allow itself to be run on.
How are the economics of this idea meant to be viable? The proposed business model is to park hundreds of millions to billion dollars of satellites in orbit, plus the costs to maintain and operate them, to meet the goal of selective area illumination and solar power. Ignoring the issue of cloud cover, which still seems to be an impediment. That's going to need to directly compete with terrestrial energy storage technology, e.g. batteries, and... general lighting. Both of which are well established, diversified and reliable market segments with vastly cheaper MWh costs compared to beaming a small amount of light down using a satellite.
This strikes me as another hand-waved scifi/fantasy inspired investment, where everyone is so caught up in proving they can achieve this (spoiler: this is obviously possible) that no one has stopped to ask does that achievement lead to a real benefit outside of VC wealth transference?
Daylight helps you just as much as your enemy. We've got plenty of cutting edge night vision and thermal imaging devices for humans and radar on vehicles. The Army's 160th helicopter regiment can fly nap of the earth on a moonless night. Satellite-based Synthetic Aperture Radar can pickup human sized objects during a pass and can switch to sub-centimeter resolution in finer modes. If anything, the military prefers fighting at night because of the advantage it holds.
I guess there's some niche applications but that's easily defeated with blackout curtains. Plus soldiers on a base are already pulling night shifts, making everyone on a "night shift". Still, they can only guarantee 100 lux (comparable to indoor lighting) for continuous periods with 50k+ satellites. That's a shit ton of infrastructure all tuned into one small operation.
Assuming the orbit is at 200km, these mirrors could only focus the image of the Sun on a 1.7km wide disk (that's (Sun diameter)/(Sun's distance)×(Earth distance)).
Moreover, the Sun's illuminance is about 1kW/m2 around Earth. 10000×60m2 satellite will thetefore intercept 600MW, so that's 260W/m2 on the focussed area. You're not going to burn anything with that.
Except if the reflectors are shaped for wide area illumination, then their focal distance is probably nowhere near the distance from the satellites to the earth’s surface. So I don’t think is any “single point” to be had.
Heck, I haven’t done the math or anything but I bet even if you did instead use parabolic reflectors that were tuned to focus at the earth’s surface, it would still be very difficult to keep them aimed at a specific point for long enough to achieve significant heating. I wouldn’t be surprised if it’s difficult to achieve an increase in heating that’s close to, say, the heating difference from standing outside at noon as opposed to 5PM. Which then doesn’t do much because you couldn’t effectively use a reflector at noon, anyway. You’d want a lens instead. Or some sort of complicated Newtonian telescope type contraption.
I don't think these things start out looking like a weapons. Wrong reflector shape? It could just be proving out other aspects. It could also be completely innocent too, but I don't think this is quite conspiracy level thinking.
> It could just be proving out other aspects. It could also be completely innocent too, but I don't think this is quite conspiracy level thinking.
This honestly strikes me as an innocent test of one random idea/technology. The whole "conspiracy level" thing (if it were to ever happen at all) would come later on, and most likely from entirely different people usin' the things discovered from experiments like this one in wholly unacceptable ways because they simply have too much power, money, and time, and not nearly enough good sense between their ears.
Sad though that as other folk have pointed out, if the technology were to work as expected, then it could also be used to help mitigate global warming by reflecting a specific amount of sunlight away from Earth, too. The sad part is that's likely not what such experiments will lead to initially. The "bad people" tend to be pretty quick to try to weaponize or monetize (or both) anything they take an interest in.
Such as? Military in the next 100 years will be drone / remote based, they have IR / night vision and soon to be fully automated. Sunlight can be handy for humans but for decades now the only ones that would benefit from it would be foot soldiers, and they're like the last resort (for western forces anyway).
The revenue potential is huge. Think of public events where people might want to illuminate the area as daylight for several hours. Galas, sports, concerts, parties, etc.. They will all pay top dollar and they have the funds. Could get sponsors, "Today's sunlight brought to you by NordVPN"
How huge is it on a continuous basis? Ii's low earth orbit, so only available for a few hours after sunset, AND requires a new satellite in position every 15 min. So for two hours extra illumination you need to support a couple DOZEN satellites, costs of build, launch, control, and maintenance. Even with 100% bookings —every night— it is dubious finances. Seems much more like a scheme to generate a money flow from meme-investors they can siphon off into their pockets then oops, it fails.
If this is somehow an actual problem, it is far more solvable with tethered blimps or drones, battery pack in a container on a truck, a spool of wire, and light banks as big as you want. AND that isn't subject to clouds (but would be subject to high winds, which would also be more likely to cancel/postpone the event than clouds).
Meanwhile, they go beyond the already massive disturbance of existing terrestrial lighting and overwhelmingly screw up the biologically critical light signals used by every plant, insect, animal, and human in the zone, and do it at multi-kilometer scale.
Edit: Even if the revenue potential is actually huge, it is no justification. For any intelligent person, the actual sponsorship message will be "Tonight's lighting brought to you by [Insert_Company_From_Which_I_Will_Never_Buy_Anything_Again]
This level of stupidity is beyond evil — the kind of lunacy to make a good argument that humans should not exist.
And a satellite isn't going to provide "hours" of extra light unless it's a very much higher orbit than current proposals. At 600 km altitude, you're talking 20-30 minutes even with an unbounded number of satellites (and 10-15 minutes when you've only got a few satellites). Same reason as sunset itself happens: Earth just gets in the way.
Opposed to holding the event during the earth's orientation towards the sun, aka daytime? Someone should tell the gala and event organizers about this idea of daytime.
I saw a presentation by one of the founders where he talked about several use cases where the benefit is just phenomenal.
They don't fool me for a second, however. The end goal of this is to build a weapon that can fry people/places on demand (but only the bad guys, of course).
orbital mirrors make very poor weapons because Conservation of Etendue means you fundamentally cannot concentrate very high unless your fill factor is very high (which would require millions of tons in orbit). Lasers are far more effective as weapons as a single aperture launched on a single rocket is sufficient to get high concentration. Microwaves also.
The military application would just be illumination.
Not every possible thing has real situations where it's better. There are legitimately terrible solutions to problems, that are dominated by better ones in every situation.
> Like....what licencing issues? After the game is "dead" and the parent company doesn't want to support it anymore, we could easily release the source code or even just the executables for the servers.
I can't speak to the parent's stance, but more generally this would be referring to IP licensing and patent encumbrance. I've worked on a number of large systems where non-trivial parts of the codebase were licensed from external parties with distribution restrictions in place. Even the executable versions would be problematic as the contracts go to great lengths to lock it down to strictly company XYZ may modify and use the IP, but nothing else regardless of the form or means of distribution.
Releasing said systems as-is would require either relicensing to allow distribution (very costly and potentially impossible if the vendor declines), or replacing that functionality with a cleanroom implementation. Which is both costly, time consuming and difficult. You may also run into further issues there if the contract forbids cloning functionality, or even worse: if there is patent encumbrance you have to go back to the relicensing option.
No problem at all. Just release your own source code. Leave out the licensed stuff. That's how id did it. If you have non-ridiculous development practices, knowing what's your IP and what is not is a basic requirement anyway.
The modder base will reimplement the licensed stuff, if needed.
What if your licensed component is non-trivial, e.g. provides critical features so that omission renders the service entirely non-functional? These laws would need to cater for that scenario, as skimming over that detail and allowing stripped releases would either mean:
1) companies get to release broken, incomplete source under the banner of commercial licensing restrictions.
2) truly upstanding companies (/s) will use this as a loophole to block the majority of their source as commercially licensed by stuffing it all under related companies and licensing it back to themselves. e.g. Company A selling game licenses majority of source (say, the entire server platform) from Company B -> Company B can't be compelled to release their engine because they aren't selling the game.
#1 would be an annoyance through to major challenge depending on the scale, #2 seems a more likely outcome for the major players as they can afford to play that sort of game and get away with it.
To be clear, I think this law should be implemented. However it would be pointless to pretend that licensing constraints won't add significant complexity, and many inventive pathways to highly evasive yet technically compliant outcomes.
I think most people are looking at existing games made under different constraints and concluding that it can't be done. But If the law passed, to me it's quite clear that it's just something that would have to be considered during development - like, we already have to get a sign-off from legal on using any open source libraries, and they usually say if it's fine for something that ships vs something that doesn't. If we knew beforehand that server binaries will eventually ship then that changes the answer from legal, and we either don't use it or try to licence it for that usecase.
Yes, this would force the nature of licensing to change. It does not apply retroactively, so the legal processes would naturally need to shift. Such licenses were used in the past, so there is no reason they cannot be considered again.
Unfortunately that's non-DAC copper cabling life it seems. They build them to work at the rated speed at the maximum rated distance (on the transceiver, not the spec) and none of them appear to link train to reduce the power output over shorter runs.
If you use a DAC they usually run cool, and optical is even cooler.
Could do with a difficulty setting that includes when you inherit someone else's log pile, someone who really enjoyed making every cut on a new and more inventive angle than the last.
Normally a wedge is used to split the wood, but it also doubles as a wedge to be wedged underneath just so you can get the log to stand up.
Also, Y sections (ycombinator mode?). 40 hits later and you might have a nice pile of woodchips, very rarely will it actually split in any clean way.
Vastly different target market and/or features there. Mercedes are chasing maximum power density, minimum weight for high performance deployments, with seemingly little concern for cost or supply chain.
Renault is going after the consumer market with these motors, where minimising cost and maximising availability is more important than pushing past 95% efficiency or cramming a 700kW power output in a motor that is small and light enough to fit inside of a wheel hub.
Looking at just the `grit` executable, 58 of the top 200 largest file->resulting code sources are from clap-rs' derive functionality i.e. it's the command-line parsing. The #1 largest is, surprisingly, merge_trees[1] which comes in at 183kiB final binary size. There isn't so much code in that file that it seems reasonable, so it's potentially one of the derives in use (Debug being a common culprit for bloat) that's blowing it out. After those outliers it starts to level out quickly.
Splitting it by crate: `grit` is 13.6MiB, `grit_lib` is 4.8MiB and then it's `std`, `rustls` and `regex_automata` that are the next largest. So as pure library you could hopefully shave off quite a bit of that 25MiB.
Nice, I haven't dug into this yet. If we can get this usable, it would be pretty cool to have a small lib or a series of much smaller, directed libs that can be used by simpler interfaces and you can just compose the parts you need.
The problem in isolation isn't new as such, but I think there's a combination of new factors to differentiate it:
1) the speed at which AI-generated codebases grow is far in excess of what human developers can achieve. What took years to accumulate in the past can be produced in a few days/weeks.
2) past large codebases that end up in a similar state would often see a mixture of developer talent. So while you might have a few developers who produce dross, there will also be a few who can pull it back together. You start to see threads of sanity appear, and from that the potential to refactor further, rather than the uniform spaghetti monster that's near unassailable from every direction that we're now getting from the pure-AI projects.
3) external perception differs. AI has been pitched, sadly by sales, influencers and shills rather than experts in the field, to business leaders as the solution to all development problems. When you present this issue to stakeholders you're then immediately put on the defensive, e.g. it's initially viewed as negativity for the sake of negativity. With past technical debt discussions, outside of a few key parties (too often the person responsible for overseeing said debt developing), I've found that it's relatively straight forward to explain technical debt, the need to refactor and maintain systems as a going concern. For the technically disinclined it's easy to draw parallels with building maintenance: you don't expect to build an office and then never spend another cent, it takes continued investment and maintenance to keep it safe, clean, functional and compliant. The difficulty again with the AI projects here I think comes back to the accelerated timeline, as you're inevitably going to be saying months after it's created that it probably needs to be burnt to the ground in lieu of the far greater task of refactoring it. As opposed to a legacy project that has been going for years or decades, where it's a far more palatable concept to take drastic action.
The AI pundits often seem to apply the logic that code output is directly proportional to revenue and/or profit, and as such it follows that an AI usage increase leads to more code which leads to more revenue.
I don't believe this aligns with the reality of any major company, unless your business is in the literal sense "selling code" your revenue and profit is tangential to the quantity of code you produce. Google is a good example of this: most of their revenue and profit comes from their ad network, which is disconnected from their development productivity and instead heavily reliant on network effects and time in market. If I was a new competitor with infinite AI funds to throw at whatever problem I choose, I can't simply capture their market by developing an exact copy of Google's ad platform. In the same way, Google can't substantially grow their ad network by coding "more" or "better", they still need more customers and consumers to interact with their network to see any increase in revenue.
So it doesn't directly follow that a productivity increase will inherently follow an AI usage increase.
Agreed. I think it’s more likely to expect that most of it is pure waste.
My impression is that most software development work is not profitable. Either the project is abandoned, or it fails, or it gets shipped but doesn’t generate positive ROI. But, like how venture capital works, the minority of projects that are successful make enough money to cover the rest.
Some portion of this is because demand for software projects in general is less than perfectly elastic. So more software does not automatically mean more software sales.
It also seems plausible that, in general, companies tend to fund the projects that are most likely to be profitable. They aren’t perfect at it, but I doubt they’re just rolling dice.
Which would imply that the new work companies can take on thanks to developer productivity gains will tend to be ones that are less likely to generate positive ROI.
meaning AI may only produce a net increase in waste, which only serves to erode profits.
Add to that that it’s been years now and we still don’t have an example of someone army-of-oneing a killer app or anything like that. It’s beginning to feel like another iteration of the amazing blockchain revolution that was always & forever just around the corner.
The unlocked economic activity won’t come from a Google competitor writing code faster. A lot of it will come from “boring” businesses who could benefit from custom software but haven’t had the means to create it themselves. In some cases they may not even know their problem can be solved by software, but some AI they are using for repetitive tasks will notice and offer to build an app for them.
I've tried tweaking both the clients and server to be less pessimistic, i.e. see if the active media elements are supported, but even then it really fights it. I think the best approach would be rewrite the clients to adopt a (try || transcode) strategy rather than (guess || transcode), but that looked to be a major piece of work.