std_throwawayay

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.

Would he use C++ or Rust?

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.

I don't think it changes until the next generation comes.

The next generation of professors.

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.)

Yes, the fish we catch will die out. Bad for us because we don't have any good fish left over.

What I'm also saying is that I think that other fish (or lifeforms in general) will take their place.

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.

Doesn't the extraction of fish have a positive impact on the O2 balance?

I thought that overfishing the kinds of big fish we like to eat will just lead to a growing population of smaller fish and other marine life.

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.

CPython is really quite slow by design.

The data structures are slow by design.

The way we use these data structures is quite inefficient.

Having a fast interpreter only about doubles the execution speed in most programs leaving another factor of 50 open for future generations.

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.

Do we have any reliable information if this is just Apple or if Chinese consumption is down across the board?

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.

I think none of your points are really set in stone.

* The kernel already contains some C++ which (if you ask C programmers) is not C. And many C programmers are more likely to accept Rust than having to deal with C++.

* AFAIK there is not gcc front-end for Rust yet but LLVM tools can compile the kernel, too. When Rust stabilizes gcc support may come, too.

* The barrier for entry could be lowered by using Rust for Rust programmers if it is employed in some specific modules. The resulting code could be more clear. Not everything in the kernel is pointer pointing and bit shuffling.

* The number of architectures that Rust supports are growing daily.

Both sides have convincing arguments and research to back it up. They have good answers to the seemingly contradictory research that the other side uses. They both provide a consistent picture.

One or both of the theories has to be wrong but I cannot decide. I can learn and read all about it and take both viewpoints into account but I still cannot decide. I could do my own research but I would come up with one or the other answer depending on what data I look at but it's not better than what I have already.

What should I do?

This is a real problem because science cannot provide the correct answer. It is more about choosing a side and sticking with it than about finding the truth.

I have used Matlab and GNU/Octave in parallel for some years half a decade ago. Octave can do most things that I needed but was slower to run for many things. With Octave you didn't run into licensing problems as those floating licenses had their limits and sometimes I needed to run quite a few instances in parallel.

Now I use Python exclusively. The language is so much better and more sane and almost any library is available. I will never go back.

Today, I would recommend Matlab only in rare circumstances. Currently I cannot think of one use case that I had in the last three years where I would prefer Matlab to Python. Using the Matlab language with a portable Octave installation can be useful for teaching matrix/vector topics to people who have little programming experience and don't know Python. You can get results very quickly. The syntax feels most natural for manipulating matrices and everything seems to be a matrix.

Other than that I think the Matlab language and ecosystem is kind of a dead end. But it will provide profits for a few more decades due to sheer inertia.

It lacks blockchain technology. Given the development cycles in play for such consumer products the blockchain support will probably come two weeks after bitcoin disintegrated.

Yes, but this time it's different.

That's what everybody inside the bubble thinks. That's what they must think. It's what makes the bubble work. The bubble must always contain some forgotten ingredient that makes it special. Something that people do not remember about the past bubbles. Then nobody inside the bubble can prove that it will burst and if it's not provable maybe it won't burst.

I've come to believe that we'll adjust our numbers in time. That time has not come yet but it will come.

TDP doesn't mean much at intel. Expect any performance chip to consume way more than TDP when fully loaded.

I believe that there are lots of professionally-run science scams.

It starts with an idea that looks good on paper and a bunch of scientists investigating it. At one point it gets picked up by the management of a company and commercialization is being started while the technology is not ready yet. Now you have high-risk development of a new technology in the framework of commercial management. Failing is no option anymore. During the development it becomes clear to some insiders that the goals cannot be achieved. To those are three options. Either they quit, they shut up or they upsell what they have. Plans become bigger and bigger and the deadline shifts later and later. The later you are, the more sunk costs you have and the bigger your plans need to be to recoup the costs and keep your department alive. This is what I consider the when it becomes a scam. It started with science but instead of burying the dead horse it is paraded around town and management applauds while those who know do not talk.

Using Matrix[i,j] is the most intuitive way for most people. It's what you'd use if you don't know anything and it's what you'd understand immediately. That's the benefit for the user.

It's one of those many tiny things that add up. There's good reasons why C++ gets so much hate and there's good reasons why it's used in so many applications. I see no good reason to not have multiple array indices.