Hacker Newsnew | past | comments | ask | show | jobs | submit | hi_herbert's commentslogin

I regularly have atrocious transient 144p like compression artefacts and lighting absurdities using Netflix both in chrome and via their native h265 app. It is pathetic.

Tangent if they really cared about user experience and Ecology they would implement h265 and h266 support in chromium (aka a mere function call to the embedded ffmpeg). H266 is revolutionary but it's adoption is of zero because of AV1 lobbyists a bit like so called environmentalists once launched a RPG rocket on the superphenix thorium mankind saving reactor.


FFMPEG hasn't even implemented VVC yet, and neither have web browsers, so Netflix can't just make "a mere function call" to get H.266 support.


>H266 is revolutionary but it's adoption is of zero

Adoption on the Web. Most broadcasting companies are getting ready to move to H.266.

I wish we could get a JPEG XL based Video codec.


Good point I hope is true but I was also mostly referring to the inexistant (not even in roadmap) hardware acceleration support.

> I wish we could get a JPEG XL based Video codec. Well i'm curious about that but FLIF, the predecessor (and maybe XL too) is based on MANIAC which is a variation of H264 encoding.. https://en.wikipedia.org/wiki/Free_Lossless_Image_Format#:~:...


>inexistant (not even in roadmap) hardware acceleration support.

Oh they are definitely on the roadmap ( Qualcomm and Mediatek ). I think a lot of people forget there are long lead time in hardware development. Especially with Mobile where energy usage is a key issue. The conformance test of H.266 only finished in mid 2021 if I remember correctly and continued being refined in 2022. If you are going to test your silicon in 2021, your earliest chance of any mobile solution with VVC is going to be 2023.

I would guess both AV1 and VVC lands in Qualcomm SoC in ~2023. MediaTek and Apple coming in 2024.


jpeg-xs?


I'm pretty sure you can do that with Linux. The hypothetical BSD networking advantages seems more and more obscolete to me, missing on most modern advances such as e.g MTCP support https://www.multipath-tcp.org/ It's a basic gradient about human resources.


This switch has throughput of 3.2Tbps and runs linux so evidently doable with hardware offload https://store.nvidia.com/en-us/networking/store/product/MSN2...


Ad-hoc black or white bans are very retrograde and costly for tje most part and usually stem from purity thinking. Case in point reflection in Java is a godsend. I use it very rarely because it'd uses only comes for very specific needs but when I use it, the alternative either doed not exist or usually would be much more uglier. As for streams well it's just regular functors (map, filter) they are used in every language and are very useful. Now I agree about two things: 1) the stream api is a bit (not that much though) verbose, which significantly contrast with Kotlin. Although e.g .toList() helps 2) yes develpers especially junior ones are eager to abuse functors in an unreadable mess. When there is complexity using loops is usually more readable. Streams however are very fit for regular ETL that represents ~70% of code for most simple apps. The pinnacle of complexity would be e.g. Reactive streams such as rxjava.

I agree python dependencies are a worldwide shame and eval() is very niche (but again should not be universality banned assuming good developers, maybe though one could conditionally ban it aka it would trigger a lint during code review that would need explicit validation.

As for the topic at hands, google style bans are insane e.g. No Exceptions lol


I agree with this comment, and cannot understand why is downvoted. I would like the one that downvoted comments on why. My thinking, more or less in line with the comment is: instead of investing energy, time and resources in writing laws of what is allowed and what no (often without rationale). Use that time, effort and energy in educating developers, so that, if those prohibitions are really sensible, they will anyway refrain from doing that. You get the benefit of not having to change the bans. By doing regular code reviews, you can detect ill formed code, and discuss with the developers. Maybe some developer has something to teach to the "big experts" who write those documents?


What's easier: writing set of rules to drop language features or educating 10k engineers? It's difficult alone to have those engineers follow the style guide (even with help from linters etc).

Average engineer, in any company, doesn't care about the language they use. Just wants to get stuff done. And that's how it should be.


My experience says, if you want to do one project. By all means, it's easier to have a standard where you drop features. -- But beware: you need either good engineers or you have to educate them, anyway.

If you have constant new projects, each one with very different requirements and needs, it will not be so easy to make a standard "one size fits all".

Also, again, you will not be doing "just one" standard, I would not subestimate the effort of such rulesets. You will have to the modify and modify it constantly (I know it from the company I'm, there are whole teams working on that, doing meetings constantly with stakeholders, and replying to exception requirements). In the long run, I would prefer to have good engineers, that do not need to be lead in each little step. --and having to check if they adhere to the rules!

I like the phrase: "If you think education is expensive, try with ignorance" Or: - I'm afraid to waste money educating our employees, and then they leave us - What if we do not educate them, and they stay?!


"no exceptions" is one of the best parts of Google style guide, IMO. Note that, banning of exceptions introduced returning status (error codes done right). It makes it easier to follow the code and makes the code more readable (but, you need a few macros, unfortunately).


In a language like C++ returning status codes means that callers can and will ignore it, even when they shouldn't.


Since C++17, using [[nodiscard]] can help with that.


Indeed, Google's implementation of Status/StatusOr requires explicit handling of those objects, they cannot be discarded automatically.


OK if you like 10-15% performance loss off the top.

And incompatibility with the rest of the world.


I'm pretty sure this rethoric is fallacious, most VMs/languages are not GPL and have MIT-like licenses and yet do not have the issue. It's just that clang lack human resources. Compagnies are not really secretly maintaining their own fork of clang with full support for modern c++. It's not in their economic interest to have to fo all tjis engineering. Instead of malice it'd just plain mediocrity. Yes there are trillion dollars companies that would benefit from better c++ but either they use GCC, either they fail to understand that clang needs funding by pure and quite universal mediocrity. Also the thing is, most languages do not afford to have multiple serious implementations because it is economically absurd, it divide progress by 2 and duplicate the bug surface by 2. GCC at least for the foreseeable future is the de facto C++ implementation.


The facto only for FOSS systems I guess.


You can find some module candidates here https://github.com/servo/servo/issues/24026#issue-483508434 The one that make the most economic sense would be for mozilla to drop spidermonkey and make v8 faster instead


Betting on carbon would allow transparent FFI like Kotlin, typescript or graalvm achieve, which is economically disruptive. Rust seems more like a plan B


I wonder how up to date is the old belief of better error messages. The was some great redhat blogs about structured error messages in newer GCC.


GCC has gotten better indeed, but it's still in a different league than Clang. I still get into situations where I can't make heads-or-tails of what GCC is saying to me, which can usually be easily solved by switching to Clang.


One problem here is that GCC emits certain warnings as part of the optimizer, which results in many false positives that are essentially impossible for the lay programmer to understand. For example, jump threading might duplicate some code path and propagate constants in it, and then warn about an uninitialized variable / out of range access / etc in that code-path, even though it does not exist in that form in the original program.


Funny enough, this is exactly the kind of situation where other people cry "why did the compiler not warn me about basing optimizations on UB".


I don't do C++ anymore but I will forever remember the Vtable hell "messages" when doing OOP and doing a slight unintuitive mistake about destructor or constructor. Is this still a thing in clang?


Ok, that's kinda true I suppose; I remember that GCC's error messages have indeed gotten better after a major version release.

Also, when you say structured, do you mean errors over LSP, or do you mean more structure in the formatting when reporting in CLI?


GCC returns pretty nice, colored and structured error messages in CLI for quite some time.


I meant in cli a bit like rust arrows logs


What is the status of ubsan, msan, tsan and others support for GCC though? Last time I checked they were a bit behind. I agree GCC make clang obscolete regarding C++ support and even performance. I don't know a comprehensive alternative to clang linter but I'm sure there are a few.

Given that llvm receive more human resources than gcc by far, I once expected it to outperform gcc generally (e.g support for polyhedral optimizations, BOLT, etc) Unfortunately weirdly it seems llvm performance is mostly stagnant. I personally suspect we are reaching increasingly diminishing returns with AOT and that the performance graal would be a hybrid that also does JIT at runtime (beyond PGO therefore) and more interpretable than BOLT


At work GCC is a lot slower than clang, the project uses a bit much template magic but still, clang is faster.

Where does this GCC is faster thing come from? I personally havent experienced it


I mean faster runtime performance, I have no clue about compilation time. Well I'm basing this on the countless benchmarks I've seen, e.g. on phoronix over the decade. Also you have to understand that Clang -O2 is (was) "unfair" as GCC did not enable autovectorization until -O3. This has (is being?) changed.


Old hype thing created by gcc fanboys :)

They always claims so.


This article is a bit fallacious/misleading: I have no clue wether Boom design is vaporware or serious engineering but: 1) The initial premise, that there is a costly need to design a new engine is meta-unecessary AKA not necessarily necessary. The article raise 2 reasons for a new engine: fuel efficiency and noise reduction. I'd argue the concorde engine (the Rolls-Royce/Snecma Olympus 593) is excellent regarding efficiency -> The overall thermal efficiency of the engine in supersonic cruising flight (supercruise) was about 43%, which at the time was the highest figure recorded for any normal thermodynamic machine.[3] I don't know for sure what is the SOTA efficiency nowadays but IIRC last generations engines are ~10% more fuel efficient than the ones from the 80s, which where at the time behing the Rolls-royce engine hence I even doubt modern engine have better thermal efficiency than aforementioned 43%. Regarding the topic of thermal efficiency, engines are not supposed to reach 43% without being supercritical, did Rolls-royce bypass physics laws? There must be something I ignore here. Anyway even if (?) we could design supercritical jet engines the best possible thermal efficiency would be 46-7% AKA a minor improvement.

Boom can increase fuel efficiency via the airplane architecture with e.g. composites. The near commercialisation new civil aircraft from china achieved a 10% reduction doing so. The same can be said for noise reduction. Hence what Boom should do is simply to order Rolls royce to produce the same engines again. However one should know that R&D for the successor of the concorde engine has already been spent and such engine has been designed. Unfortunately the U.S imperialist oppressive bans killed the concorde economics before the production of said engine, cf: https://en.wikipedia.org/wiki/Rolls-Royce/Snecma_Olympus_593....

Now about the noise levels let's adress the fact that it is a non-issue. 1) If you look at the empirical scientific comparisons, the mean noise of the concorde is significantly lower than many civil airplanes, especially the ones with 4 engines. 2) The boom while intense, is very transient. It is not heard from people inside the airplane. It is a non-problem for the obvious reason that your jet does not need to be supersonic for 100% of the trajectory, therefore a plane can and should go to very high altitude (already a supersonic requirement) and/or above low density population (rural, ocean) and only then bypass the speed of sound, making the noise boom a moot problem. While this solution is trivial, political bans and people hysteria isn't.

What is at stakes? A lot of things, supersonics isn't just cool, it is a life saving technology that can allow the transfer of key people in records time (expert surgeon in niche disease emergency for example) which can have very high utilitaristic value. It can also make it much more pratical for key people to meet physically (e.g. key academicians for a symposium about advancing the state of the art in a topic) which is high impact considering cognitive biases regarding human agency.

Note however there are other supersonic engine makers than rolls royce, for example any country that makes supersonic military jets can obtain such engines. It is easy to forget that the first commercial supersonic engine was not the concorde but a russian tupolev. While the tupolev has reliability issue, few know they had an alternative engine (likely more reliable). In addition to the tupolev engines, I would look into the state of the art https://en.wikipedia.org/wiki/Saturn_AL-31 Regarding SOTA civilian turbofan there is the https://en.wikipedia.org/wiki/Aviadvigatel_PD-14#PD-35 in development, although it can power an antonov (!) and seems very versatile I wonder if (not a turbojet) it can perform supersonicity without afterburners.

regarding those options however, russia bad, china bad.


The GE XA100 is intriguing, not that it would be available for a corporate jet.

https://en.wikipedia.org/wiki/General_Electric_XA100 https://www.geaviation.com/press-release/military-engines/ge...


Interesting concept thanks


This article is a bit fallacious/misleading: I have no clue wether Boom design is vaporware or serious engineering but: 1) The initial premise, that there is a costly need to design a new engine is meta-unecessary AKA not necessarily necessary. The article raise 2 reasons for a new engine: fuel efficiency and noise reduction. I'd argue the concorde engine (the Rolls-Royce/Snecma Olympus 593) is excellent regarding efficiency -> > The overall thermal efficiency of the engine in supersonic cruising flight (supercruise) was about 43%, which at the time was the highest figure recorded for any normal thermodynamic machine.[3]

I don't know for sure what is the SOTA efficiency nowadays but IIRC last generations engines are ~10% more fuel efficient than the ones from the 80s, which where at the time behing the Rolls-royce engine hence I even doubt modern engine have better thermal efficiency than aforementioned 43%. Regarding the topic of thermal efficiency, engines are not supposed to reach 43% without being supercritical, did Rolls-royce bypass physics laws? There must be something I ignore here. Anyway even if (?) we could design supercritical jet engines the best possible thermal efficiency would be 46-7% AKA a minor improvement.

Boom can increase fuel efficiency via the airplane architecture with e.g. composites. The near commercialisation new civil aircraft from china achieved a 10% reduction doing so. The same can be said for noise reduction. Hence what Boom should do is simply to order Rolls royce to produce the same engines again. However one should know that R&D for the successor of the concorde engine has already been spent and such engine has been designed. Unfortunately the U.S imperialist oppressive bans killed the concorde economics before the production of said engine, cf: https://en.wikipedia.org/wiki/Rolls-Royce/Snecma_Olympus_593....

Now about the noise levels let's adress the fact that it is a non-issue. 1) If you look at the empirical scientific comparisons, the mean noise of the concorde is significantly lower than many civil airplanes, especially the ones with 4 engines. 2) The boom while intense, is very transient. It is not heard from people inside the airplane. It is a non-problem for the obvious reason that your jet does not need to be supersonic for 100% of the trajectory, therefore a plane can and should go to very high altitude (already a supersonic requirement) and/or above low density population (rural, ocean) and only then bypass the speed of sound, making the noise boom a moot problem. While this solution is trivial, political bans and people hysteria isn't.

What is at stakes? A lot of things, supersonics isn't just cool, it is a life saving technology that can allow the transfer of key people in records time (expert surgeon in niche disease emergency for example) which can have very high utilitaristic value. It can also make it much more pratical for key people to meet physically (e.g. key academicians for a symposium about advancing the state of the art in a topic) which is high impact considering cognitive biases regarding human agency.

Note however there are other supersonic engine makers than rolls royce, for example any country that makes supersonic military jets can obtain such engines. It is easy to forget that the first commercial supersonic engine was not the concorde but a russian tupolev. While the tupolev has reliability issue, few know they had an alternative engine (likely more reliable). In addition to the tupolev engines, I would look into the state of the art https://en.wikipedia.org/wiki/Saturn_AL-31 Regarding SOTA civilian turbofan there is the https://en.wikipedia.org/wiki/Aviadvigatel_PD-14#PD-35 in development, although it can power an antonov (!) and seems very versatile I wonder if (not a turbojet) it can perform supersonicity without afterburners.

regarding those options however, russia bad, china bad.


There are a number of non-starters here:

1. Efficiency counts for a lot in these aircraft, and it's absolutely possible to do better than the Olympus. In particular, high-temperature materials and engineering, along with combustor efficiency have evolved significantly since the Olympus era. Tenths of a percent are a big deal in subsonics, let alone supersonics.

2. Emissions are also a huge deal. Significant work would need to be done to clean up Olympus emissions.

3. Is the Olympus sized properly for the Boom design? Probably not.

4. We don't necessarily publicly know if Rolls offered to refurb and support these engines, but if they didn't, there are some very good reasons. Re-establishing a supply chain for these would be a really big deal, and in some cases not cost-competitive with a from-new design based on present-day supportability.

5. Supersonic boom noise being a non-issue is an absurd premise. It drastically affects your addressable market, period.

6. Time savings for a few critical needs as you cited are not going to be enough economic motivation to develop this system.

7. It's not that "China, Russia bad", it's that Chinese and Russian materials and manufacturing will not currently support the durability requirements for commercial viability of these hypothetical supersonic cruise engines you propose. You would have a lot of off-wing refurb time on such engines. Chinese engines don't have the performance, either.

The case for anything Boom is developing is not really there.


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

Search: