laurowyn

Well no, not really.

Fuel (or really, oil) is a single commodity that everybody is after. If the price is low, and you're anticipating a shortage in the near future, you can buy now and sell later for a higher price. That's as simple as a market can get. buy low, sell high, whilst gambling on future price rises.

However, ICs are not a single commodity - you can't take whatever the foundry is putting out and slam it in place of whatever you actually needed. Each circuit is specific to its application. Sure, you could take a similar chip and rework your product to use the new chip instead of the old, but that isn't how a foundry works. They sell capacity.

Each company that wants their chips made will (or should) have done their forecasting for demand in the short-medium term. The problem is that those term limits have lapsed at a time when manufacturing is in a crunch. So now everybody needs new chips made, and nobody has the capacity to make them all.

Those that can rework their products to use similar chips that are already available should be doing so to maintain business. Those that can't do that, or are unwilling to do that, are paying through the nose to pay off other foundry customers to take their slots. meanwhile, there aren't enough chips to continue product manufacturing, so that's on hold until the new chips come out of the foundry and then everything can resume.

Prices will rise to cover the lull in production. And then businesses will see that people are willing to pay that amount, and so prices will not go back down.

If that isn't a more complicated financial market than oil, then I have no idea what is.

Any idea why Bitwarden insist on their installation ID generation for self hosted deployments? it strikes me as unusual, as it's not documented WHY it's necessary, or what the ID is used for, only that you're required to give Bitwarden your email address to get the necessary ID.

If they would remove this step, or at the very least explain it, I'd be more likely to deploy and use it. Critical things like password managers should be self hosted where possible, IMO, and this is a blocker preventing trivial deployments.

Is forcibly breaking away from the content you want to watch every 10 minutes to show ads not distracting? or the 2 minutes of repeated content from before the break to remind you what was happening before you got distracted by the ads not also distracting? Have you ever watched a show with the ads removed and seen how much of it is actually repeated just because of ad placements?

Just because it's not on screen the entire time doesn't mean it isn't a distraction. TV ad breaks are one of the best methods for producers - guaranteed impressions, broad audiences, official metrics, etc. - whilst also being the worst for consumers. An hour of my time set aside for watching something I enjoy now contains 20 minutes of content I don't care about at all, and cannot skip/bypass if not interested, and the 40 minutes of content is closer to 30 because of repeated content either side of ad breaks.

This is pretty well documented in business law. former employee transfers to competitor, takes clientele with them.

https://www.acumenbusinesslaw.co.uk/2018/07/23/a-former-empl...

"protection" would include deleting once no longer required, does it not? Can't lose something you don't have in the first place.

Is not using the shipping address for any other reason than shipping an order really that much more effort?

Sure, protecting that information is more effort, but you should be doing that already, right? not just from a GDPR perspective but a business perspective too - if a competitor can get a list of all your clients and send them brochures with 10% discount on your prices, you'll close down pretty quick.

5G is the next generation of mobile connectivity. I can't list all of the detailed changes off the top of my head, but some of the biggest changes I'm aware of are;

The use of a different radio band, therefore less contention in the existing mobile bands - less congestion results in better speeds overall.

Reducing the range of base stations. shorter range means less clients, less congestion and therefore better speeds, whilst also deploying them more densely to cope with wider areas and higher bandwidth densities. Also, shorter range reduces the power requirements, meaning mobile devices will have longer battery life (nothing magical, probably not even noticeable to the average user), or it can be built into smaller/low power devices such as IoT.

Utimately, 5G is irrelevant to end users until it's actually deployed widely. Just like 3G and 4G, the end user has no impact on the deployment of the network other than the demand for it. So, all the hype around 5G is almost entirely marketing, politics etc. It only really matters once 5G is deployed across the areas you visit daily, and until then the previous generations of mobile connectivity will continue to serve just fine.

Your suggestion about a football stadium is an interesting test case. Ideally, an area that size would be served by up to a dozen base stations, spread throughout the stadium. Compare this with a single 3G base station that would cover the stadium, plus a large portion of the local area, and you can see the pros/cons fairly easily. But how many people are surfing the web whilst watching a game? or taking calls, answering texts etc. Very few during active play time, but there'll be large bursts of traffic in any breaks in play which will stress the older mobile generations to breaking point whereas 5G is designed to deal with that scenario fairly well.

Absolutely.

Meanwhile, we live in a world where VPNs are sold to the casual user while critical systems are left on internet facing networks.

I've never understood why, if these critical systems need remote access, it's not all done through a VPN of some sort. VPNs are not infallible, but it significantly increases the bar for entry from script kiddie to nation state real quick (depending on choice of crypt), while choosing a well supported implementation ensures long term bug fixes and security patches.

Because it's a public server, which means Discord feel it reflects on them as a business to be hosting hostile communities.

You can say whatever you want in a closed, private discord group. Discord isn't going to care if it's a server with a dozen users who are all close friends. It's when you go posting invite links everywhere and get a community in the thousands that Discord start taking an interest and enforcing their brand protection.

Whilst it's DRM free, it's still licensed copyrighted content that cannot be shared unless the license permits. BandCamp's terms of use state that they take non-exclusive rights to sell and distribute works on your behalf, but they do not grant those same rates to buyers.

DRM is not Licensing, but a mechanism to enforce a license.

I think OP is implying that the sharing provided in funkwhale is likely violating the typical license terms of any purchased music, therefore is preventing a musician from making money from streaming services which have appropriately licensed the music for streaming.

Buying a license doesn't mean that you own the work, just that you have the right to play it in specific circumstances (most of which nobody pays attention to anyway). I'm sure we've all played a song on a loud speaker for others to hear, but again that's against typical license terms.

Yes, but I don't need the store to be online and supported to access my physical copy of an offline game. At least there's a chance I can continue playing if/when the store gets taken down.

Look at every retro console - their games still work on their platforms, and there's a second hand market for games. It's a shame they're no longer made, but at least there's a physical copy that can be traded instead of a digital copy DRM'd to an account on a store that's no longer operational.

Except I don't need the console's digital store to be online and active to be able to play a physical copy of an offline game.

Agreed, it's not a perfect system, but it's not exactly the same as the Apple app store - the only way to get software on to iOS for the longest time (recently, side loading has become easier and less gatekept, but still not the same as the desktop experience).

I feel like that's an interesting approach though. My PS4 sits idle most of the time, the rest of the time it's playing a bluray movie. only fractionally ever playing a game on it nowadays.

I guess the sales numbers will tell the bigger story.

Absolutely, not saying it's a perfect system. But at least I can go to GameStop, or even Amazon (lol), and buy a physical copy instead of having to go to the console specific digital store to buy and download it. At least if the digital store shuts down, and/or the console goes out of support, I still have a physical copy of the game I can play.

Physical vs Digital is a whole nother holy war though.

I feel like that falls under "changes between versions".

Agreed, it's not as bad as it used to be. Android needed developer mode, iOS needed the device to be registered as a test device.

At least with a console you have the option of buying a physical copy of the game and loading it onto the device, compared to mobile where you need to enable developer mode in order to load apps from alternate sources (and even then, it's not an officially supported method as the steps can change significantly between versions).

But I do agree that there will be a console war if this is continued. I would hope that it leads down the "I own this device" route and level the playing field in general - I've paid Microsoft, Nintendo or Sony the money for the device, therefore I should have the right to run whatever I want on it. Gatekeeping what can be run on a device is a significant problem that needs to be resolved, along with the right to repair (Apple's a good example of the problems) and the second hand market (Tesla is a good example of the problems).

And when they declare bankruptcy because they can't pay back the loan with interest?

Payment upon delivery is how most business-to-business purchases work. You agree a cost, deliver the item, then get paid. Being paid before delivery gives no incentive to deliver what was requested.

yes.

> when you cannot handle the error in the current code block and the function interface does not support returning enough information to the caller to detail what went wrong

Exceptions are, fundamentally, an alternate way to return from a function. That's why the general practice is to avoid using them for control flow - there's enough in the language already to support what you want to do, we don't need to instrument the entire stack when I could return a negative value to indicate the error.

The engineering problem to solve is deciding when to turn a void return into a boolean or enum. Just because there is space in the interface for an error code, doesn't mean it's the right choice. But likewise, just because exceptions are available, doesn't mean every error should be thrown.

Interesting corner case that I can't say I've ever seen before.

fstream is a bit of a mess. Even the documentation for close is a bit contradictory. Its exception safety states that an exception is caught and rethrown after closing the file if one is thrown by an internal operation. That to me sounds like the actual resource being managed will be closed (assuming the fd is valid), but any data may not be flushed out of the write buffer.

sounds to me like iostream needs some serious attention in future specs, but that's unlikely to happen unfortunately. Creating new toys > fixing old ones.

I think there's a lot of merit to this post, but it really shows its age. Modern C++ typically suffers from only the last point raised - exceptions during destruction, but that goes against the all good C++ practices.

Overall, the author's approach to exception use is flawed. It's bad form to use exceptions for code flow purposes, as per their example. If you throw an exception in the same block that catches the exception, you've wasted a whole lot of time doing something an IF-statement could solve trivially.

All projects that I have worked on that use C++ has declared that exceptions should be used in exceptional circumstances only - that is, when you cannot handle the error in the current code block and the function interface does not support returning enough information to the caller to detail what went wrong. An exception is more than just throwing your hands in the air and saying "I can't do that" - it has context, purpose, history. Getting rid of exceptions breaks some of the fundamental design concepts of the language.

2-step initialisation is the only way around errors during construction whilst forbidding exceptions. But 2-step init breaks a fundamental rule of RAII - the constructor acquires the resource and establishes all class invariants or throws an exception if that cannot be done. If the constructor is not allowed to throw exceptions, as per the language's standardised interface for constructors, then my library or application needs to be modified to support whatever process a third party library has defined as appropriate. There is a wide surface for bugs to creep in, let alone costing me time, money and effort in supporting whatever interface they've come up with.

If an object has been constructed, it should be in a valid state unless an exception has been thrown, in which case I'm told what went wrong. If I can fix it before the stack is fully unwound, I can save the day. but if there's nothing I can do, the exception has to roll to the top as that's the only other option. That then begs the question; should I catch all exceptions at the top level and prevent crashing, or should I crash and allow whatever system I'm running under to restart me? That depends on the project, but typically I'd let it go. systemd should bring me back, docker should restart me, kubernetes should restart my pod, etc etc. If I focus on what is within my control, and delegate everything else, the system will be cleaner and much more maintainable.

I've never come across a situation where exceptions during destruction is a problem, but am very interested in any examples. C++ standards define that you _can_ throw exceptions, but you shouldn't for the exact reason raised in the article - the process will be terminated as there's nothing else that can be done. If there aren't any destructors containing the throw keyword, it's not likely to throw an exception - OOM or other system exceptions are still possible, but why are you allocating memory in a destructor? destructors just need to release resources and clear down the object, it shouldn't be requesting more resources. Thinking about saving the object state before exit? wrong place to do it.