I think it depends. Encrypted filesystems typically encrypt contents of each file separately - that way you don't need to read / write the whole disk to read it write any individual file contents. Of course that means metadata may be in plain text or may be separately encrypted - again possibly folder by folder instead of all metadata at once. Exact details would vary with different file system encryption schemes.
Whereas if you image the disk and encrypt the image properly, that gives you all the great confidentially guarantees but no random access.
> Encrypted filesystems typically encrypt contents of each file separately - that way you don't need to read / write the whole disk to read it write any individual file contents.
Ah, that's not true of "full disk encryption". It usually encrypts the disk blocks.
File-based encryption is stronger; you can use different protection classes on different files, you can use authenticated encryption, etc. iOS does it this way and I assume other systems have caught up, but don't know any in particular.
While the unauthorized sites potentially deliver poor customer service and (the appearance of) higher prices, potentially driving away customers? Who do you know that comparison shops all the different ways to order from the same restaurant?
Price shouldn't be the only thing the restaurants care about.
Any idea what those are exactly? Does it only work for recipients on teams with SSO? Or is this just gating who can start these supposedly e2e encrypted email threads?
Looks like recipients can be anyone but would be forced to create a guest account if they don't have one. Which sounds like Google meditating key exchange? Which isn't really e2e encryption at least for the initial message.
Huh, I played on mobile and move and jump were exclusive afaict in the touch controls. I climbed up a fire escape and almost got on top of a building but couldn't make the last step to get up there. Maybe I'll have to try on desktop.
It's perfect on the almost square-ish main screen of a foldable.
In fact, it's the best looking game experience on a foldable I've seen so far (most games are designed for either mobile or tablet form factor, and can't quite handle the in-between). And it's cool how you can just fold or unfold the device on the fly, and the game just adapts without anything more noticeable than the camera pivoting a bit if needed to keep the character on-screen. No stutter, no half-second pause for UI to realign, not even perspective change.
EDIT: I just realized it's probably not a mobile-specific thing, and sure enough, on a desktop you can just resize your browser window to see this.
An IPO means selling a whole bunch of people, whereas fundraising rounds pre-IPO mean courting a small number of large investors. I think it's partly a sign of the times that there's enough concentrated capital that you can get enough money from private hands to not need to go the IPO route yet.
The private market is getting out of hand, then. I think it makes sense for private companies beyond a certain size to have the same reporting requirements that listed ones do. At these valuations the private market for startups is becoming systemically important.
To some degree, they do -- under SEC rules (Exchange Act §12(g)), private companies with >$10M in assets and 2,000+ shareholders (or 500+ non-accredited investors) have to start public-style reporting.
I assume there's some clever accounting to ensure they're not at the 2,000 shareholder cap (perhaps double-trigger RSUs don't count as being a shareholder yet?)
So one effect I've seen over the last decade of working: if it never needs to change, and no one is adding features, then no one works on it. If no one works on it, and people quit / change teams / etc, eventually the team tasked with maintaining it doesn't know how it works. At which point they may not be suited to maintaining it anymore.
This effect gets accelerated when teams or individuals make their code more magical or even just more different than other code at the company, which makes it harder for new maintainers to step in. Add to this that not all code has all the test coverage and monitoring it should... It shouldn't be too surprising there's always some incentives to kill, change, or otherwise stop supporting what we shipped 5 years ago.
That's probably true, but you're describing incentives and social dynamics, not a technological problem. I notice that every other kind of infrastructure in my life that I depend upon is maintained by qualified teams, sometimes for decades, who aren't incentivized to rebuild the thing every six months.
If you're asking why software has more frequent rebuild cycles than, say, buildings, or roads, or plumbing, it's because it's way cheaper and easier, can be distributed at scale for ~free (compared to road designs which necessarily have to be backward compatible since you can't very well replace every intersection in a city simultaneously), and for all the computerification of the modern world, is largely less essential and less painful to get wrong than your average bridge or bus.
It's like the difference between building a Bird house, Dog house, people house, mansion, large building and a sky scraper... it's different levels of planning, preparation and logistics involved. A lot of software can (or at least should) be done at the bird or dog house level... pretty easy to replace.
For roads, brushes, wastewater, sewer, electricity - it's because these things are public utilities and ultimately there is accountability - from local government at least - that some of these things need to happen, and money is set aside specifically for it. An engineer can inspect a bridge and find cracks. They can inspect a water pipe and find rust or leaks.
It's much harder to see software showing lines of wear and tear, because most software problems are hard to observe and buried in the realities of Turing completeness making it hard to actually guarantee there aren't bugs; software is often easy to dismiss as good enough until it starts completely failing us.
A bridge is done when all the parts are in place and connected together. Much software is never really done because
- it's rare to pay until we have nothing more to refactor
- the software can only be as done as the requirements are detailed; if new details come to light or worse, change entirely, the software that previously looked done may not be. That would be insane for a bridge or road.
Maybe it's a documentation problem? It seems to me that for a piece of software to be considered good, one has to be able to grok how it works internally without having written it.
Not per Naur, in his seminal "Programming as Theory Building" he claims that documentation doesn't replace the mental model that he original authors had developed: https://pages.cs.wisc.edu/~remzi/Naur.pdf
I think something to keep in mind, the US hasn't fought a war on the home front since 1865. The Spanish American war, WWI and WWII, Vietnam, Korea, the Gulf war, Afghanistan, Iraq - none of these were fought on American soil, with the exception of Pearl harbor, which was a navy base, not a major manufacturing site. So we haven't really had to reckon with what happens if our homeland is under fire - sure, we drilled for it during WWII, worrying about Nazi bombers and Japanese sabotage but neither actually happened.
It doesn't look like our wars are going to get closer anytime soon, but modern planes and rocketry have much greater range than in the 1940s the last time we were at war with countries with significant resources. If we ever come head to head with China, their missile capabilities could be a real concern.
Whereas if you image the disk and encrypt the image properly, that gives you all the great confidentially guarantees but no random access.