Yes, I got the 13" M4 Pro mostly because of the display. I use the iPad Pro as my photo album and its just fantastic for that. The M4 flies of course. Thanks to more and more multi-windowed support on iPad OS it gets more useful for light tasks.
Is that so? Or isn't it that being the CEO of such a large and well-known company is basically always career enhancing? In my experience, with companies hiring for high-level positions, former job titles are valued often more than actual performance.
Right. But as long as touch is the main interface to you tablet, at least the desktop UI should be designed for that. So in my eyes it totally makes sense not just to use plain MacOS for the iPad.
Another item is that so far they resist giving users full control over their iPad.
Yes and no. What they are currently doing, and it is working out greatly, is having a single hardware platform and a common code base on all devices. They still have branches of the main OS body for each device with the device specific customization. Which absolutely makes sense. Macs don't have touch. But iPads have. Which has at least some differentiation in the desktop UI. Then they try to keep up strong limitations on what iPad software can do - probably to a large extend to keep the lucrative app store alive. And of course, TV OS looks quite different for obvious reasons.
Reading this makes me so happy! Even if it by itself might not be the biggest science news, we know about antimatter for a long time and we are still talking about a few atoms only, but the news that people are actually handling antimatter to the point of transporting it with a truck, just feels a bit like sci-fi actually happening.
That is exactly how it is and it makes the whole article completely pointless. Especially as the article in the second sentence correctly writes "1920 pixels wide".
If a camera company sells me a camera, I consider it a definite disadvantage, if I cannot open the Raw files until the software companies have updated their products. This is also a great way of forcing customers into the subscription models like Adobe offers.
So as a customer, I do criticize that they don't support more open formats.
The ironic part is, that basically all the closed-source photo-editing software (and of course all open-source) are just using the open source LibRaw. Any special features as color profiles comes on top of that. So yes, the camera manufacturers could just donate to LibRaw or just use DNG instead.
Well, it is obvious that between a RAW file and the final image there are a lot of complex processing steps. But that is independent of the file format used. DNG isn't so much different, just documented. And while the manufacturers converter might give the best results, the photographers rather use the image processing programs from Adobe or their competition which use their own RAW converters anyway.
Not forever. But 75 years after the death of the creator by current international agreement. I definitely think that the exact terms of copyright should be revisited - a lot of usages should be allowed like 50 years of publishing a piece of work. But that needs to be agreed upon and converted into law. Till then, one should expect everyone, especially large corporations, to stick to the law.
I think it is already as narrow as you can put 2 seats side by side. But then indeed it becomes a tradeoff between size and efficiency. They went for maximum efficiency. And it is still 26cm shorter than a Model 3. So while not an compact car, not overly large either.
Because it needs to be that long to have a low air resistance. There are two determining factors for air resistance. First, the cross section A, which determines the amount of air to be moved and second the drag coefficient c, which describes how well the air flows around an object. This gets lower the more "round" a shape is, but the sphere isn't actually the best one, you want the form of a falling raindrop. For that the shape needs to be quite a bit longer than it is wide. So if your car is e.g. 2m across, it needs to be something like 4m long to approach best efficiency. See also the empty "tails" attached to some racing cars for drag reduction.
It is the only sane way to handle things like this and I think it is the reason air travel is so secure that most regulations and practices make sense.
You want the crew to be fully in charge of security. If they think the plane should turn around, it turns around. In the long term it is way cheaper to eat those costs then to start a whole industry about litigation for events like these, probably causing everyone to buy additional insurance etc.
You definitely don't want to give any incentive to anyone to "overlook" possible problems.
Why would you want to store enough energy to supply for a whole winter? Wind energy delivers most power during the winter and even solar contributes a bit. The actual amounts to store would be a fraction of that. Of course, that might be the one single good use of hydrogen as a means of storage, but way less storage is needed than most would think.
While having to declare the interfaces a type implements can increase the readability, it comes with a huge drawback: you are limited to implementing the interfaces considered when writing the code. In my eyes it is a fascinating and important feature that you can add interfaces and all existing types automatically implement them, if they, by their methods signature, implement them. You don't have to edit their type declarations to do that.
Ok, thanks, finally found the source of transpose. That uses unsafe. Which of course means, all guarantees of safety are off. I am not sure why the usage of unsafe is necessary here, but one way or the other, safety now is in the hand of the programmer.
My point rather was: wherever you don't use unsafe, you are protected by the compiler from certain errors. Which I consider extremely important, that is why I am a strong proponent of memory-safe languages.
Now, if there is a question whether Rust requires you to use unsafe to often, that would be a valid technical critique of Rust, but that didn't seem to drive the Linux discussion.
It is trivial to audit the usage of "unsafe". Grep does this. Of course auditing the unsafe functions is another thing. But you can have large codebases without unsafe and consequently a lot of less work with auditing your code.
I don't have personal experience with Rust, but quite a bit with Go. It is almost ridiculous, how much more safe Go is in comparison with C. So yes, it is worth every bit.
Is that so? How large parts of the Rust kernel drivers in existence are inside unsafe blocks?
Yes, unsafe, as the name says, allows unsafe parts. But it is trivial to audit code for the usage of unsafe. Which means, everything else isn't. And it is there where the most common mistakes are made.
Not everything might be better, but most things would be more secure and stable in shorter time for sure, when using Rust or any other suitable language which e.g. guarantees memory safety and general correctness. It just looks as Rust is the most promising and also the best fitting candidate for this. Also, I have heard just good things about the experience using Rust for Linux drivers.
So the Linux project is now at a point where long-term decisions need to be made. The Rust integration requires the next step, one maintainer tries to block that entirely. This has to be resolved in one way or the other with the corresponding consequences.
Or worse: Linux is so widespread and managed to practically kill most Unix alternatives, that progress in OS development is slowed down globally. I would strongly prefer Linux being an OS with a lot of progress to stagnation and possible no alternative in the next decades.
I think initially Linus stance of encouraging Rust drivers as an experiment to see how they turn out was a right decisions. There should be some experience before doing long term commitments to a new technology.
But since then a lot of experience was made and I got the notion that the Rust drivers were quite a success.
And now we are at a point where proceeding further does need a decision by Linus, especially as one of the kernel maintainers is actively blocking further work.
That is a fallacy. No one has claimed that Rust magically prevents you from getting owned. Quite to the contrary: there is no magic in preventing most, if not all memory handling errors. Which are the most common reason for security problems. Removing one category of errors entirely would free a lot of resources to deal with the remaining ones.
Well, while Hector had a long history of frustrations with working with kernel development, the project of integrating rust drivers in the kernel has reached a cross-roads. Either to take the next steps or effectively close the door of the kernel progressing further with C and all the debt it brings.
From what I saw, the project of writing the graphic drivers for ARM Macs was quite a success, so the door for those projects shouldn't be closed.
Have you seen the "Ultra" versions of the Apple Silicon? They are gigantic chips. And many other competitors make server-class ARM based processors, so having a chiplet architecture as part of the ecosystem makes a lot of sense.
And I was trying to make the point that it already is a pressing problem for any woman living in those states and of course any male who feels attached to them. Because medical support for women of any age is strongly decreasing.
The problem is, even when there is never the plan of having an abortion, healthcare support for women suffers greatly from the abortion plans. Because it gets legally problematic for doctors to provide healthcare for women. Sooner or later you will have a patient with a medical emergency during a pregnancy. There are already enough incidents where critical ill women don't get medical treatment because they also are pregnant.
I can't say it from first hand experience, but usually that are just example stats. The limit usually is pixels/sec for the bandwidth, so any configuration which requires less bandwidth should work too.