eyesee
eyesee on Hacker News
Reminds me of an app I built ~20 years ago now.
We wanted a cross-platform C++ layer and native Cocoa front end. Objective C++ wasn’t a thing then, and having built a plain C shim previously I didn’t want to repeat the experience.
We built our own bridge by registering our C++ classes with the Obj-C runtime, generating selectors for all the methods so you could send messages to (carefully constructed) C++ objects using Obj-C syntax, or even subclass from C++ to Obj-C.
It was a pretty neat trick, but would’ve been difficult to port to the Obj-C 2 runtime.
MacBooks don’t ship with OLED displays, only micro LED (“XDR”) displays which shouldn’t be susceptible. iPhones however do have OLED displays.
The problem is that you’re always at a sensor deficit because you need so much more resolution to cover a wide field of view. When sensors and chipsets would finally catch up, user expectations would grow to match. Now we’re up against physics: Can’t add more resolution past the diffraction limit, and larger sensors are impractical for super fisheye lenses.
I worked on 360 cameras / software for many years. Looking forward to the day when an article like this comes out for one of the products I worked on.
When you’re in the heart of it it’s so easy to take pride in the technical challenges you’ve overcome, but completely miss the realities of the marketplace.
I mean this is an intriguing rationalization, but I don’t buy it.
Buying votes simply doesn’t cost this much, by orders of magnitude. Burning your empire to ashes as a loyalty test doesn’t hold water either: It’s politicians that partake in loyalty tests, not donors.
More often than not I was opening documents, not apps. But with spatial windows in Finder I used to just arrange my Applications folder the way I wanted (sometimes using Aliases) and have it open on the left of my screen, then have my Documents on the right. I kept a row of Desktop icons visible with an In and Out box.
There wasn’t a default folder structure in the early days. Your hard drive had a “System” folder with merely a few hundred files in it (in a hierarchy) that you can ignore day-to-day. Otherwise the whole drive was your playground.
It’s interesting: my recollection of that period was I rarely stored anything on the desktop. The file system was so much smaller and easier to handle that I stored things in folders and didn’t have trouble finding them again. Not until OS X did I pick up the desktop-as-staging-area habit because navigation was so painful.
Spam was a losing battle. I stopped running a bulletin board around the same time I stopped hosting a mail server.
It was Sony, not IBM. They built the PowerBook 100 based on Apple’s 150 and 170 models.
As it is likely that the number of launch customers for this node is one (continuing the trend), this may be necessary simply to reach agreed upon volumes.
APIs existed for fractional scale and assets in early Mac OS X versions (10.4 I think). I remember building out 1.25, 1.5 and 2x assets for an application at the time. These were never to be shipped to consumers for a few reasons.
There were intractable issues with window spanning across displays with different scale factors. Ultimately this was resolved by not allowing window spanning on the platform anymore.
It’s cheaper to build two at the same time than shutting down production for years and trying to build another one. Tooling doesn’t last forever, and the process and skills required to build one can help you build the second one cheaper. But if you wait, that knowledge is often lost. For example, we have no way to build a Saturn V rocket today even having spent R&D and NRE decades ago.
Surprisingly my rate was not effected (around $1200/yr), though I have been a customer for more than 20 years without a claim.
My Model 3 hit some road debris a couple years ago. It damaged the coolant line connector heading into the battery. Tesla replaced the entire battery for ~$15k, which probably could have been a $700 repair like that mentioned in the video.
That said, my insurance covered the cost without a problem and I had my car back in 4 days. I don't know if they took possession of the original battery or negotiated a different rate, but it sounds like Tesla makes bank on this kind of repair. $15k for a new battery pack, a quick turnaround from their service center, and someone gets the old pack which in all likelihood was perfectly fine.
There aren't a lot of shops that know how to repair a battery pack (in most of the country anyway). With less than 2% of cars on the road being EVs that's not surprising, but as more are sold you'll see more come about. The insurance companies will be very motivated to reduce these kinds of claims, and with real competition Tesla will no longer be able to justify the practice.
I think the feet-dragging comes more from the dealer network than from automakers themselves. Ford, GM and the like will still make plenty of money from offering parts for their EVs. Dealers however continue to show distaste in EV sales. Part of that may be the reduced service needs (no oil changes, transmission rebuilds, engine maintenance, etc.) that will lower their income, part may be from the sales side. That's been Tesla's argument all along for selling and servicing direct, and I think anyone that's tried to buy an EV from a Chevy dealer might agree.
Apples and oranges. Tesla AutoPilot is a driver assistance system not an autonomous vehicle. It doesn’t even claim to avoid these situations, hence the need for full attention by the driver.
AP has billions, not millions of miles driven FWIW.
H2 does not, and cannot offer the end-to-end efficiency of battery electric vehicles. The distribution infrastructure for H2 is inherently less efficient than electricity distribution alone, making BEVs 3x more efficient:
https://electrek.co/wp-content/uploads/sites/3/2016/04/hybri...
The primary advantage is faster refueling. The price is no in-home refueling -- a big win for BEVs, as most trips will not require refueling on the road. There are also real safety concerns about storing and transporting H2 at very high pressure.
> In contrast with conventional digital cameras, in fact, curvy imaging sensors typically require multiple and complex lens combinations to take clear and high-resolution images.
This sounds backwards to me. My understanding of the main benefit of curved sensors is to eliminate complex lens series needed to correct aberrations caused by a flat sensor surface.
The neat thing about codecs is they're really defining the bitstream and decoding algorithms.
The encoding algorithms are not written in stone, so to speak. If you can optimize motion estimation encoding using Lucas-Kanade, you can just write that into, say, the x264 encoder and so long as the output is complaint you can expect all existing decoders to play back just fine.
Decoding of course may not be so flexible for compatibility reasons, and of course software is much more malleable than hardware.
Are there video codecs which are (accidentally) Turing-complete?
Maybe there should be a separate indication of throttling so we don’t conflate with CPU usage.
Throttling is essentially determined by three factors: Energy usage, thermal saturation, and cooling. A bath tub analogy comes to mind: Energy usage represented by flow from a faucet, the heat sink is the water level in the tub, and the drain represents the cooling rate. Only energy usage could be plotted instantaneously while the others may have to be modeled and could change based on environmental factors.
> It shouldn't take horrific accidents for us to suddenly decide to care about structural safety.
Building codes are written in blood, as they have always been.
I wouldn’t count on it. Apple is vertically integrated, but doesn’t do their own manufacturing. It’s not necessary when They can dominate the supply chain and hold a practical monopsony on the best production capacity anywhere. This is why everyone else was lagging to produce 5nm parts -- Apple simply bought 100% of TSMC’s capacity.
It's been a decade since AirDrop was released. It's clearly a useful capability, and I would love to be able to share with any device this way. Nevertheless, no universal protocol has emerged, simple or otherwise, that could take its place.
In context it sounds like calling in a favor, like “calling in a chit”, in that it’s transactional unlike of the common usage.
> Alarm bells should have been raised among us developers when Apple suddenly asked everyone to shell out $99 for the "privilege" of making an app available on the "App Store", and treated it as something normal. And later, more so, when Apple demanded a percentage cut too on every sale you make from your app.
I'm not sure where the "suddenly" comes from. It's not as if there was a time before the fee where developers could ship apps for iOS. There's been a developer program as long as there has been an App Store. For that matter, there was a much more expensive developer programs for the Mac before iOS was even a thing. I remember paying somewhere between $1500 and $3000 when we were writing Mac software in the early aughts.
I'm curious on a technical level where Apple would go if forced to allow third party stores. Presumably they would still control the keys for notarization and entitlements used by apps, and still require developers to purchase Apple Developer Program accounts. Would we see the APIs be restricted to only allow 'App Store' apps to use things like iCloud and Apple Pay, as it is on the Mac? Would more APIs be partitioned between first- and third-party access?
Is there an advantage to compiling native vs non-native code? Certainly during execution I would expect that, but I’m not clear why that would be true for compilation.
Agreed that a better benchmark would be compiling for the same target architecture on both.
I suppose they "dropped the ball" in the sense that those instructions cannot be assumed to be available, thus will not be encoded by the compiler by default. Any future processors which include the instructions may not benefit until developers recompile for the new instructions and go through the extra work required to conditionally execute when available.
That said, to get the best performance on vector math it has long been recommended to use Apple's own Accelerate.framework, which has the benefit of enabling use of their proprietary matrix math coprocessor. One can expect the framework to always take maximum advantage of the hardware wherever it runs with no extra development effort required.
