An employee wants more than money. If I have the feeling that I grow, I stay longer. If I get the feeling that they want to keep me down, I leave sooner. Simple as that.
If you increase the skillset of your employees you get back something along the way, so it's not just money wasted but also collecting a lot of interest. Also you become attractive for employees who want to grow. It's easy for the beancounters to count all the wasted money but it's not so easy to evaluate the real productivity that such employees give back. Maybe if companies were allowed to trade employees like cattle that mindset would change.
Forgetting about the enormous heat sink is a typical rookie mistake. Those things produce lots of heat when you try to cool something. They are much better suited for heating something to a specific temperature than cooling.
One advantage that they have is that they can pump the heat in both directions and change direction very quickly. This means that you can keep temperature very precisely with a closed regulation loop.
Providing base technology doesn't seem to lead to financial success. You have to provide more concrete solutions for companies and people instead of the abstract infrastructure. I wonder if protection of the base technology through software patents could have averted this looming financial disaster.
It could easily be replaced by an electron app running a QEMU in JavaScript emulating an virtual machine running Windows 3.11 on an Rasperry PI terminal connected to a cloud server located at the edge for maximum performance paid for by real-time Bitcoin micropayments.
One of the reasons why the prohibition of alcohol failed but cannabis is illegal has to do with the DIY-supply. Everyone could brew some alcohol at home. Growing a hemp field is not so easy to do undetected and therefore much easier to enforce. Cheap artificial lighting did have some impact but this yeast (if it works well) could be a real game changer.
GNU/Octave has a great strength and weakness that it uses the Matlab language. This is great for many who are educated with Matlab but don't know much else. After some time I found Python and the ecosystem around numpy/scipy/matplotlib fit my problems much better. Python just much more flexible and better suited for general programming tasks than that weird matrix oriented language.
Why should anyone use Octave over Matlab?
- Licensing cost.
- Freedom.
Why should anyone learn Octave instead of Python?
- It's a bit easier to get started for scientists who are not programmers.
- If you mostly do vector/matrix math, the language is nice.
- Otherwise I don't know any good point.
All in all I like a free alternative to Matlab but have the feeling that most people are just better served by joining the much bigger Python ecosystem. (Or maybe R/Julia/Rust which I don't know so much about in this context.)
I agree that taking one specific animal out of a complex system that had a long time to adjust will produce big changes. Killing the wolves allowed the deer to thrive. We wanted lots of deer, so that was good for some time. Now we don't hunt enough of them, so we need wolves again.
I agree that the oceans change - a lot - due to human influence. Some species will dwindle in numbers and disappear. It takes a long time for new species to emerge. But what I'm not so sure is that the overall change necessarily would have to be so negative in the long run.
> MacBooks are worse now than they were since 2015. I won't upgrade until they get rid of the TouchBar. I would rather go back to Windows than use that stupid TouchBar.
For me, the keyboard kills it. It feels cheap. It almost feels like there's no keys at all like the glass surface that is rumored to come. I'm sure that's great for people who are media consumers but producers of media and software often like to have a keyboard. To me it feels like they missed the market and try to sell products at premium price to normal customers.
Also, the lack of HDMI and one USB-A port on each side would hinder my workflow.
They are probably the fastest dicts and lists we can imagine today. If you really need lists and dicts for your data, you need them and won't gain much. But if you don't need them and instead could use something simpler, an array of C structs would be much faster than a list of dicts.
Right now you have one mutex for everything (the GIL itself) and everything else doesn't need locking. In order to achieve similar convenience without the GIL you would have to trade this for one mutex for every single data structure. Because the data structures in python are so flexible, every single variable needs its own mutex then. Locking every single variable access would be enormously costly.
Other languages achieve a good compromise by clustering data structures into fewer parts with only a handful of mutexes that are locked while other threads work on different datasets. This is usually done manually and with great care as it is the heart of both safety and performance. I don't know if there is an automatic solution to this problem that is compatible with the way python programs are structured.
The libraries basically assume that, while you call them, nothing else changes. In order to ensure that you need to lock everything down. Because you don't know what these libraries do and what data they access it needs to be everything (like it is today). It should be possible to only lock the GIL when such a library is called, so there should be kind of a middle way forward.
The GIL comes with great convenience as you don't have to worry about a whole host of data races. It's no silver bullet but it's mighty convenient if you only do some multi-threading like in a web-server.
Many libraries are not prepared for the disappearance of the GIL and while it's not a general problem for python per se it will be a great amount of work to make every library compatible with GILless python.
Therefore I think that you must always provide an option for the GIL that is enabled by default in order to provide backward compatibility.
That [1] was what I remembered. They were preparing for C++. But obviously it didn't get as far as actually including C++ code in the mainline kernel. Maybe it was a preparation in order to allow experimenting with C++ in the kernel.
I could swear that I read that they start allowing some C++ contributions. But with a search in the kernel source I could not come up with any evidence. If there is any C++ code in the kernel they hid it well.
If you increase the skillset of your employees you get back something along the way, so it's not just money wasted but also collecting a lot of interest. Also you become attractive for employees who want to grow. It's easy for the beancounters to count all the wasted money but it's not so easy to evaluate the real productivity that such employees give back. Maybe if companies were allowed to trade employees like cattle that mindset would change.