A lot of things in Mercurial kind of geared you towards using it more like Subversion was used. You pretty much could use Mercurial just like git was, and is, used, but the defaults didn't guide you to that direction.
One bigger difference I can think of is, Mercurial has permanently named branched (branch name is written in the commit), whereas in git branches are just named pointers. Mercurial got bookmarks in 2008 as an extension, and added to the core in 2011. If you used unnamed branches and bookmarks, you could use Mercurial exactly like git. But git was published in 2005.
Another is git's staging area. You can get pretty much the same functionality with repeatedly using `hg commit --amend` but again, in git the default gears you towards using the staging approach, in Mercurial you have specifically search for a way to get it to function this way.
I think the best, and also most popular, textbook for a Quantum Mechanics 1 course is "Introduction to Quantum Mechanics" by David J. Griffiths. This is also what Claude says.
But you also need some math: Complex numbers, linear algebra, some basics of partial differential equations.
But a traditional university course in quantum mechanics aims at doing quantum mechanics in 3-dimensional space, to solve electron orbitals and energy levels of hydrogen atom. But all this 3-dimensional mathematics, you don't necessarily need if you just want to read about quantum computers. Maybe some quantum computers textbook has a presentation of the basics of quantum mechanics that leaves out the topics that traditional physics needs, because traditionally physics was interested in how atoms are build.
Finland tried a project, drilling two 6km deep holes. The temperature at 6km depth is 120C. The idea was to pump water down one hole, and get heated water up from the second hole. But the rock wasn't porous enough, they could not get enough water to flow from the bottom of one hole to the other hole. So in the end, they couldn't extract enough heat out of the setup.
It's really really hard to 'aim' a 6km deep hole. Hitting a slab of tough rock can deflect the drillbit off course. If you remember the Chilean miner rescue in 2010, who got rescued by a new hole being drilled - they had 3 seperate holes being drilled at the same time as backups, just because they were worried about the success rate of actually hitting their target. And that was only 0.7km underground.
directional drilling could work if they started nice and high up and aimed to meet somewhere, but turning 90 degrees at the bottom of a 6km borehole is going to require a 6km long directional drilling rig, and probably a fair bit of extra depth to make that turn. it might be possible, but at those depths everything becomes much more difficult to the point where it might make more sense to just give up and abandon the project.
it does like a good opportunity for the fracking techniques mentioned elsewhere in this thread - drop some explosives down those boreholes and see if you can artificially increase the porosity.
Penrose believes that consciousness originates from quantum mechanics and the collapse of the wavefunction. Obviously you couldn't (effectively) simulate that with a classical computer. It's a very unconventional position, but it's not circular.
This is just another form of "god of the gaps" - Penrose desperately wants an interpretation that would allow for freedom of will, and so he constructs a theory around a physical process that allows for randomness, despite there being no evidence that this process is actually relevant to consciousness.
> But how are animals with nerve-centres or brains different?
In current LLM neural networks, the signal proceeds in one direction, from input, through the layers, to output. To the extend that LLM's have memory and feedback loops, it's that they write the output of the process to text, and then read that text and process it again though their unidirectional calculations.
Animal brains have circular signals and feedback loops.
There are Recurrent Neural Network (RNN) architectures, but current LLM's are not these.
For my mother, the year of Linux on the desktop was this year.
Basically, she got enough of Windows, mostly due to subscriptions, that there was news being shown in the browser, and some other related issues and she was incredibly happy with Ubuntu (which is of course American, but since it's free and gratis, it doesn't really matter, and there's always SUSE).
She liked the cleanness, the absence of distractors, how it was clearer what was in the cloud and what was on the local machine, that she wasn't paying any continuous fee for LibreOffice and the happiness this switch brought was huge.
The only reason people are still using Windows is gaming and that it's a default on the machines at computer- and electronics stores. They'd be happy with Linux, they'd be more productive with Linux and they'd be calmer with Linux.
People who don't know often imagine that, understandably. Recreating years of accumulated deployment and management in a new system is so expensive, it's usually impossible. In a real sense, you have to redo many years of work, all at once. And on top of that, you have to deploy it all at once - an immensely complex project that is almost certain to be a disaster.
Also, in many ways, Windows management components (Active Directory, Group Policy, etc.) have no competition:
First, you must have management systems: imagine you are deploying, configuring and managing a new application on 10,000 desktops, or just 1,000. You can't manually go to each desktop (just add up the time spent walking between desks!); you must automate it.
Second, most user applications provide management components for Windows and for no other platform. If they have something else, it's often an afterthought (and goodness forbid they stop developing it and you are left 'to your own devices').
Finally, there's usually no reason not to use Windows. Why create these risks and costs? The users care only about the applications - these aren't their home computers; the IT department handles the OS, etc. The network effect of the Windows standard is hard to beat.
There are exceptions: Some deployments are very simple and can be done on Linux, for example POS cash registers. Many applications now depend on web browsers, though even then you can have DRM and other issues, and you don't know what new application a user may need tomorrow. Macs are a standard in some places.
I forgot another aspect of migrating: After all that time and money and energy (including opportunity cost of taking people from other productive work), what do you have to show for it?
Another directory services / management system that does the same thing as - or likely worse then - the original. All that work and at best you haven't moved an inch forward, you haven't helped the business' bottom line ... what did you do? How do you explain that to the CEO?
I work with energy systems that are still running Windows Server 2003. Even upgrading to a new version of Windows would be a multi-year project; rewriting all of the customized, Windows-specific software to work on Linux would be incomprehensibly expensive.
What major corporation doesn't use AD, excluding special cases (e.g., Apple might use their own, or do they use their Macs under AD)? What do they use?
I ran Linux as my desktop since... approximately the turn off the millennium, with a brief downgrade to Windows from when the Rift S came out until I finally got around to switching back last year.
I should probably see about finding time to upgrade my laptop away from the os it came with as well as some point...
One bigger difference I can think of is, Mercurial has permanently named branched (branch name is written in the commit), whereas in git branches are just named pointers. Mercurial got bookmarks in 2008 as an extension, and added to the core in 2011. If you used unnamed branches and bookmarks, you could use Mercurial exactly like git. But git was published in 2005.
Another is git's staging area. You can get pretty much the same functionality with repeatedly using `hg commit --amend` but again, in git the default gears you towards using the staging approach, in Mercurial you have specifically search for a way to get it to function this way.