Posts by Jon 37 721 publicly visible posts • joined 28 Nov 2009
Rust is fairly new. We don't have the many decades of experience & training with Rust that we have with C++.
But that argument is basically "we should never do anything new. We should never try new approaches to fix the issues with our current approach".
When cars came out, we didn't have the centuries of experience with them that we had with horses. There was a big community of people who could use horses but not cars. People understood horses but not cars. The supply chain for the first cars probably included horse drawn wagons. There were a limited number of car suppliers compared to lots of horse breeders and sellers. But ultimately, the advantages of cars meant that, over a period of many years, all that changed.
But there have also been many other attempts at major changes that haven't worked out.
It's too soon to know if Rust will succeed or not. Maybe in 50 years a few enthusiasts will be going "remember Rust, shame that didn't take off". Or maybe people will use Rust and look at C/C++ as legacy languages like Fortran and COBOL.
Your argument is that a good programmer can write memory-safe code in C++. In theory, you are correct. In practice, there is many years of evidence of memory safety bugs being found in C++ code. And lots of programmers are not good.
So large programs written in C++ are highly likely to have memory safety bugs. For applications where those bugs are security vulnerabilities, that is not acceptable. The other advantages of C++ are irrelevant if it's impossible to write secure code.
Any Rust code that does not use the "unsafe" keyword is memory safe. This is enforced by the language and compiler.
There has been talk of having a memory-safe subset of C++, and making the compiler enforce it. Right now, that does not exist. There is some early development work on how C++ could be extended to allow that. If/when it does exist, then existing libraries will need to be ported to it or wrapped in bindings. It's basically a new language based on C++, with all the work needed to establish a new language - which Rust has already spent years on, so Rust has a big head start.
If they wait a few months, the USA may have withdrawn it's troops from Taiwan. Either because the USA can't afford them any more, or because Taiwan won't pay for them at the price demanded by the USA (perhaps "give us TSMC or we withdraw our troops"), or because Trump just doesn't want to support them any more.
Not in the UK's experience. Hinkley Point C is located on the same site as Hinkley Point A and B. They started planning it in 2008, so 17 years ago, and it's still being built. Might get some power in the early 2030's, so 22+ years.
Git uses SHA-1 for hashing, not security. That is okay.
However, as soon as someone writes code to "get the code with this SHA hash from someone else's Git repo and run it", then the SHA is being used for security. It's the only thing authenticating that the code being run is what you intended to run. That's one of the options that GitHub provide.
Now, you might be happy with that level of security. Or you might not. Personally I would be a lot happier using SHA3-256, although even SHA256 would be an improvement.
It would probably be cheaper to just populate more RAM.
What you're describing requires chip, OS and application support, to put the right data in the right memory.
Also you can't add a socket on the end of the fast RAM bus, because that would slow down the bus even when talking to the "fast" soldered-on RAM chips. You would need extra RAM channels that are dedicated to slow RAM. That means more pads on the CPU and more tracks on the motherboard, which adds a lot of complexity and cost.
Modern RAM busses run at ridiculously high speeds that push the limits of modern electronic design. The wires going from your CPU to your RAM have to be really carefully designed, with length matching so the signals all arrive at the same time, careful choice of geometry to keep the specified impedance, and no stubs ("dead ends" that cause reflections and also act as antennas to transmit and receive interference) or branches in the wires. This avoids reflections and interference. Having a connector on the bus is a major problem - it's likely to introduce impedance issues. You can do it, but the tradeoff is slower RAM bus speed. So the RAM will perform worse.
Note we're discussing RAM performance here, not how system performance might be affected by a choice of how much RAM to fit.
Some customers will need a written quote, perhaps in a certain format.
Some customers will insist on paying 30 days after they get the goods/services. Or 90 days.
Some customers will insist on certain terms in their contract.
Some customers will have a bunch of questions before they add a supplier as an "approved supplier".
It's not just a matter of "add another payment method". It's all the nonsense that some big companies insist on for the privilege of supplying them.
This is why resellers mark up the price so much. That covers their cost of dealing with this nonsense.
When The Post Office was privatised, everyone knew this might be coming. So the government promised the soon-to-be new owners of the Post Office that the UK Taxpayers would pay any compensation. The government is paying the compensation. The Post Office gets off without any financial impact.
TikTok is a business which takes in money and pays out money. Using banks. The banks operating in the US can be told to block transactions going to or from TikTok. That way, TikTok gets no income from US advertisers and can't pay US content creators.
Additionally, TikTok will have servers in the US for better performance. Those servers will go away.
A slow website that doesn't pay content creators and can't accept advertising from US companies, is a lot worse than the current app. Lots less people will use it.
And it won't be profitable. It will have to pay more for Internet traffic because it's now paying to send that traffic across an ocean instead of having local servers. And a large revenue source was cut off. And there will be less content so less view time so less scope for adverts.
Apps do compete on price, where there are multiple basically-the-same apps from different developers.
In that case, lower fees mean they could reduce prices further. And if their competitors do that, then they may have to do that. That means consumers save money.
That doesn't apply to all apps, of course. But it does apply to some apps.
The safe, sane subset of PDF is called PDF/A. It just lets you have a document you can view and print, which is what most people using PDF files want.
The full PDF spec has extensions for video, scripting, forms, DRM, encryption, digital signatures, and more. Some people want and use those features. Most don't.
Depends if he knew he was working for ransomware people.
If you're asked to do something like "write code to print a message on every printer", that's not illegal in itself. There could be legitimate or at least legal uses.
If you know that you are working for criminals then it becomes illegal.
However, if you are asked to write code to disable Windows Defender, then most people would suspect that they might be working for criminals.
And if you're given source code to ransomware and asked to add features, that is clearly illegal.
Because that is entirely theoretical at this point, and has no immediate impact.
Using quantum computers for decryption is theoretical, but people can record encrypted data now and feed that into a quantum computer if/when they become available. So nation states that want to keep their Top Secret information secret for decades, are starting to worry about quantum computers now.
> How does making "non-important" people cold benefit them?
It prevents the entire electricity grid from collapsing if there is insufficient generation.
Third world countries often have rolling electricity blackouts due to insufficient generation. The UK can of course do that, by turning off parts of the grid, but that would affect everyone in an area.
Smart meters allow the blackouts to be targeted to individual houses.
The UK has got rid of it's big reliable coal power plants, and the reliable nuclear fleet is aging out and retiring. Simultaneously, the government is pushing for electric cars and electric home heating (heat pumps).
This leaves the UK massively reliant on gas power stations, using half imported gas. There is a lot of wind and solar on the grid, but neither are reliable sources of power - you can't decide to turn them on during a calm wind-less evening.
Minor nitpick: In many countries, such as the UK, the life insurance pays out to a named beneficiary. It's nothing to do with your will. (Maybe there are countries that do it differently?)
The reason for that is that your will divides up your "estate" - everything you owned. Many countries, including the UK, tax estates. So if the life insurance money went into that pot it would be taxed. By paying it directly you avoid that tax. Also if sorting out the estate takes a long time, that doesn't delay the life insurance payment.
Yes. If you are using RAID in your motherboard, what happens if the motherboard dies? If it's implemented right, you should be able to move the disks to a different motherboard of the exact same model. If it's not implemented right, you may not even be able to do that. Moving the disks to a different model of motherboard... no idea if that will work. No idea if motherboard manufacturers document their disk formats to make life easier should you need data recovery.
(If you have 4 disk RAID 5, then data is striped across 3 disks and the fourth is parity. Fine. But what order are the 3 data disks in, and which disk is parity? Sane RAID 5 implementations will write this information to one of the blocks on the disk. But there's not one standard format for that, so no guarantee of compatibility if you change controller/motherboard. And insane RAID implementations may not write that to the disks at all, just store it in the BIOS's persistent settings).
If you're using RAID at the OS block layer or filesystem layer, then those questions have well documented answers - of course you can move to a completely different motherboard.
Your suggestion of 10% profit and 20 years payback is nonsense.
If you ignore the costs of buying the PCs and building the data centers (the thing they spent $20b on), then the only real ongoing cost is power and a tiny amount of staff costs. On that accounting, almost all the revenue is "profit". Far more than 10%, more like 90%.
So 2 and a bit years to break even. Maybe 3 years at a stretch. Which is fine. The servers will probably last 5+ years, and the data center itself will last decades.
America has a submarine specially designed for sneaky underwater operations. So I would be surprised if they **weren't** dropping surveillance devices near "Chinese" waters.
The USS Jimmy Carter is the fourth in a series of such submarines that the US has operated over the decades, and they're now building a new one.
Note that the Chinese claim to "Chinese waters" is much larger than the rest of the world thinks they should get.So America can claim to be legally surveying what it considers international waters, while inside waters that China claim.
The reason for that discrepancy is partly because China has been building artificial islands and claiming the sea around those islands. And partly because they claim natural islands that other countries also claim - and China has been building military bases on some of them.
China has been running a major operation dredging up sand from the seabed to create and expand islands there, and building bases, for many years. They clearly aim to be so well entrenched that the rest of the world can't do anything about their claim to basically the entire South China Sea.
The best for the consumer would be an open standard for apps. Any app written to that standard could work on any phone from any manufacturer. Any phone built to that standard could run any app.
Apple is clearly not open. Only Apple can make phones that run iOS apps.
Android is part way there. There are apps and phones from multiple manufacturers. The issue of the central app store is being addressed. The big remaining issue is that Google forces their apps on Android phones, and also deliberately designs Android to not work without their apps. (E.g. location services).
The environmental costs wouldn't be lower, just moved to be someone else's problem.
Well, the dollar cost of complying with environmental regulations may be lower at the cost of more environmental damage.
If the US thinks that level of environmental damage is ok, why does it have regulations against it in the US? If the US thinks that level of environmental damage is not okay, why does it outsource manufacturing to countries where it will happen? Oh, because everything is about what's good for the US, they don't care about the rest of the world.
> should DJI be required to by the Chinese government, it would push such features as an OTA update
Yes. But maybe you don't understand your local law. This is normal in many countries.
For example, here is an article about the UK law that says UK companies and employees can be ordered to do that sort of thing:
https://www.theregister.com/2017/08/10/gchq_techie_deputisation_powers/
Under US law, the US government can require a US company to give it any data it has, any where in the world. A hosting provider can be required to copy customer data from a data center in Ireland and give a copy to the US government. Under a US warrant without telling the Irish authorities.
Source: https://www.theregister.com/2018/04/03/us_government_serves_microsoft_with_fresh_warrant_for_irishheld_emails/
Now, many people would say that this kind of law is unreasonable. (I would). But the UK and US governments clearly don't think it's unreasonable, because they have that kind of law.
That leads to the conclusion that the US are just blocking Chinese companies because of blatant protectionism. Or that they are totally two-faced - "it's okay for us to spy but not anyone else."
You and the other reply are missing the point about Comic Relief. It's a very bursty load.
That big burst of load for one day, if you went "on premises", requires buying a lot of servers sized for the max load, and having them sit idle the rest of the year. That is expensive.
Renting server capacity in the cloud is a much cheaper option. And using one of the cloud services such as serverless, which automatically scales up and down as needed, is an even better option because you don't need to predict your peak load as accurately.
As with everything in life, there is not one solution for everyone. Not cloud, and not on-premises. Use the best solution for the problem you're trying to solve.
Decades ago, the US covertly salvaged a wrecked Russian submarine in deep water. That could have been seen as an act of war too. But it happened.
Before spy satellites were good, the US routinely sent spy planes over Russia, Cuba and other enemy countries. That could have been seen as an act of war too. But it happened.
The US is publicly discussing how to protect it's satellites against foreign satellites. And has plenty of classified satellites. The US likely has the capability to get one of it's satellites close to an enemy satellite, to inspect it. That's likely one of the things that their X-37B spaceplane can do, although I expect they have dedicated satellites for that too.
Dropping the service module in a low Earth orbit, it will gradually slow down due to drag from the really thin atmosphere up there, then re-enter and burn up in the atmosphere. The international standards say it has to do that within a few years. But an adversary could inspect it during that time. Possibly even manoeuvre one of their satellites close for close up pictures. Or theoretically even grab it, perhaps have an astronaut pull out the interesting bit and return it to earth. That would be very difficult, but is not impossible, so national security people could worry about it.
For the new mission, they can drop the service module in an orbit which goes much lower. That way, the service module won't survive very long, it will rapidly burn up, likely within a day or two and possibly within an hour.
That's not how the GPLv2 works. Including GPLv2 code does not automatically change the license of your own code.
Including GPLv2 code in a proprietary application, and then distributing that application, is copyright infringement. Whoever wrote that GPLv2 code can sue, and get damages and an injunction against further distribution. Just like if someone stole some proprietary source code and used it.
Now, the copyright holder could settle out of court. And might agree to do that if you GPL'd your own code and paid their legal costs. Or they might not. Up to the two parties involved to negotiate a mutually acceptable outcome.
If you want to avoid copyright infringement, then one option is to relicense your proprietary software as GPLv2 before you distribute it. But that would have to be your own choice. And once you've infringed the copyright, it's too late - you lose your rights under the GPLv2 and can never use that GPLv2 code again unless the copyright owner gives you special permission.
It's only "superabundant" once it's been created. The process of creating it is expensive. That is why Copyright exists: It gives authors a limited time to profit from their work, and then their work enters the public domain. This encourages people to make stuff.
You might say that modern Copyright law is ridiculously long, the term should be shorter, and I would agree with you. You might say that when a program enters public domain, the source code should be made available too, and I would agree with you.
But the idea of Copyright is not evil. It's there for a good purpose, even if it has been partly subverted by modern corporations. It could be fixed, if there was political will to do that (which will never happen).
They don't need it in their bylaws, because it's the law.
Just like they don't need "don't murder people" in their bylaws.
Anti-trust laws mean that industry organisations where companies conspire to harm their customers are illegal. However, industry standards are good for consumers. So meeting solely to create a standard that is a benefit to consumers, is allowed under the law.
You want a choice of browsers and CAs.
Server operators are consumers of certificates. They want a choice of competing CAs to buy from. To be a good CA you have to be accepted by most browsers.
So it's good to have a standard for "what a CA needs to do to be accepted into a browser". And it's good that all the browsers agreed to have mostly the same standard (though there are some browser specific bits on top). This is good for competition in CAs
End-users want a choice of browsers. To be a good browser, it has to support the CAs that are used. So a standard that makes it easier for a CA to be in every browser is good for competition in browsers.
So the CAB forum is legally obliged to ensure it's standard provides a benefit to server operators and end users.
However, let's remember that the point of certificates is security. So the rules have to ensure that TLS is actually secure. This is good for both ends users and server operators. It is a clear benefit.
There will always be a tradeoff between security and other factors. And for an Internet wide standard like CAB Forum, it's really hard to come up with a solution that is perfect for everyone. There are compromises.
Is this proposal the right balance? I don't think so. But I mostly respect the people who are mostly trying their best to make the Internet secure.
If the browser your users are using rejects the SSL certificate, then your users can't get to the site to see your "use a different browser" message. They just see a browser provided error page. (Maybe the browser allows the user to click through to the site, but maybe not. And there will be scary warnings from the browser).
Also, all CAs have to follow CAB Forum rules or face expulsion from every major browser. So if CAB Forum approves this, then your CA will just stop offering long lived certificates from their existing Root Certificates.
Theoretically a CA could create a new root, not trusted by the major browsers, and just the alternative browsers could support it. That wouldn't have to follow the CAB Forum rules. But that doesn't sound like a good business plan to me.
We already use a separate temporary key for each TLS session, negotiated using DSA or ECDSA. So a stolen key doesn't break the security of past connections, only future ones.
We already have OCSP, which would allow the certificate for a stolen key to be revoked. Although it's not possible to actually use, because it is slow and unreliable, and also a privacy problem. Your browser has to ask the CA if the certificate is still valid every time you visit a site, with the response being kept for a couple of days before your browser has to check again.
We already have OCSP Stapling, which no-one uses, but would fix most of the problems with OCSP, at the cost of requiring every old HTTPS server to be updated to support it. The web server gets the OCSP response from the CA and sends it to the web browser. That fixes the privacy problem, and mostly fixes the performance and reliability problems. The response from the HTTPS server is a bit bigger, so slower. And if the OCSP server ever goes down for more than 2 days that would cause an outage.
Shorter certificate lifetimes can be sold as compatible with existing HTTPS servers. But it actually requires extra automation, so it isn't really. It also adds another reliability issue: If the CA stops issuing certificates then websites will go down. At the moment, people renew certs well before they expire, so have plenty of time to fix any issues. With the proposed changes, they would have much less time.
Also, automated systems that can renew certificates, open up the risk of attacks on those systems to get certificates for the attacker.
If we're going to break most existing HTTPS servers, then I'd rather have OCSP Stapling.
> Interestingly, USB doesn’t really help, as you still need to double check wall wart and cable are correctly rated.
In theory, a USB-PD device can check that the wall wart and cable are correctly rated. And either charge slower, or just not turn on. And could indicate that to the user.
In theory. Whether anyone implements that properly in practice is a different question.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
