AFAIK it's more like a reimplementation of NT APIs in userspace - aka basically Wine with extra steps, or Linux UM. There was a slide deck going around about Project Drawbridge, here: https://threedots.ovh/slides/Drawbridge.pdf
5,113 karma · joined November 10, 2017
> I was pleasantly surprised how fast you can run x64 windows apps
In general as long as you have a fast enough machine emulation isn't that bad. Apple was doing that already for 68k with PPC and most people didn't noticed due to how massively faster their first PPC computers were. Still, the issue is that here we're not really talking about a high-end CPU aren't we
What would a Phillips screwdriver bring over a flathead screwdriver? Sometimes you don't want/need the flathead screwdriver, simple as that. There are macOS-specific jobs you need to run in macOS, such as xcode toolchains etc. You can try cross compiling, but it's a pain and ridiculous given that 100% of every other OS supports containers natively (including windows). It's clear to me that Apple is trying to make the ratio jobs/#MacMinis as small as possible
You're not exactly describing rocket science. This is basically how websites work, there's never been anything stopping anyone from doing dynamic UI in TUIs except the fact that TUI frameworks were dog poop until a few years ago (and there was no Windows Terminal, so no Windows support). Try doing that in ncurses instead of Rataui or whatever, it's horrendous
yeah... Ironic I guess. It's as if they've realised that it's only a matter of time until we get a "good enough" FOSS model that runs on consumer hardware. The fact that such a thing would demolish their entire business of getting VC hyped while giving out their service for a loss surely got lost to them. Surely they and Nvidia have not realised that the only thing that could stop this is to make good hardware unreachable for anything smaller than a massive corp
Mark my words: in less than one year, we'll probably get something akin to Opus 4.6 FOSS. China is putting as much money into that as they can because they know this would crash the US economy, which is in the green only thanks to big tech pumping up AI. China wants Trump either gone or neutered as soon as possible, which they know they can do by making Republicans as unelectable as possible - something that will probably do if the economy crashes and a recession happens
Writing a compiler/interpreter is _extremely_ straightforward; a lexer -> parser -> ast -> semantic analysis -> {codegen -> linker | evaluator} pipeline is a very widely understood and tested way to write a compiler in any language, regardless of what language you are trying to compile. The hard part is _learning_ how it works, but after that implementing a compiler is a kind of mechanical activity. That's why LLMs are so great at writing parsers: they can just read the source of any compiler (and they probably read all of them) and apply the same stuff mechanically, with almost a 100% accuracy. We even have formal languages to define parsers and RTL and stuff, that's how "mechanical" the whole process can be.
I'm pretty sure that any skilled compiler dev with the ISO C standard and a few packs of Red Bulls can apecode a working C compiler in a few days, give or take. The hard part isn't doing that, the hard part is the decades of iterative improvements to make it generate extremely performant yet correct code as fast as possible.
1. Covid, which caused a dramatic shift in the EU focus and required the Commission to permanently take on lots of extra responsibilities (debt, shared procurement of medical goods and vaccines, way more international recognition/influence, etc)
2. Brexit: Ireland has to follow whatever Northern Ireland does. Northern Ireland's Unionists will never tolerate being in a different timezone than London, and Farage and his cronies in the UK will never tolerate having to swallow down an EU directive for ideological reasons. BoJo was already saying back in '19 that the UK was going to keep daylight savings only to spite the EU. This means that Ireland will almost 100% veto any changes to DST unless London is on board with them.
There's also an underlying internal divergence about what abolishing DST should look like. While nobody in Europe likes daylight savings (the material act of switching), Southern and Northern Europe have a very different opinion about which timezone to keep. Right now basically 70% of the EU is in CET/CEST, so trade and business are frictionless - from the tip of Sweden down to Malta, from Galicia to the Suwalki Gap - all year round.
The issue now is that Northern Europeans generally don't give a fuck about more daylight in the summer - they already have a humongous amount of daylight during the night. What they'd like to do is to keep "natural" time all year around, because summer time would cause the sun to rise extremely late in winter. They'd like CET to become the new central European standard.
On the contrary, in Southern Europe people don't really care that much about sun rising at 7 or 8 in winter but really love the extra hour of sun on summer evenings. This means keeping CEST all year round.
Given that having a timezone between Southern Germany and Austria/Northern Italy or between the Rhineland and France is objectively terrible for the EU economy, nobody is going to propose this ever again unfortunately. I think we're stuck with DST forever unless someone caves - most likely the Nordics. Having basically all of Europe on a single timezone is just too convenient, that's why nobody went back to their previous timezones after Hitler and Franco fucked them up in the '40s and why China is still on Beijing time
It is: the original unmodified code is still MIT, but the bits you wrote and thus you hold the copyright for are AGPL. The combination of your bits + old bits is AGPL; some judge may argue your derived work isn't derived enough if you just change a few characters though. Still, I may argue that fixing a bug, no matter how trivial, requires you to perform a creative task, which almost definitely is by itself to be considered enough to go above the threshold required by a derived work.
For that specific OS, that would probably be the case? I think every API is bound to reflect the specific constraints of the language it has been written in. What I was trying to clarify was that UNIX and C are intertwined in an especially deep way, more than basically other OS that doesn't have a UNIX API, because both were born and written alongside each other, so some Unix APIs rely on C-specific behaviour and quirks and some C features were born and designed around the same historical context UNIX was born
No, C is the language _designed_ to write UNIX. Unix is older than C, C was designed to write it and that's why all UNIX APIs follow C conventions. It's obvious that when you design something for a system it will have its best APIs in the language the system is written in.
C has also multiple weird and quirky APIs that suck, especially in the ISO C libc.
POSIX has the best API. C has `fopen` which, while not terrible, isn't what I'd call "great"
Also, the REPL. Julia's REPL is vastly better than any other language REPL, by far. Python's is good but Julia is way better, even as a calculator for instance, it has fractions and it is more suited for maths