There is fairly new Zeiss camera that implemented the whole "camera OS" with Android and even included mobile Lightroom editing capabilities. I guess it's as close as it gets right now.
My theory is that the main Japanese companies are extremely conservative and they don't pick up such changes easily - see how Canon and Nikon completely missed mirrorless and suffered huge market loss to Sony.
Most image processing has to do with imitating full frame sensors (better low light photography, DOF, etc.) So I'm not sure if full frame/APSC/Med-format cameras need the same image processing that camera phones have. Also, most people who use the bigger sensor cameras are probably pros. Most of them would prefer a "blank slate" and use RAWs.
Camera phones have significantly better processing than newer full frame cameras at this point; obviously they can't take the same pictures, but full frame cameras can't do HDR, noise stacking, night mode etc very well. You can do it by hand by shooting raws and editing them together but it's inconvenient. The autofocus is also more advanced in iPhones with lidar.
I assume part of this is that the camera companies are Japanese and refuse to pay any engineers more than $20k a year.
My Olympus does in-body HDR, noise reduction with stacking, low-light handheld with sensor stabilization, and more. It's not "full-frame" but full-frame is a meaningless condescension from the 35mm crowd.
Besides that, the main problem with the processing in those cameras is they don't do it to RAW, only to 8-bit JPG, so nothing for HDR displays. iPhone can do fused RAW, 10-bit HEIC, and takes HDR photos and has an HDR display to show them.
yes, but perhaps this is because of other things? Like that a person is going to have their phone with them anyway? Even if a phone camera is only 1/2 as good as a consumer camera, the ease of use and convenience is going to win the 99% of the market which doesn't care about 'professional grade' results. And the 1% that does care is going to buy a SLR.
Not better tech (better as in takes better photos), rather more convenient tech which is good enough.
Good enough for most people's point-and-shoot, but a smartphone camera is by no means competitive for anything beyond that. Hobby photography is fairly common too, and most people won't be using smartphones for that.
One of very important reasons why FreeBSD haven't incorporated the patches from HardenedBSD was that their code quality was disputed and historically the author had issues with undergoing reviews and applying requested changes. HardenedBSD may do a very good job for the PR about their "superior security" but one may wonder if a system without badly implemented feature isn't more secure than the one with it.
> the author had issues with undergoing reviews and applying requested changes.
Does this mean the author would send code for review and never actually action the change requests? Or was it more they sent patches and expectecd them to just be merged?
You need to be aware that while pledge is a security technology, linux containers aren't. Pledge was designed as another security layer, while containers were designed as "management" or "separation" layer, but not strictly as security measure - read up on how bad is to run things as a root in a container.
Just for accuracy, they were actually recognised as "workers"[0], which is a different formal employment status to "employees"[1] and doesn't confer the full set of employment rights in law. Worker status does come with the rights to minimum wages, breaks and holiday pay, though, so it's still a reasonable concern that if/when Deliveroo riders are granted the same status it will increase the company's operating costs considerably.
So far all the courts in the Netherlands have done the same for deliveroo employees (no longer gig workers). They keep appealing and losing so we have to wait another year or so for the final verdict.
Uber drivers need to be allowed to set their own prices, but stay contractors, imo. The UK is different to the US in that you don't need health insurance, so the employee distinction is less expensive of a change.
> Uber drivers need to be allowed to set their own prices
Yikes this seems terrible for the drivers. There would be a race to the bottom surely with the most desperate drivers who perhaps just need to make a mortgage payment today undercutting everyone else.
The same laws of supply and demand also explain the price of employee labour, no? The big question is whether one price beats flexible pricing. It's not obvious that having a single price for all Uber drivers would benefit everybody, presumably it would have deadweight costs by pricing some drivers out of the market.
The difference is most people aren't providing their labour with a pricing model this dynamic.
If I look for Ubers and one is offering rides for 50p I'd take it, because the result should be the same as anyone else offering something more expensive and I have no relationship with my Uber driver.
If a gardener stats to offer gardening services for 50p an hour I wouldn't go with that, because I have a relationship with my existing gardener and I'm suspicious how quality someone can be for 50p an hour.
I see your point. It sounds as if you agree that in Uber's case, flexible pricing is appropriate. Or do you think that Uber should price its cabs flexibly but pay a flat rate to its drivers?
The implementation I have seen is that there is a minimum price, but drivers can set higher prices, if they like. (Which in reality means that they can't set the price at all)
A large company like Uber is going to be relatively stable in terms of cash-flow, access to credit, etc day-to-day. If they do sell under cost it's usually part of a longer-term plan.
An individual driver may have a loan-shark threatening to break their fingers for a repayment that day.
I think individuals are going to be much more volatile and so create a worse race to the bottom.
Maybe let drivers set a price above a floor? Could be like their own surge pricing.
No, it doesn't and this is where an initially "superior" technology (Jails existed years ago, I was using them at least 15 years back in time) gets overrun by "inferior" tech (Linux containers), because the latter gets a user oriented tooling, packaging and so on (no flame war intended at all). Now the Linux container is much more "superior" as it catch'd up and exceeded Jails in many areas, especially user oriented readiness and integration.
And FreeBSD Jails are still superior in the way they're a "first class citizen" in the kernel, vs. the "hacky" feel that Linux containers has.
I have no doubt that Linux containers are just as secure as FreeBSD Jails, but if the implementation and tooling is complex, there is a much higher risk of something being configured wrong.
And then there's the giant gorilla in the room, Docker, which probably has the best tooling of them all, and initially used Linux containers, but has since moved on to their own container implementation (runC, https://www.docker.com/blog/runc/).
I wouldn't be so hasty in saying that Jails implementation doesn't suffer either - there are dragons there too, it wasn't all just designed and written in one go, there are layers upon layers and it is not all pink and unicorns as it perhaps initially was ;)
RunC isn't "their own implementation" but rather an OCI (Open Containers Initiative) standard that world seems to be adopting and I wish FreeBSD Jails would be a part of it.
Jails has their share of problems, all i was saying is that when the tooling and implementation is complex, the risk of doing "something wrong" is bigger. ;)
I really like how jails get stuff like their own IP address and more. Indeed it seems like the underlying tech is superior. But your point is on target too, the tooling has brought the dev experience to the front with docker.
Actually, you don't need another copy of userland. You merely need a dedicated space for the jailed OS (assuming we're talking OS-style jails, not process-style ones) to write the things OS writes to (devices, logs, etc.). You could get away with null mounting your host filesystem and then mounting writeable space on top of it. Once I've had read-only mounts for my jails, for funsies.
While I agree it's easy in hindsight, you're not comparing apples to oranges here: comparing the comment author to a person running a business, with very high expertise in particular subject (chip making) and general subject (technology), having access to information not accessible to others (Apple plans and visions about the product, tech specs required, price asked, etc.) is not even close to being the same thing. I can see how a much better decision could be made very realistically given that expertise and information no one else had and yet the worst possible was made.
I've experienced something like that as well. Depending on what you can do, try a different monitor and/or different cable and/or different dongle. I've managed to find a combination that doesn't do that anymore.
I have my problem with OWC TB3 dock and Dell P2715Q. I will try an older dock that I have in the office (Kanex TB2 Express; as the name says, it is TB2, thus extra dongle needed); but playing around with different TB docks can get expensive...
I use a Dell XPS 13 with 3 external monitors via a Dell TB16 dock (which uses external power). I wonder if that setting solves these M1 issues (via the extra power) or not. I understand CalDigit docks also have external power but don't know if there can be a subtle difference.
The OWC TB3 dock I'm using is also powered externally. Docks by CalDigit are different docks than OWC, but I think they are all using the same chipset underneath.
It also does not happen with Intel Macs, which use Intel TB implementation. With M1, the TB is brand new, so some issues are to be expected. I suspect that with sleep and wakeup, there is some state mixup with previous link training, so it doesn't talk to other side the way the other side expects. This might be - or might be not - fixed with firmware updates.
