nas

How so? Does Rust have zero runtime overhead? I would find that hard to believe.

It looks interesting but phrases like "embarrassingly parallel execution" make my marketing hype detectors trigger. Maybe they could tone down their self promotion just a touch. Also "Even though Polars is completely written in Rust (no runtime overhead!) ...". I find that hard to believe.

I think it can't use the same recipe. Sam's approach for CPython uses biased reference counting. Internally, Pypy uses a tracing garbage collector, not reference counting. I don't know how difficult it would be to make their GC thread-safe. Probably you don't want to "stop the world" on every GC pass so I guess changes are non-trivial.

Sam's changes to CPython's container objects (dicts, lists), to make them thread safe might also be hard to port directly to Pypy. Pypy implements those objects differently.

> Surely you mean density?

The ideal gas law applies, at least nearly enough. So PV = nRT. By saying the density is equal between the top and bottom, you are also saying the pressure is equal. The air around the wing is having it's momentum changed, not it's pressure. At least, at sub mach speeds.

That sounds like the problem of explaining how magnetism works. Engineers and scientists understand very well how airfoils generate lift. It is not some kind of mystery like the article implies.

It is true that most of the popular simplified explanations are incorrect. Flat plate airfoils generate lift if they have positive angles of attack. Airplanes can fly upside down. At fractional mach numbers, pressure above and below the wings is essentially equal.

If you are not flying near the speed of light, Newton's laws apply. So, if you want simple explanation, the wing deflects air downwards and that pushes the airplane up. If you put your hand outside the car window at an angle, you will feel a force. Should be simple enough for 2nd graders.

I'm afraid it would end up like the Android store changelog where all you get is "Bug fixes and performance improvements". Only a small percentage of devs would actually take the time to write something useful. I guess having a standard place doesn't hurt.

Open location codes (plus codes) are just as good and non-proprietary. Sad if actual emergency services have been persuaded to use a proprietary system.

The fact that you have to use quoting nearly everywhere is a design flaw in the Borne shell. Some shells, like Plan 9's rc, for example, don't expand after variable substantiation. They have an operator to call if you want to explicitly force expansion. That's so much cleaner and less error prone.

We have been using M5 Hosting for one of our servers since 2011. They have been extremely reliable up until today. Based on what was posted about the Hacker News server setup, we have something similar. We have a "warm spare" server in a different data center. We use Debian, not FreeBSD.

We are in the process of slowly moving to a distributed system (distributed DB) that is going to make fallover easier. However, that kind of setup is orders of magnitudes more complex than the current (manual fallover) setup. I really wonder if the planned design is going to be more reliable in practice. Complexity is almost always a bad idea, in my experience. Distributed systems are just fundamentally very complicated.

Interesting but I would be reluctant to touch anything controlled by Oracle. They don't have a good track record of treating developers nicely. E.g. trying to claim copyrights on APIs. Or, recent Java licensing changes. Bit like sticking your hand in a lawn mower, IMHO.

I'm not sure why people would be much interested in what Kasparov has to say about AI. He clearly doesn't know much, as displayed with his wild accusations of cheating by the Deep Blue team. He knows a lot of about top-level chess but almost nothing about AI. When he lost vs Deep Blue, the AI was not stronger than top chess players at the time. Instead, Kasparov had some wrong ideas about what the computer could and could not "see". If he understood computer chess better, he could have easily won, IMHO. He played into the machine strengths and was clearly flustered when it didn't behave as he expected.

I don't have high hopes either. It takes a combination of hardware and software to produce a really good trackpad implementation. Apple has the advantage of total control over the hardware and years of research on the software. They bought FingerWorks (https://en.wikipedia.org/wiki/FingerWorks) in order to improve their touchscreen and trackpad products. Wayne Westerman spent years on the problem before getting acquired. I'd imagine many more person years of research has been invested at Apple.

That's not to say we can't do better and it's not worth making an effort. However, thinking Linux can match Apple in terms of trackpads is wishful thinking, IMHO.

I use Bitrefill to buy pre-paid credits from my daughter's mobile phone. Paying with Lightning gives me a small discount and the payment process is easy. I use the "Bitcoin Lightning Wallet" app on my Android phone (BLW). I had to transfer some coins into the wallet initially and then use some of those coins to "open a lightning channel". Once that's done, paying for something on Bitrefill takes a couple of touches. The transaction completes nearly instantaneously (like less than 10 seconds) and the fees are small (0.1% fee on 15 USD payment).

Ease of use for Lightning is not to the point where I think it is good enough for the average user. However, in the early days getting on the Internet was also not easy (remember dialup, PPP and SLIP? I do). I think Lightning is interesting because anyone has the ability to set themselves up as a merchant and receive payments. Right now it is complicated and a bit clunky but it is actually possible.

It will be interesting. The amount of fiat money being created right now is a bit crazy. Whether that is "good for Bitcoin" is not entirely clear. Bitcoin has failed to live up to initial hopes. Transaction fees are too high and throughput (transactions per second) is too low. In a way, it is victim of its own success, at least in terms of price per coin. The second layer protocols, like Lighting, were supposed to solve the fee and throughput problems. I've played with Lighting and when it works, it is amazing. However, it far from a simple and polished user experience. Maybe they will eventually get there. Or, maybe people will give up waiting.

Likely yes but it depends on the Bitcoin price. The amount "wasted" (i.e. securing distributed ledger against attacks, providing difficult to fake notary service for transactions) is dependent on block rewards and fees. Since the block reward makes up most of that and has now been halved, you should expect less resources being put into mining (i.e. unprofitable miners will turn off their machines).

If the price of Bitcoin now doubles presumably no miners will be turning off their machines. If it doesn't double, some fraction of all mining setups just became unprofitable.

Are farmers in Ontario planting corn already? Seems a bit early in the season to me.

The OpenOffice people will probably still tell you the project is not dead. However, they have been almost incapable of making releases for the past few years. If you look at their code repo, there are an order of magnitude more commits going into LibreOffice (maybe multiple orders). I admire their tenacity but at some point the right thing to do was to hand over the Open Office name over to LibreOffice. The war has been over for years and LibreOffice won.

She is using a "planter". That is a quite expensive and complicated machine. It's used for crops that have expensive seeds or very precise planting requirements. Corn seed is expensive and a significant cost of growing the crop. So, you want to make the best use of the seed. A planter will meter out seeds one at a time and place them a fixed distance apart in the seed rows. Seed depth is also carefully controlled. Corn will yield better if plants are optimally spaced in the row. Less sophisticated seeding equipment (e.g. air drill, air seeder) will randomly space out seeds in the row. For lower cost seeds like wheat, that's typically good enough and it is a simpler machine.

Another difference is that planters typically have wider row spacings. For corn, that's not a problem because the plants want more space. However, for cereal crops like wheat, ideally the spacing should be smaller. Typically spacing for wheat might be 8 to 10 inches but even narrower might give optimal yield. To get narrow spacing, you need more seed rows and those get expensive given the complexity of the planter system (high cost per seed row).

In area she is farming, corn and soybeans are the major crops. There are a bunch of other field crops they might grow. Wheat is one but there are many others.

Example planter manufacturer (lots of other companies make them):

https://www.monosem.com/Products/Planter/Monoshox-NG-Plus-M

Yeah, I grew up not far from St. Brieux and the Bourgault plant. My father was one of the first farmers in the area to start using a "new fangled" air seeder system. That was back in the early 1980s. The machines have gotten a lot larger, more complicated and way more expensive since then.

The user experience is a lot better than it was a few years ago but you are correct, it's a lot of screens. There are two screens for the tractor itself. The lower screen above throttle, displays and controls tractor related stuff. The screen above does GPS guidance and mapping (automatic steering). There is a screen from the planter tool. That does mapping as well and probably does seed (population) rate control. The small blue screen I think is for the fertilizer controller (separate system and manufacturer again). I guess the screen all the way to the right is also for the planting tool. Maybe monitors the tanks that store the seed and other planter properties. I'm not familiar with the planter she is using.

They have integrated some things over the past few years (ISOBUS is the standard communication protocol for integrating). There is a lot more integration that could be done but it requires a lot of cooperation between companies. Also, the tractor is a multi-purpose tool and in this case is being used for a very specific job. So, many of the screens apply only for the job she is doing.

I'm guessing that video is taken in the US since she is planting corn. Here is another video from Southern Saskatchewan. People might be interested in the equipment being used. Mike is quite an character. He works on a big operation, I think over 20k acres. The equipment he is using costs a fair bit of cash. The seeding system (para-link hoe drill) and tractor to pull it likely costs between 500k and 1m CAD. They have multiple units like that.

https://www.youtube.com/watch?v=uM5ZBNzvKz4

The video doesn't show too much of it but Mike's equipment a bunch of technology on it as well. Some of the stuff:

- auto section control: turns off/on seed & fertilizer automatically to minimize overlaps and prevent skips. On large machines (e.g. 80 ft) the cost of overlap is quite significant. The seed and fertilizer is carried by a pneumatic system and optimally tuning the system is a bit tricky (he shows a bit of that)

- auto rate control/variable rate control: with variable rate, the field is split into many zones and the applied rate of seed and fertilizer is optimized. That's a whole topic into itself, I won't explain here.

- population/blockage monitoring: this system monitors seed and fertilizer flow in the pneumatic delivery system and will alert the operator is something is wrong (blocked run, rate to high or low). That's the "Agtron" system he is talking about.

- I don't know if his para-link drill has it but there is a variable packing system available. That will monitor packer (the wheel behind the seed opener) and adjust packing pressure depending on field conditions. Wet areas of the field will need less down pressure compared to dry areas

- As is typical these days, GPS mapping, guidance. He has two different screens showing the map. The Deere screen doesn't show the individual on/off sections of the drill and so it shows more overlap. The Topcon screen (comes with drill) shows the sections.

- The system for controlling the metering on the drill is fairly advanced. For planters, it is typically more advanced yet (corn seed is really expensive and so very precisely metering it and placing it is key). On the Bourgault drill he is using, there is a variable speed hydraulic motor on the metering system with a feedback control loop to control the rate. Early in the video he is calibrating those meters so the system knows the mass-flow feedrate of the meter (e.g. RPM of meter -> lbs/min of material). That feedrate will be converted to a per-unit-area application rate. The variable rate prescription map will provide input to the rate controller.

Just some info in case people are interested. Running a profitable farm is a challenge and most farmers are aggressive in adopting any new technology that will help them get an edge.

Right. It was meant to intercept Soviet bombers coming from the North. For other purposes, like air superiority, it would have been ill suited. People thinking it could be resurrected as an alternative to the F-35 are wildly confused.

If you compare the specs with contemporary aircraft (like the English Electric Lighting) the Arrow is impressive but not vastly superior. The "brain drain" after the cancellation of the program seems the biggest tragedy to me.

Your confusion is why I hate the term "mining". Call it "transaction notary service" and things make more sense. Currently the people with hardware get paid by a combination of transaction fees and inflation of the bitcoin supply. Once all blocks are "mined" they get paid for being notaries only with the fees.

They know how to make the old equipment. Buyers with enough cash to buy new equipment don't want it. They get warranty and they want all the fancy electronic features on the modern stuff. Deere know what they are doing.

As someone who grew up on a farm and spent 7 years running one (few thousand acres so fairly good size), I can provide some background on why this is happening.

The large farms are driving new equipment sales. They are the ones buying the brand new John Deere $700k combine harvesters will all the bells and whistles. The problem is, those bells and whistles add a lot of extra complexity to the machine, making it harder and more expensive to fix. Deere doesn't make it easier since they don't provide details needed for 3rd party repair people (e.g. schematics, software tools for managing embedded controllers, etc). The people buying new equipment don't care about that. Their equipment is covered by warranty and Deere fixes it for them (or replaces it). They sell the machine after it is a year or two. So, they never deal with the crap repair-ability of new equipment. The 2nd stage used market cares a little but not so much either. They can still get Deere to fix it for them, maybe not under warranty.

By the time the equipment gets to the 3rd tier used market, it is already heavily deprecated. The loss in value due to poor repair-ability is not getting fed back up the chain in any significant way which would make the primary buyers change their decision making. They want the bells and whistles and they will pay a little extra in deprecation to get them. The problem for society is that you have a $700k machine that is basically a paperweight after a decade or two. You might was well drive it in the junk pile because no one is going to be able to make it run. At least, not without tearing out heaps of electronics that are no longer working. New machines are utterly dependent on onboard electronic control systems (e.g. ECMs). They won't run without them.

New machines are disposable and that is what the buyers are deciding to choose. You can't put all the blame on companies like Deere. The contrast to old farm equipment is dramatic though. We have an old Ferguson tractor, might be from the 1950s. Everything on that tractor can be fixed. If we wanted, we could make it run like it just came out of the factory. For jobs on the farm that don't need a big tractor, it does them just fine. Probably in 100 years you will still be able to keep it running if you want.

I have a 13" XPS and a 15" Macbook Pro. I wanted to like the XPS but the Mac is just much better hardware. First, there is no comparison between the quality of the touchpads. The MacBook one works great but the XPS is terrible (imprecise movement, accidental movement/clicks from palm). The XPS wifi card is unreliable, it frequently disconnects. I understand a lot of people replace it with a better one. The screen is not great. There is no way to disable the automatic brightness magic going on (terrible for doing photograph processing). There is no way to turn of the eye blinding charge light on the front, under the touchpad. For a laptop that is premium priced, I'm disappointed with the hardware quality. I prefer my Lenovo X230 over the XPS 13.

Python 3 making 'bytes' an array of integers was a minor mistake, IMHO. I.e. b'abc'[0] should be b'a', not 97. That change made it harder to port code and also makes the bytes() object a bit more unhandy to use. Much too late to change that now.

However, as someone who as done a mixture of low level (e.g. system tools), high level (e.g. web apps) and network protocol programming, the Python 3 bytes/str model works well. If you really want to treat a 8-bit byte string as a string, you can always decode as "latin1". In my modern Python 3 code, I don't find a good reason to ever do that anymore.

I don't wish the Tauthon project ill but I suspect people are underestimating how much work goes into maintaining Python 3. If the Tauthon project scope was limited to taking Python 2.7.X and doing bug fix only releases of it, I think it could be a successful project. Since they seem to be backporting features from the 3.X branch, I don't see them keeping up. Python 3 has too many users at this point. If you look at the Tauthon commit log, it seems clear they are being left behind.

There is another problem with trying to backport selected Python 3 features. How do you decide what gets backported? New features will introduce incompatibility. Even if the feature is forward compatible, you end up with code that will run on Tauthon 2.X but not on Tauthon 2.X-1. If it just a better Python 2, that's fine. When it is some 3rd kind of thing with a relatively tiny user base, who is going to use it?

I suggest taking this article with a grain of salt. The assumption seems to be that it's totally fine that Linux can have filenames that are arbitrary byte strings and that don't convert to valid Unicode text. First, Python 3 has a good way to deal with those. See PEP 383: Non-decodable Bytes in System Character Interfaces.

Second, having filenames that are not valid Unicode text (even if Python 3 has a way of handling them and round-tripping them) is going to cause you a lot of pain. No one who has thought through all the issues thinks its a good idea. The modern computing world uses Unicode text all over the place. Filenames are manipulated by humans and we deal with them as text.

The idea that 8-bit byte strings are the ideal way to deal with text is a dead end. I expect we are going to see more of these kinds of articles now that Python 2's EOL is coming. In retrospect, you could argue that Python 3 should store Unicode text in memory has UTF-8. However, at the times decisions were made, UTF-8 was not dominate as it is now.

Look at the cpython history. There is a major change from Mercurial to Git. It's not that Mercurial doesn't support the "rebase" workflow. It does discourage it though. Personally, I much prefer the "rebase your WIP changes, avoid merges" style. It is much easier to work with the resulting history.