Hacker News new | past | comments | ask | show | jobs | submit | more indolering's comments login

And no insurer would be willing to insure it.


Yeah, the stainless steel panels of the Cybertruck are not stainFREE. Adding a clear coat to the base model would prevent a lot of disappointment.


There are similar strategies employed by high frequency traders using Java. Not as ergonomic as in C# (which I believe had this as a forethought) but interesting all the same.


.NET has been designed since the beginning to handle C++, C# already had some of the features but not all of them, in some cases it was needed to emit MSIL, or use Managed C++ on .NET 1.0, or C++/CLI since .NET 2.0.

The improvements on C# 7 and later are exactly to avoid emiting MSIL manually, and also cut the dependency on C++/CLI, as it is Windows only.


It's a really smart application of ML: helping around the edges and not letting the ML algo invent pheonems or even whole words by accident. ML transcription has a similar trade-off of performing better on some benchmarks but also hallucinating results.


A nice story about Xerox discovering this issue in 2003, when their copiers began slightly changing random numbers in copied documents

https://www.theverge.com/2013/8/6/4594482/xerox-copiers-rand...


I don't think machine learning was involved there at all. As I understand it, it was an issue of a specifically implemented feature (reusing a single picture of a glyph for all other instances to save space) being turned on in archive-grade settings, despite the manual stating otherwise.


https://youtu.be/zXXmhxbQ-hk Interesting yet funny CCC video about this


fwiw, in ASR/speech transcription world, it looks reverse to me - in the past, there was lots of custom non-ML code & separate ML models for audio modeling and language modeling - but current SOTA ASRs are all e2e, and that's what's used even in mobile applications, iiuc.

I still think the pendulum will swing back there again, to have even better battery/larger models on mobile.


It would fall back to radio and/or other connections. The laser connection would probably be sold at a discount rate due to the variable level of service.


> I imagine it would be much more straightforward to port pretty much any indie games to consoles like Xbox original onwards, PS3 onwards, Wii onwards, maybe Windows 7 average desktop and notebooks (lots of indies already use older direct x and are compatible with windows 7 ,

Not a game developer, but given the lack of ports between current gen gaming systems I would assume that it is not straightforward. Sure, a game engine will magically pump out your game for different backends but even supporting Vulkan and Metal results in much gnawing and mashing of teeth (and a lack of games on Apple hardware).

Then there is the developer ergonomics. I know that I hate having to write code to maintain compatibility for even 5 year old standards. Each GPU and game engine is also a unique clusterfuck of incompatibility and subtle bugs that crash the shit out of games. If you want to support that old hardware, you will need to test on the actual hardware. Why bother with all that when there is no money in it and your team just wants to move on from a project that already took 5 years of their lives to develop?

Forward compatibility is something I strongly agree with but backwards compatibility is a logistical nightmare.


Forward compatibility is promising. - The computing systems are kinda standardized now, with consoles and pcs using X64-86 architecture, Xbox using a optimized windows os, and PS4 (almost certainly PS5 too) running BSD. Industry standards would bridge the gap even more, like making open software mandatory (everyone just incorporates their code). More companies investing in FOSS like Vulkan instead of the proprietary ones would be helpfull too. - The proton software on Linux makes a compatibility layer between the game and a newer system, and you can choose an older version.

I think we could eventually just leave the ''XYZ Game of the Year'' v.2.1.4 and never touch it again, and future gamers would at most have to select the proton layer version and vulkan-directx-other game engine version of the game release time, and it could be automatically done in the instalation.


Couldn't they also keep supporting that functionality though CentOS or EPEL? And Fedora probably won't drop support as long as unpaid volunteers bother to keep it working....

I'm glad Red Hat is dropping support entirely: they have been footing the bill for this transition for too long. It's time for Ubuntu, NVIDIA, and others to step up their contributions to/support of Wayland.


Support means many things to a company like Red Hat.

"Ship it" in EPEL, sure, but support to Red Hat is a contractual obligation.


WTF? I thought NVIDIA had adopted an open-source core? Is this seriously something outsiders can't fix?


They have since started supporting the linux kernel and implemented its APIs more or less. I don’t own any nvidia card, so can’t really speak from first-hand experience though.


RHEL 9 will be supported for ~10 years, but RHEL is scheduled to come out in ~3 years. Fedora will probably still support it and I would bet some of the RHEL rebuilds will too.


April fools everyone! Seems like ARM got the domain from a trademark dispute. Redirecting it to their own website is a pretty funny self-own .


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: