Typically the purpose of policies like this is to shift liability for copyright infringement, rather than to prevent it outright. If someone submits some LLM-generated code anyway and then later there is a successful accusation of copyright infringement related to that code, I expect the GCC project would attempt to assert that they had a clear policy against such contributions and that the submitter is the one fully liable for the copyright infringement. The GCC project would presumably still need to stop distributing the relevant code, but if this allows the project and its maintainers to avoid liability then that's still a win. Whether such a claim would actually be successful in court of course still remains to be seen, since none of this has been tested yet. But from a risk management perspective, I'd certainly prefer to have this policy in place than not in order to have a stronger defense if a legal claim does eventually arise.

I think that individual charging infrastructure can only take us so far here. At some point we need to make the jump to having traction power broadly available, similar to how we have grown to expect parking to be broadly available so each dwelling doesn't need to include its own car storage facilities.

The current commonly-deployed charging tech is a little too simplistic for this: it's literally just a funny-shaped normal electrical plug with some passive signalling.

With some extensions to that system, it could be possible for a chargeable device such as car to be associated with a power company account in similar vein to how your house has a power company account, and then the power company could provide charging stations anywhere they have power distribution infrastructure (that is, most places) where anyone with an account can plug in and have the power they consume billed back to their account. For example, there is already tech available for using existing power lines as a carrier for data, which could allow account negotiation to be overlayed on the existing conductors in the SAE J1772 standard, so that physical compatibility with existing charging infrastructure is preserved.

I'm not naive to some very real concerns about an approach like that. For example, it gives the power company access to some data about your movements, if you are routinely plugging in your car to charge everywhere you go. That concern already somewhat applies to the various competing public charging companies, but at least there are enough of those that in principle your data ends up distributed across them all. This is not a trivial concern by any means, though existing precedent of cellular device usage seems to suggest that the average citizen isn't super concerned about it, and there are enough average citizens to make a significant dent in the use of in-vehicle fossil fuel burning.

"Losing focus" means trying to do too many things and doing a poor job of each of them as a result. Users probably won't jump ship immediately, but if resources are diverted away from the parts of Steam that users love in favor of parts of Steam that users don't care about it could hurt in the long run. Perhaps Valve has become a big enough company to pull this off now, but it's always a difficult compromise between "do one thing and do it well" and "don't put all of your eggs in one basket".

Conspiracy theories aside, I believe the problem is that Mobile Safari does JIT compilation of JavaScript, but since third-party apps are forbidden to do runtime code generation, and the WebKit widget runs in-process of the app that embedded it, third-party apps end up using the older, pre-JIT engine.

Option 4: - Focus on a speciflc use-case and let others focus on other use cases, rather than trying to make one product that is a jack of all trades and a master of none. There's no rule that says all problems must be solved with one piece of software.

I really don't see the problem with plugging in my car when I park it.

The last part of your comment gets to the part that amuses me most about the tech scene dynamic in San Francisco: most of the startups and other tech companies (including mine) are in SoMa, but the people who work there almost all live somewhere else. Meanwhile, the houses in SoMa are occupied largely by people who use Caltrain to get to the peninsula to work. I ilve in (or at least near) Cole Valley and commute to SoMa on a bike every day. 20-30min each way. However, I used to take the bus (6 or N) and I can confirm that it's far from being entirely poor people: the neighborhoods along these routes are very popular with professionals of all kinds and they fill up all of the available buses from 8:00 til 9:00 every day. (It does indeed take about 45 minutes to commute by bus from here, but as others have said it's nice to read a book on the way to work rather than having to drive... that's the one thing I miss now that I ride a bike every day.)

Several groups have tried and failed. The main problem is that Facebook owns the ecosystem today, and it's incredibly difficult to compete with that. Facebook has no incentive to inter-operate with anyone else, and they shut down any third-party integrator that they deem to be a competitor.

I was once optimistic that "the rest of the web" could band together and create a decentralized system more interesting than Facebook, but Facebook has done such a good job of creating a hub-and-spoke model where Facebook is the hub and everyone else is the spoke that it's really hard to pivot from there to a truly-decentralized social network.

And the best thing is we already have both of these systems, and individuals can use whatever is appropriate for a given situation. The armed forces are a good example of where it is more important to know exactly what time something will happen than to know whether local people will be sleeping at that time.

The concept of timezones is a compromise between each longitude having its own time-of-day origin and all longitudes sharing the same which attempts to keep the advantages of the former (easy to determine approximately what phase of the day it is at any longitude) while avoiding constant clock adjustments as one moves between longitudes. I think I'd agree with the grandparent that the idea of timezones makes sense, but the implementation of it based on arbitrary administrative boundaries (countries, states) rather than on actual longitude increments is what adds the complexity for software, since the only way to work with administrative boundaries is to maintain a database of the boundaries and each of their special cases.

A large reason for that is that watching shows on broadcast TV is pretty damned inconvenient.

I discover every day new shows on Netflix that aired years ago but I wasn't able to watch either because I wasn't in the right country (wasn't in the US) or because I had something better to do when they aired.

However, if these things had been available for on-demand streaming from the outset I'm quite likely to have watched them, just as I currently watch new TV shows on-demand through Amazon VOD or Hulu.

You made an error in your third line:

.5 * 10 = 5
5 - .5 = 4.5 = 9 * .5
4.5 / 9 = 0.5
0.5 = 0.5. QED.

The original nook gets "free" 3G because the device (as shipped) is locked down so the only thing you can do with that 3G is buy books from Barnes and Noble and download them. The cost is eaten by B&N as part of the book purchase costs. Note that in particular the included web browser application only works when a wifi network is available.

Nook color is unlikely to get this functionality unless they can find a way to allow third-party apps on the phone without allowing them to use the subsidized 3G.

Given that "wine is not an emulator" but rather a library that mimics the Windows API and a loader that understands the Windows executable format, the code that is running is native code for your architecture and can potentially do anything a native application can assuming it's been written with that in mind. So you should expect a Windows application running under Wine to be able to do anything a native application could do running under the same user account.

There is one aspect of running under Wine that leaves you in a better situation than running on Windows XP: on Wine, the entire Windows filesystem lives under your home directory as far as the native OS is concerned, so you never end up running things as Administrator (or root) to get them to run, which means if someone does make a rogue Windows app that detects when it's running under Wine and tries to do something mean it'll be constrained by the access rights of your user account in all cases.

I think the crux of the issue here is that Apple is the party distributing the app via its app store, and as a distributor it is bound by the licence of the software. In this case the licence is the GPL which requires that all binary distributions be accompanied either with source code or an offer of source code. Therefore to be in compliance Apple must at the very least make available the source code of the application by some means. Other requirements in the GPL may apply here too.