This is inaccurate: you can definitely make "Hosted $THING" under AGPL. What you cannot do is modify said THING, host that (more precisely, make it publicly available as a service; if it's private, it's still ok), and keep the changes private.
Or you could try a package repository for one of the C/C++ package managers. For example, for build2[1] we currently have ~300 packages[2] which you can all build in a uniform way.
I am curious, what happens if I get a /48 from you and some time later you decide you don't wish to be a LIR anymore. Do I get to keep my /48 somehow (i.e., does RIPE guarantee this)?
I am guessing the reasoning goes like this: if we only support IPv4, then it's on all these ISPs with IPv6-to-IPv4 CGNAT to make sure their stuff works properly (and chances are they will notice if it doesn't). But if we support IPv6, it will be on us to make sure people behind those ISPs can still reach us (because hardly anyone goes via this IPv6 route and if it doesn't work it's likely nobody at the ISP will notice).
That's in a sense what Debian is doing with its experimental/unstable/testing/stable repositories. We also adopted a similar approach in build2 where we have queue/testing/stable sections of the repository. A newly submitted package version first lands in the queue where it is not yet visible to anyone. After it has been tested and reviewed, it is migrated to testing where it becomes available for testing by the larger community. After some time, if no issues are found in the package, it is migrated to stable. You as a user of build2 have a choice from which section(s) of the repository you want your dependencies.
If you have the time to share the details, I would definitely appreciate them (looking to do something like this myself). In particular, on which hardware did you build the kernel? Or did you cross-compile it? Also which bootloader did you use? Thanks in advance!
How about an equivalent for Clang targeting the MSVC runtime (which is how both Google and Mozilla build their web browsers for Windows), is this supported?
> The two main backers (Apple and Google) seem to have backed out.
This highlights an important difference between GCC and LLVM that many fans of the latter seem to miss: LLVM is first a bunch of compiler components that Apple and Google use for their own needs and a C/C++/etc compiler for you and me second and only as long as it flows naturally from the first. While GCC is a C/C++/etc compiler, that's the end-goal.
I can't say anything specifically about this case, but generally, sometimes the whole architecture has to be changed in order to support concurrency (especially in the "millions of mutexes" kinds of problems). And such alternative architectures are often inherently inefficient in serial execution.
Thanks for working on this! It would be great if making Asahi generally usable was not blocked by the GPU driver. Currently Apple M1 is the only generally-available ARM hardware that can be used for testing other software for compatibility with ARM. So an installable version without desktop
support would be very appreciated.
In my experience the weak point here is the controller/firmware. We bought a bunch of high-endurance Enterprise MLC drives (also Intel but newer) and one of them has already bricked itself, way before reaching any kind of wear worth mentioning.
Dynamic dependencies are supported by build2 (this is, for example, how we handle auto-generated C/C++ headers) but it's not something that is exposed in ad hoc recipes that are written in Buildscript yet (but is exposed in those written in C++). Our plan is to start with the ability to "ingest" make dependency declarations since quite a few tools are able to produce those. Would something like this cover your use-cases?
You apply different amount of breaking. Sometimes you would only use the rear break (for example, if you want to take a corner by locking and sliding your back wheel).
To illustrate this point further: the common setup is to have the rear break on the right hand side of the handlebar. But some people ride it the other way around. If you are used to one way and then have to ride the bike that is set the other way (say, a borrowed bike), it completely messes up your riding.
For me #1 would be to add a version to any data format or communication
protocol. If you want to know how hard not doing so can bite, don't look further than Git and it's tourcherous migration from sha1.
To me things that are worth starting over would be the CPUs that we no longer understand and the OSes that are debugged into existence. Not a computer that has no SSD because memory is persistent.
One aspect that is not mentioned is that we build software on top of an ever-increasing number of first-to-market, low-quality, building blocks. And by low-quality I mean "worse is better"/MVP/"everyone makes mistakes"/"leaky abstractions"/etc -- pick your favorite. As a result, we spend more and more time dealing with someone else's mistakes rather than making forward progress.
Here is a previous discussion of a similar tool that also lists some of the limitations (like inability to use bridged networking without Apple's permission) of using Virtualization.framework: https://news.ycombinator.com/item?id=25382529
I am personally more interested in tools that are based on Hypervisor.framework (which as I understand offers lower-level support for virtualization). Anyone knows what is the current state of Qemu support for M1 (last time I heard there were some out-of-tree patches)?
Virtualization.framework appears to provide Virtio disk, network, etc. I wonder how Apple did it: I doubt they could copy GPL code from qemu. Maybe they copied something from one of the *BSD implementations? If they have implemented it from scratch, I wonder how buggy it is? Anyone has any information on this?
It's funny how the way to get a Linux on ARM machine with decent performance might be getting a Mac Mini and running Linux as a VM. I doubt nested virtualization will work though.