> It’s only happened twice in more than a decade, but I still have the feeling that I was better off compiling stuff manually and cultivating a tidy /usr/local/bin like I did in early 2000s. But it’s probably rose-colored glasses and I’d definitively never take the time these days.
A lot of Homebrew packages are pre-compiled binaries ("bottles" produced by Homebrew) that are pretty much just downloaded and untarred onto your system.
The Homebrew formulas' are what's used to produce those binaries, or - if there's no pre-compiled one available - that's when it's compiled live on your system.
Seems like a decent tradeoff, as otherwise installing (say) Qt could take an hour+, since that's a bit of a monster to compile. :)
The problem is that every time you install something it will update a gazillion dependencies because there is a minor version difference in a library I don't even use. And of course I did not ask for those binaries to be upgraded.
When I do a yum install, 99% of the cases it just add the package I need. And won't mess with my dev tools.
how do you do streaming with SmartShare? closest thing i could find was that the tv supports airPlay off all things. But that seems quite useless without any apple products.
i might be wrong but currently rustc is based on llvm so any platform llvm cant target, rust can target.
For the linux kernel it seems like they want to use a gcc frontend for rust (gccrs) that is currently under development. So with gccrs rust should be able to work on any platform gcc supports thus giving it the same portability of the current c code in the kernel.
I had a similar thought when I learned about e-graphs. I'm not sure yet, but I think congruence closure is a slightly different problem from the one Prolog unification solves. In particular, if you tell an e-graph that `f(x) = g(y)`, it will take you at your word -- while Prolog would give a unification error. (An e-graph should also handle `X = f(X)`, while this would fail Prolog's admittedly often-ignored occurs check.)
We started with Go++ (C++) more than two decades ago, and went on to make Java, .NET, and JavaScript versions of the library. "Go" here stands for Graph Object, GraphObject being the base class for drawn objects.
Their github repo goes back to 1.4.0 or so around Apr 2014; their changelog goes back to 1.0.0. Go 1.0 was released March 2012. GopherJS' first commit is showing as Aug 2013. I'm not sure what GoJS' first release is but it seems likely to me it predated the Go project that really looks like "GoJS" and plausible that it predated Go 1.0 entirely.
I also can't find proof, but I think Go the language was previously essentially Limbo the language at Bell Labs in the Plan9 OS world, and when the team moved to Google they updated Limbo naming it Go.
It seems (from simonsarris comments) that GoJS was created in the Limbo naming era, and is itself an acronym.
dd can do seek, skip, re-block. It's unusual to need the features but they exist for good reasons. I used dd to transfer 4.1BSD release tapes to a vax 11/720 via rl02 10meg pack and reconstruct the chunks on the receive side, long ago.
It's right in the sense that the units are the same size. IE if something increases 10 deg K it also increases 10 deg C. But it's obvious to humans that that isn't what you where asking.
Compare:
You have: 1 degF
You want: degcelsius
* 0.55555556
/ 1.8
Nitpick: There are no "deg K", because it is an absolute system it doesn't have degrees.
Notice you also don't need degrees metre, degrees watt or degrees newton, because those are absolute units they are metres, watts and newtons. It is Celsius (and Fahrenheit) which are weird because they aren't absolute but instead have this arbitrary zero point.
> Conversions between temperatures are different from linear conversions between temperature increments—see the example below. The absolute temperature conversions are handled by units starting with ‘temp’, and you must use functional notation. The temperature-increment conversions are done using units starting with ‘deg’ and they do not require functional notation.
What is different on intel since you can play fast and loose with multi threading?
Two threads reading and writing the same memory area without and locking would give problems regardless of the ISA or am i missing something?
So e.g., on x86 if you store to A then store to B, then if another core sees the store to B it is guaranteed to see the store to A as well. This guarantee does not exist on ARM.
Two threads reading and writing to the same memory area do not necessarily give problems. In fact, many software is built to exploit several facts about how memory accesses work with respect each other.
ARM processors give very few guarantees, so code has to workaround that.
thats exactly what homebrew does.