sipos

Unless you can describe the bad behaviour in question, it just looks like an attempt to make more proprietary software for personal gain.

The FAQ does not answer the patent comment's good questions.

Why have you chosen a name so similar to Creative Commons, when you seem to prefer the term Source Available from a descriptive point of view?

Frankly, it just sounds like an attempt to pass off software licensed under this abhorrent license term as Creative Commons.

Can you elaborate on what is wrong with Cloud SQL? I have next to no experience with it GCP Cloud SQL, but use AWS RDS a lot.

TBH, I think we just need much more efficient software. This is something we can do, and used to do more. It is insane how inefficient many things we write today are compared to how they could be. I'd love it if efficient code was a reasonable goal again, but at the moment, it just isn't worth the time using more efficient technologies and doing optimisation because it usually isn't really necessary. I've spent time optimizing code where it was really necessary, but it so rarely is that I've only once had the opportunity to spend as much time as I'd like to on this.

I can't see my company (a small business with a number of small apps, with engineering and marketing people who it'd be great if they could just use something like this to build some things themselves) ever using something like this that is both closed source and somewhat prone to lock in by the nature of how it works.

While charging for use might seem like a good business model, I think an awful lot of potential customers will just never use it because of it. You may be able to find a model where you charge for the front-end page designer or something, but open source everything needed to run the site so that being locked in to a product you have to pay for and can't modify is less of a concern.

It is annoying that they cannot be more committed to open hardware. (I'm not saying they should be).

I appreciate that they probably can't commit to it at this stage, but the fact that their laptops are not does not inspire confidence that the noises they make about trying will come to fruition.

The page says yes, it is included in the list of sensors.

Whether they can deliver what they promise (I imagine GPS will not be the stumbling block here) is not certain of course, so I can't say "Yes - it will have GPS" with certainty.

I think your comment downplays the importance of Stallman's work. Just because the vast majority of people do not use what he advocates, it doesn't mean he isn't having a significant impact on what they do use, indirectly. I think this is one example of a change that will affect people that happened probably in part because of people valuing rights that Stallman champions. It may not be him that directly influenced Apple, but he is a big part of influencing the bulk of opinion that did, so he has indirectly. It is not a case of one or the other.

It is like high art. Lots of people rarely look at modern art, but it doesn't mean it doesn't influence the design and pop-art they do see regularly, indirectly.

You are wrong to present behaving like Stallman and what Apple is doing as things that are competing alternatives, with things being in one camp or the other. Stallman's work influences the mainstream, so mainstream, less extreme, changes and what he does are not unconnected.

I think this is true to some extent - they do suit many users more than more flexible, but as a result more complicated, Android - but the iOS ecosystem is more restrictive than it needs to be, and more restrictive than is ideal, for many more than 1% of users.

Personally, I think more than 50% of users would benefit for more flexibility than iOS offers, even at the cost of less ease of use. I don't think it has to cost that much ease of use though. I think the ideal for most people is somewhere in between Android and iOS, but probably closer to Android. Android is not that hard to use. It is also not impossible to have a highly curated app store like Apple's, and allow apps from other sources at the same time of people want to install them. Ideally we'd have more diversity in OS implementations I think, based on one or a small number of actual OSs. Android based OSs that are more heavily modified to be easier to use etc. This would be easier I think if phones were more like PCs in that you could install your own OS and get the drivers for your hardware. I think Android is somewhat moving in that direction so there is hope for that in future.

I had a reasonable idea of what was needed, and a roadmap for what order to tackle things in, when I was working on this (briefly) before. I didn't work on it for long and stopped working on this because I changed jobs and had less time for non-work projects, and personal circumstances got in the way too so, I switched to focusing on smaller projects. This was several years ago, before HAMMER2 and, I haven't actually followed developments since that closely (I haven't been looking at the code really) so, I expect some of my conclusions are no longer valid and I need to revisit this. I have been interested in taking this up again for a few months but, hadn't actually decided to start again until a few weeks ago when someone else I know expressed interest too.

What utilities you need and, what you do in userspace, depends on what the goal of the port is somewhat I think. Also, what goes in user-space depends on what you are porting to (FUSE or what OS). My goal was (and is again now) to have first class support on Linux, i.e. you should eventually be able to do everything you can on Dragonfly with HAMMER on Linux, with as good performance as possible. Initially, performance takes a back seat to feature support (unless it were to be so bad that it made features unusable) but, good performance is an important end goal of mine. I think for my goals, an in-kernel driver and user space utilities based on the Dragonfly ones but, with some substantial differences in code, make sense.

There is a FUSE port of HAMMER that lets you read, without history I think. I don't think this is maintained anymore but, it had very different goals to mine and, a port with different goals to my own, might want to pickup this/start a new FUSE port. In particular, if you don't care about supporting every feature, you want to get things that you do plan to support working more quickly, you don't care about performance in the long-run and/or, you want to target other platforms than Linux as well/instead, FUSE might make more sense. I think there are reasons to work on a FUSE port as well as a specific port to Linux (and other OSs), they have slightly different goals and trade-offs.

To be honest, I'm not sure exactly what you want to know here so, if I haven't addressed it, please do ask (but, it is possibly the case that what I know is too out of date to be interesting).

If you're interested in working on this together (there are a few people I know already who have expressed interest in working on this, all based in London so far), hearing more about progress in the near future or, if you are planning your own Linux port or port to another OS, I'd be interested to hear. Let me know if you'd like me to provide contact details for non-public messages (there's no email on my profile right now). I am not planning to make anything I do public until at least we have read support, with no history, working and at least somewhat tested but, I'm not set in stone about that particularly. I don't see any reason to use our port over the existing FUSE one until after then either.

This is certainly the easiest way to get a working implementation, yes. There is an existing (but I don't think maintained) FUSE port of HAMMER and it would not be a huge amount of work to have HAMMER2 FUSE support I don't think. I am interested in a kernel port of HAMMER/HAMMER2 because I think this is likely to give the best performance in the long run.

There are plenty of reasons to want to/have to use Linux. There is clearly space in the world for more than one kernel. That said, Dragonfly deserves more use.

It will definitely happen.

I started an improved port of HAMMER to Linux (I don't like the current FUSE one and started building an in-kernel version from scratch) but, stopped working on it before I got it working or published it. I am planning to start working on it again with someone else. I wouldn't be surprised if someone else beats us to it though.

Visually, no - it should look the same. For comparison of the code, it will be interesting, even if it doesn't necessarily show everything you can do with Vulkan and DirectX (which has some similar low-level features in recent/latest? version).

The Vulkan version will really add a lot I think. I would guess most people are most interested in an OpenGL to Vulkan comparison. Similarly (possibly more interesting to people, I don't know?) the DirectX version.

Nice comparison.

It isn't anywhere near the worst thing the UK has done (in this case for the US so, I think they share a bit of the blame). The key issue here is that it is ongoing - the UK still isn't allowing them back or properly compensating them. The UK government should recognise that what it did was wrong, establish that the land belongs to the Chagossians and, broker an agreement where the US tries to try to buy the land needed for the base from them. There will be a price that the US government is willing to pay to keep the base there, that the Chagossians will accept, I suspect. If there is not, the base should have to be moved over a period of five years. An alternative might be the construction of an artificial island nearby. It is also possible that the value to the Chagossians, and the cost of building an artificial island, are both greater than the value to the US of having the base, in which case they should just abandon it. This is the only fair solution IMHO.

This. This is the worst design flaw I am aware of in AWS. It makes no sense that Amazon's two totally different businesses, use the same account.

Mobile phone authenticator apps are not that great anyway. They rely on the security of a phone that is connected to the net to keep the keys secure. If someone can get code running on the phone and exploit a privilege escalation vulnerability to get root, they can read the keys. A hardware token like a Yubikey or similar is probably more secure.

Another problem with the Google authenticator, at least for Google accounts, is that you have to add a phone number to your account to use it I think and, they then allow access by SMS, which is not so hard to circumvent.

That if you lose access to all of the 2FA methods you have available, you should just lose access to your account and there be no way to recover it.

If there is a way to recover it, that has to be secured too and, there are only a limited number of ways you can do that (and the more that are enabled, the harder it is to secure). Most services with 2FA offer a set of one-time codes that you can write down and store securely at multiple locations (safes in different places, safe deposit box etc). It is not that hard to avoid losing access if you care. If you don't care enough about the account to do this, just accept losing access, cancel the card payment authorisation and, lose it.

Companies should not grant access to accounts with 2FA by letting you call support unless they at least take proper steps to ensure that you are the account owner, which is pretty impractical in most cases (it is either too costly to be worth it or, too hard to do well enough). Demonstrating that you are the account owner to recover it if you have lost 2FA access should at least require a visit, in person, with photo ID being checked with the relevant authorities (for example the passport service examining your passport to check it is not a forgery) and, multiple people who can attest that you are in fact the person in the photo, to recover an account, for which they would presumably have to charge hundreds of dollars. It seems easier to just not offer recovery in most cases.

One thing missing is that most users cannot be trusted not to lose their key and still want a way to recover it.

LastPass, for example, provides ways to do that, for example by using devices they have used recently but, I don't think it is particularly secure.

Spreading the key to multiple devices so that you have a copy of it on another device helps obviously, as does allowing an unencrypted backup of the key, for example on a USB key you store securely.

The other problem is paying for it. To deliver messages quickly to all devices, even when they are offline, the messages obviously have to be stored serverside, which takes up space and bandwidth.

A federated system, where a user is on a particular server and, you deliver messages to that server, which delivers to their devices (possibly when they come back online) makes managing paying for it easier - you can get other people to host it or, people who can can host it themselves. It also removes the single central point of failure.

It does make people less likely to want to buy the chip with the DRM though.

The Rayleigh criterion defines the theoretical limit of anything resolvable looking through and aperture, your pupil for example, irrespective of how good your retina is. For a pupil diameter of 0.5cm and 500nm light (green), this is 1.22e-4 radians. 1 arcsecond is about 5e-6 radians, or about 25 times smaller than it is theoretically possible to resolve with a pupil that size and that wavelength of light. There is roughly a factor of two for the wavelength and the pupil size each possibly but, it is physically impossible for you to be able to resolve this small.

The theoretical upper limit of the resolving power of the human eye will be given by the Rayleigh criterion. For a pupil diameter of 5mm and a wavelength of 500nm (green light) we can theoretically resolve about 1.22e-4 radians. 1 arcsecond is about 5e-6 radians, i.e. 25 times smaller than we could theoretically resolve without a magic retina.

1 arcminute is a more realistic size for what people can reliably resolve I think. I guess we need significantly better than that to avoid a subjective feeling it is blurry but, that is about what we can actually reliably tell the difference between I think. We cannot tell the difference below 25 arcseconds or so though, it is not possible without larger pupils.

Thanks. Making the add-in open source makes sense from a business perspective, lets people inspect the code they are running on their machine.

What is the licensing model? Completely open source, free for small time use with license fees for heavier use, charge for all commercial use, undecided yet?

I ask out of interest rather than because I am thinking of licensing it. I can see it will be highly useful though to those that need it.

This seems like a better approach than Apple's WebGPU in that it is more realistic (depends on using a usable subset of the three APIs that is reasonably common) and, not started by the same company that is the biggest obstacle to cross-platform graphics APIs in the first place.

It seems unfortunate that it is necessary though. It is clear that neither Metal or DirectX can be the cross-platform API we'd all like so, it seems a shame Microsoft and Apple can't just support Vulkan.

Where do I point to any "pet issues"?

I don't say it is already too late, I say it might be. That may be overly dramatic but, unless you refute that there is a problem with an actual argument, you are hardly arguing against that.

> It is a joke to suggest putting another abstraction over the low-level api. That is squarely the domain of libraries and frameworks.

That's fine for native apps when the libraries and frameworks can be native and thus high performance but, on the web, these have to compile to JavaScript and, while that can be very fast, a native framework is going to be faster than one running in JavaScript ontop of a lower-level API. This is a problem with the web though.

Macs used to be popular with developers but, this has basically changed IMHO. Perhaps they are popular with web designers still but, developers seem to be using Macs no more than the rest of the population to me now. It is Apple's complete lack of support for them that has brought this about IMHO and, I think it will be the end of Apple in the (very) long run (it will be the end of them as anything other than a phone manufacturer sooner and eventually completely I think).

It is a serious problem for the future of Apple that they have almost completely lost the support of software developers. It used to be that most software developers had MacBook Pros and, the ones that didn't wished they did. Now software developers are generally buying non-Apple machines and running Linux or Windows. In the short term, this is only a tiny market so the loss of sales is irrelevant but, these people are people that other people look to when they are deciding what to buy and, they are people that develop software that other people use. If there is no decent software for Mac OS because none of the developers who would otherwise write it and release it use it anymore, it will make it much harder for other people to use. Both of these are long term effects and, it is too soon to show their effect on sales but, they are important. Since the release of Mac OS X, it has been an attractive platform for developers but, this has completely changed in the last couple of years and, the only reason to use it now is for iOS development IMHO.

Windows has done an awful lot to make itself more attractive to developers recently because they get that it is vital for their future. I hate Windows but, even I have to admit, it has got way way better.

Apple's decision to stop producing things like AirPort Extreme or monitors is a stupid decision in the long run too. Even if these don't make any money on their own, part of what makes Apple an attractive platform to people is that they can buy everything from Apple and it work together so, even if these lose a bit of money, they make sense to do.

There are an awful lot of reasons to not use Mac OS so, it has to get the reasons to use it right and, it is quickly losing them. Fair enough, most of their money comes from selling iPhones but, sales of these will be seriously harmed in the long run if Apple can't sell other systems that integrate well with them. For example, Microsoft would not have to port or update Office on iOS if there wasn't the possibility that it could weaken their hold on the market if there was a Mac and iOS Office alternative. As it is, they would be insane not to support it on iOS but, without Mac OS and Macs, not doing so would be an option and, it would be a serious selling point for Windows phones. Apple's strategy is seriously broken and, it is going to be a serious problem for the company in the long term if it doesn't fix it soon, if it isn't already too late.

The latter I think.