> Soo ... how sure are we that the memory makers themselves are not going to be the ones holding the bag?
We aren't. The remaining memory manufacturers fear getting caught in a "pork cycle" yet again - that is why there's only the three large ones left anyway.
Surely this can be solved with financial engineering. The memory makers build more capacity, but they finance it with something like floating-rate notes linked to an index of memory prices, or even catastrophe bonds or AT1s. Or more crudely, set up special purpose vehicles to build the extra capacity, and issue convertible bonds from those; if the memory market collapses, investors don't get paid, but they do get a memory factory.
If they don't expand capacity much, the only negative consequences I foresee happening for them is that they might lose spending discipline, and that systems will be set up to make do with a little less memory. Apart from that, it's just very high profits followed by more or less regular profits.
They could wind up losing all their business to China though.
China has memory makers who are creeping up through the stages of production maturity, and once they hit then there's no going back.
If the existing makers can't meet supply such that Chinese exports get their foot in the door, they may find they never get ahead again due to volume - that domestic market is huge so they have scale, and the gaming market isn't going to care because they get anything at the moment, which is all you'll need for enterprise to say "are we really afraid of memory in this business?"
Good point, it's a risk but so far the Chinese competition isn't up to par and it's unclear whether they'll be able to exploit the current window of opportunity.
That however requires significant investments - either each computer gets a powerful GPU for local inference (which cost a fortune) or the school gets a rack worth of compute. Most schools however even struggle to get their children fed.
Another issue is that it forces kids to stay in school for longer to do their homework, which can be a serious problem in rural areas where public transport is limited, so parents are forced to fetch their kids from school which may not be compatible with working hours.
... and one that has quite the merit. A few hours worth of watching Scammer Payback will do that to anyone.
The thing is, wide parts of the population are extremely IT illiterate. The governments didn't act to protect them (say, by threatening the host countries of the scammers aka India in the case of the US or Turkey/Bulgaria/Romania in the case of Europe), so private companies had no other choice.
And hell even the best of us like Brian Krebs can fall victim to attacks [1].
I'm really out of ideas how we can reconcile the needs of the 99% vs the needs of the 1% without making life hell for the other group.
... of course, the EU has the power to get the banks to block those money transfers. Hell, central banks have to be involved in those scams (hopefully/probably unaware). But they CAN shut it down, HARD. They're not doing that, at all.
> so private companies had no other choice.
Because Microsoft has demonstrated how it's done on their platforms? Obviously governments, EU or otherwise, have quite serious tolerance for scams.
> It's true that the lack of multithreading in PHP has been a persistent pain.
That's... not necessarily a bad thing to lack. Entire classes of bugs that are common in Java, C/C++, .NET and other true multi-threaded environments simply cannot exist in the PHP world at all.
If you’re not capable of setting up DMARC correctly then it’s a safe assumption you aren’t capable of adequately securing your email server. Which is even easier to mess up with much higher consequences. Even if you are not intending to be a spammer, if your server gets pwned you will become an unwitting one.
I set up my orgs SPF/DKIM/DMARC (we self host, they have feelings about corporate data sovereignity...) it look about 30 min having never touched them before, and maybe another 15 to write an ansible playbook to rotate the keys.
We do have a _tremendous_ amount of spam fail these checks, as well as a few legitimate organizations.... Some of our peer companies have sent out notices that they will bounce anything that fail these checks in the coming years, and we're probably going to to do the same before too long.
> Reading the matching ntkdriver sources is also where the Novatek link became clear: the tree is stamped throughout with Novatek Microelectronics identifiers, so these ntk* interfaces were not just opaque device names on the TV, but part of the Novatek stack Samsung had shipped.
Lol, a true classic in the embedded world. Some hardware company (it appears these guys make display panel controllers?) ships a piece of hardware, half-asses a barely working driver for it, another company integrates this with a bunch of other crap from other vendors into a BSP, another company uses the hardware and the BSP to create a product and ships it. And often enough the final company doesn't even have an idea about what's going on in the innards of the BSP - as long as it's running their layer of slop UI and it doesn't crash half the time, it's fine, and if it does, it's off to the BSP provider to fix the issues.
But at no stage anywhere is there a security audit, code quality checks or even hardware quality checks involved - part of why BSPs (and embedded product firmwares in general) are full of half-assed code is because often enough the drivers have to work around hardware bugs / quirks somehow that are too late to fix in HW because tens to hundreds of thousands of units have already been produced and the software people are heavily pressured to "make it work or else we gotta write off X million dollars" and "make it work fast because the longer you take, the more money we lose on interest until we can ship the hardware and get paid for it", and if they are particularly unlucky "it MUST work until deadline X because we need to get the products shipped to hit Christmas/Black Friday sales windows or because we need to beat <competitor> in time-to-market, it's mandatory overtime until it works".
And that is how you get exploits so braindead easy that AI models can do the job. What a disgusting world, run to the ground by beancounters.
Yeah, sorry, assumed it was common knowledge. For those out of the loop - a BSP usually consists of a frankensteined mess: a bootloader (often u-boot but sometimes something homebrew), a Linux kernel with a ton of proprietary modules and device-specific hacks to work around HW quirks, basic userspace utilities (often buildroot), some bastardized build tooling building all of that, some solution for firmware upgrades and distribution, and demo programs to prove the hardware actually works.
Most of the BSP is GPL'd software where the final product manufacturer should provide the sources to the general public, but all too often that obligation gets sharted upon, in way too many cases you have to be happy if there are at least credits provided in the user manual or some OSD menu.
> Anyone with a legitimate reason (giving to a friend etc) can work it out even on the day of the event.
I've seen it happen multiple times people couldn't find someone to take the ticket off of them, even for free.
Sure, for an ultra mainstream act the likes of Rammstein? A FC Bayern soccer game? You'll always find some people outside the venue willing to pay in cash for tickets.
It's all about time to market. A BSP with a custom fork of the Linux kernel that barely works can be done concurrent with hardware development.
But if you say as a manufacturer, we'll first get it upstream-supported by Linux and then release the hardware... by the time the quality is good enough for the proper upstream Linux kernel, the hardware is multiple generations outdated.
And often enough, the software side is an afterthought. The BSP teams get thrown the hardware and told to "make it work", which all too often means having to do horrible hacks to the Linux kernel that would be completely unacceptable upstream. Even if they'd hire Greg KH himself, the fundamental problem remains that the BSP teams aren't asked if the HW designers can make the life of the BSP team easier.
The one notable exception to this unholy mess, however, is Apple. And that is why Apple hardware seamlessly integrates within the ecosystem, why it is so performant and why it is so energy efficient.
> Basic hygiene security hygiene pretty much removes ransomware as a threat.
It does not. The problem is, as long as there are people employed in a company, there will be people being too trustful and executing malware, not to mention AI agents. And even if you'd assume people and AI agents were perfect, there's all the auto updaters these days that regularly get compromised because they are such juicy targets.
And no, backups aren't the solution either, they only limit the scope of lost data.
In the end the flaw is fundamental to all major desktop OS'es - neither Windows, Linux nor macOS meaningfully limit the access scope of code running natively on the filesystem. Everything in the user's home directory and all mounted network shares where the user has write permissions bar a few specially protected files/folders is fair game for any malware achieving local code execution.
AFAIK the idea is to have backups so good, that restoring them is just a minor inconvenience. Then you can just discard encrypted/infected data and move on with your business. Of course that's harder to achieve in practice.
If the important data is in a web app and the Windows PC is effectively a thin client, this lowers the ransom value of the local drive. Of course business disruption in the form of downtime, overtime IT labor cannot be mitigated by just putting everything online.
The next step is just to move to security by design operating systems like ChromeOS where the user is not allowed to run any non-approved executables.
If tricking a single employee can cause an entire company to stall out, it's a process issue. Just like how a single employee should not be able to wire out $100,000.
Getting rid of Windows in favor of an OS with a proper application sandbox like Android would solve so, so many security issues, but that's not viable in most cases because so much software depends on the outdated user-based permissions model most desktop OSs are built around.
Please don't. It's bad enough that companies running windows have all the data on win premises. Dumbing down what the users can do with their machines seems like the end of personal computing.
I don't think Android is "dumber" or less capable than Windows. In many ways the application sandbox actually gives owners a lot more control over their devices than a less locked down OS would, allowing them to restrict what information installed applications are allowed to access.
But what I think you're concerned about (and I agree) is that the flip side of that is that giving device owners more control over their apps also gives the OS developers more control, and Google's interests are not always perfectly aligned with the device owner's. There's a much wider market for apps than there is for operating systems, so sometimes app developers' interests will actually be better aligned with the device owner's than the OS developer's interests are.
One possible saving grace here is AOSP. In theory you could have multiple competing AOSP-based desktop OSs, each catering to a slightly different set of users. This would be close to the ideal situation in my opinion. Either that or Chrome, Firefox, Edge, and Ladybird all evolve into full fledged OSs with WASM-based apps.
I see your point, I do. It seems like all external software is going in the SaaS direction, where the vendor is keeping all of the data, so they are available over an API. So there are genuinely solid cases for Chromebooks.
The issue is how much power this gives to the vendors. I think we should be able to survive a vendor going poof, taking all our data with them. Having a general computing platform capable of mixing files and privileges seems to me like the only way of keeping this capability.
Sleeper agent malware is a thing especially in high risk situations. If somebody has a dormant RAT installed since year X-1 it’s going to be impossible to solve that in year X by using backups
That does not work. They just infect you and do not demand a ransom for a few months as they encrypt all your data going to the backup. Now your backups are also encrypted going back multiple months and you have to discard months of work.
Modern ransomware are not just encrypting data but uploading them somewhere too, the victim is then threatened with a leak of the data. A backup does not save you from that.
Well yes, if you get breached, you have problems. At least in good backups scenario you can continue to operate, so you have money incoming to fix this.
> all mounted network shares where the user has write permissions
This is very literally what 'basic hygiene prevents these problems' addresses. Ransomeware attacks have shown time and again that they way they were able to spread was highly over-permissioned users and services because that's the easy way to get someone to stop complaining that they can't do their job.
Basic security hygiene in the modern world is "assume your employees can be a threat", either because they're incompetent ("I accidentally deleted the shared spreadsheet, I thought it was my copy"), malevolent ("I will show them all!") or compromised ("I clicked a link in my email and now my computer is slow.")
If you aren't designing your systems to be robust against insider threats, they will fail.
(If you design them to be robust against insider threats, they will probably also fail, so you have to be constantly working to understand how to limit the consequences of any individual failure.)
Yes it does. A little bit of application control, network segmentation and credential hygiene (including phishing resistant MFA) go a long way.
> The problem is, as long as there are people employed in a company, there will be people being too trustful and executing malware,
Why are you letting employees execute arbitrary software in the first place? Application allowlisting, particularly on Windows is a well solved problem.
> not to mention AI agents.
Now this is possible only through criminal incompetence.
> And even if you'd assume people and AI agents were perfect, there's all the auto updaters these days that regularly get compromised because they are such juicy targets.
Relatively rare, likely to be caught by publisher rules in application control and even if not, if the compromise of a handful of endpoints can take down the entire business then you have some serious, systemic problems to solve.
> And no, backups aren't the solution either, they only limit the scope of lost data.
In the end the flaw is fundamental to all major desktop OS'es - neither Windows, Linux nor macOS meaningfully limit the access scope of code running natively on the filesystem. Everything in the user's home directory and all mounted network shares where the user has write permissions bar a few specially protected files/folders is fair game for any malware achieving local code execution.
Why are you giving individual employees such broad access to so many file shares in the first place? We’re in basic hygiene territory again.
> Return to traditional degrees, get rid of the boutique majors and things that belong in job training centers.
But who is gonna pay for these? (half-/s)
Reality is, employers don't want to pay the bill for job training centers or for German-style apprenticeship education. Universities aka degree mills are what keeps most large employers afloat - depending on the system, it's either the talent themselves (US via student loans), the government itself (Germany) or a mixture of both paying the bills, while employers get fresh trained talent without paying a dime.
We aren't. The remaining memory manufacturers fear getting caught in a "pork cycle" yet again - that is why there's only the three large ones left anyway.
reply